Treasury Data Quality and Governance

Everything treasury reports and decides — the cash position, the exposures, the valuations, the forecasts — is computed from underlying data, which means data quality is the quiet ceiling on whether any of it can be trusted. A wrong number in treasury rarely comes from a wrong formula; the formulas are old and well understood. It comes from wrong data flowing through a correct formula, and the result still looks like a number. This article is about the quality of the data the treasury data model describes, and the governance that keeps it clean. In eighteen years across SAP FI/TRM and treasury systems, it is the least visible discipline in the landscape — and the one that most often explains the reconciliation that never quite closes.

Why data quality is the whole game

A treasury system does not store its answers. It stores data and derives them. A cash position is computed from balances and flows; a valuation from positions and market data; an exposure from deals against a counterparty. Every output is downstream of data you fed in earlier, often by someone who has since moved on.

So if the data is right, correct logic produces correct numbers; if the data is wrong, that same logic produces wrong numbers confidently — no error, no red flag, just a figure that is off, right up until every number is suspect at once.

The dimensions of data quality

"Quality" sounds vague until you break it into the dimensions that actually fail. Five carry most of the weight in treasury:

• Accuracy — the data reflects reality. A bank account number that is wrong by one digit is inaccurate, and it does not throw an error; it routes a real payment to the wrong place.
• Completeness — nothing required is missing. A deal captured without its settlement instructions, or a counterparty without its country, is incomplete — and the gap surfaces downstream as a payment that cannot settle or an exposure that cannot be classified.
• Consistency — the same thing is defined the same way everywhere. If "counterparty exposure" or a currency's rounding is defined one way in the ERP and another in the TMS, the two systems disagree by design, and nothing reconciles.
• Timeliness — the data is current when it is used. Valuing today's positions on yesterday's FX rates, or building a cash position on a statement that has not yet arrived, gives a stale answer that looks perfectly live.
• Uniqueness — no duplicates. The same real-world counterparty entered twice fragments your view of exposure to that name: you look within limit on each record and are over it in reality.

Each of these fails silently. That is the common thread — none of them announces itself as a data problem. They announce themselves as a wrong position, a stuck payment, a broken reconciliation, weeks later and hard to trace back.

Master data: the highest-stakes case

Not all data carries equal risk, and master data carries the most. It — banks, accounts, counterparties, instruments, settlement instructions — is stable but shared by everything, so a single wrong record does not corrupt one transaction; it corrupts every transaction that references it, for as long as it stands.

"

Bad transactional data is one wrong number. Bad master data is every number that touched it.

A wrong bank account is not a data-quality footnote — it is a payment incident waiting for a payment run. A duplicated counterparty is an exposure understated across two records that never aggregate. This is where the model and data quality meet: the model says which data is shared and authoritative; quality determines whether that authoritative data is actually right. Get master data wrong and the coherence of the model cannot save you — the whole structure is built on a value that lies.

Governance: keeping it clean is a discipline, not an event

Data quality does not stay high on its own. Left alone it decays — accounts go stale, definitions drift, duplicates creep in as people onboard the same entity twice. Governance is the standing discipline that resists that decay, with four moving parts:

• Ownership. Each data domain has a named owner — a person or role accountable for it — not a vague sense that "someone in treasury looks after banks." Data with no owner is data no one keeps clean.
• Standards and definitions. The same thing means the same thing everywhere: an agreed definition per field and per metric, so consistency is designed in rather than negotiated after every disagreement.
• Maintenance workflow with controls. Changes flow through a defined path with the right approvals — four-eyes on the changes that move money, following the system-of-record rule that a field is edited only in its owning system and copied everywhere else.
• Monitoring and quality checks. Automated checks that catch drift — duplicates, missing required fields, values outside plausible ranges, stale records — before they become a wrong number, so problems are found by a control and not by an incident.

None of this is a one-off. It is an operating responsibility that runs for as long as the landscape does.

Migration and steady state: two very different battles

Data quality has to be won twice, and the second win is the harder one.

At migration, before go-live, there is focus, budget and a deadline. Everyone accepts that legacy data must be cleaned, deduplicated and validated before it moves, and the work gets done because a bad go-live is a failure nobody will own.

At steady state, the pressure is off. The project team has disbanded, and the data that was pristine on day one starts to drift: new accounts added under time pressure without full validation, duplicates slipping in, promised reviews quietly stopping. This is the gap governance exists to close — keeping data clean after the launch adrenaline is gone, when it is nobody's obvious job and no deadline forces the issue.

Docs-vs-reality: the discipline nobody wants to fund

Here is the pattern I keep meeting. Data quality is invisible when good and catastrophic when bad, so it is chronically under-funded. Everyone wants the dashboard and the analytics; almost no one wants to own the reference data those reports silently inherit. The money goes to the front end and the foundation gets whatever is left.

The bill still arrives — just later, and disguised. The reconciliation that never closes, the exposure figure two people cannot agree on, the payment that went somewhere it should not have: run any of them to ground and the cause is almost always here — a duplicate, a stale rate, a definition that meant two things, an account maintained in two places. On paper, data quality is a setup task you finish before go-live. In reality it is a live control surface, and usually the least-owned one in the landscape.

Name an owner for every domain, agree the definitions, control the changes, monitor for drift, and treat the work as continuous rather than a one-time cleanse — and treasury data becomes the dependable foundation every number quietly stands on. Skip it, and you build ever more sophisticated reporting on data you cannot trust: a fast, expensive way to be precisely wrong.

Part of the Treasury Systems Architecture guide. See also the treasury data model and treasury master data management. The newsletter sends one finance-systems pattern every two weeks.