What Is the Treasury System of Record?

A system of record is the single authoritative source for a given set of data — the system whose version is treated as definitive when others disagree. For treasury, it's the system that holds the master version of deals, cash positions, exposures and bank data, and it's usually the treasury management system. Designating one system of record per data domain — and drawing a clean boundary between the TMS and the ERP — is what prevents the most corrosive problem in a finance landscape: two systems showing two numbers, and nobody able to say which is right.

What a system of record is

In any landscape with more than one system, the same fact often lives in several places — a bank balance in the TMS and the ERP, a deal in the trading system and the accounting system. The system of record is the one designated as authoritative: its copy is the truth, and every other copy is a derived view that must reconcile to it. Without that designation, you don't have data — you have several versions of data, and an argument.

Why treasury needs a clear one

Treasury runs on numbers that must be trusted absolutely — a cash position you fund against, an exposure you hedge on, a payment you release. If two systems can each claim to hold "the" position, then at the exact moment you need certainty, you have doubt.

"

The question "which number is right?" should never require a meeting to answer. A clear system of record makes it a lookup, not a debate.

A single source of truth isn't a nice-to-have architectural ideal — it's the difference between decisions made on facts and decisions made on whichever screen someone happened to open.

The boundary: TMS vs ERP

The central design question is who owns what. A clean, common split:

The TMS and ERP integrate, but each should own its domain and consume the other's — not both claim the same data. The TMS is the system of record for treasury; the ERP for the ledger; and the flow between them has a clear direction per domain.

System of record vs system of engagement

Not every system needs to own data. A system of engagement (or reference) consumes and presents data for a particular purpose without owning it — a treasury dashboard, a reporting layer, an analytics tool. These are enormously useful, and they're safe precisely because they don't claim to be authoritative: they're views built on top of the system of record. Trouble starts only when a "view" quietly starts being edited and becomes a second, competing master.

The two-sources-of-truth problem

The failure this all prevents has a signature: two systems, two numbers, and a recurring reconciliation nobody can close. It usually comes from one of a few causes — the same master data maintained independently in two places, bidirectional sync that lets edits originate on both sides, or a shadow spreadsheet that's become the real source while the official system lags. Each produces the same symptom: no one can say which figure is authoritative, so everyone quietly keeps their own.

How to define it well

1. Per data domain, name one owner. Deals, cash, statements, GL — each gets exactly one system of record. Not "mostly the TMS" — the TMS, for these domains.
2. Make the flow directional. For each shared data element, decide which system originates it and which consumes it. Avoid bidirectional master sync.
3. Treat everything else as a view. Dashboards and reports read from the record; they don't become alternate masters.
4. Kill the shadow copies. Every persistent spreadsheet that's really a source of truth is a system of record you didn't design — find it and fold it in.

What usually goes wrong

• Duplicate masters. The same data maintained independently in two systems, guaranteed to diverge.
• Bidirectional sync loops. Both systems can edit, so "latest wins" races and neither is authoritative.
• Unclear ownership. "The TMS and the ERP both kind of own cash," so reconciliation never closes.
• Shadow spreadsheets. The official system says one thing; the workbook everyone actually uses says another.

Name one system of record per data domain, draw the TMS–ERP boundary explicitly, keep data flow directional, and treat every dashboard as a view rather than a master — and "which number is right?" stops being a question. That single-source-of-truth discipline is the backbone the whole treasury architecture hangs on.

Part of the Treasury Systems Architecture guide. See also the reference architecture and ERP-TMS integration. The newsletter sends one finance-systems pattern every two weeks.