What Is the Treasury System of Record?
A treasury system of record is the single authoritative source for its data. Designating one, and the TMS-vs-ERP boundary, ends 'which number is right?'
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:
| Data domain | Typical system of record |
|---|---|
| Deals, positions, exposures | TMS |
| Bank statements, connectivity, cash | TMS |
| General ledger, accounting | ERP |
| Vendor/customer master, AP/AR | ERP |
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
- 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.
- Make the flow directional. For each shared data element, decide which system originates it and which consumes it. Avoid bidirectional master sync.
- Treat everything else as a view. Dashboards and reports read from the record; they don't become alternate masters.
- 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.
Map yours: the free Treasury System-of-Record Map makes you name one owner per data domain — and flags any domain with two owners, a flow written in as the owner, or no owner at all — then exports a table for your architecture doc.
Part of the Treasury Systems Architecture guide. See also the reference architecture and ERP-TMS integration. The newsletter sends one finance-systems pattern, product decision or build lesson every two weeks.
Frequently asked questions
What is a system of record in treasury?
A system of record is the single, authoritative source for a given set of data — the system whose version is treated as definitive when systems disagree. In treasury, it's the system that holds the master version of deals, cash positions, exposures and bank data, typically the treasury management system. Designating one system of record per data domain is what lets an organization answer 'which number is right?' with certainty instead of a debate.
What is the difference between a system of record and a system of engagement?
A system of record holds the authoritative, master version of data — it's where the truth lives. A system of engagement or reference is a system that consumes and presents that data for a particular use, without owning it. A dashboard or a reporting layer can be a system of engagement built on top of the treasury system of record. The distinction matters because only the system of record's copy is authoritative; everything else is a view.
Should the TMS or the ERP be the system of record for treasury data?
It depends on the data domain, and the key is drawing a clean boundary. Typically the TMS is the system of record for treasury-specific data — deals, positions, exposures, bank statements and connectivity — while the ERP remains the system of record for the general ledger and accounting. Problems arise when both systems claim ownership of the same data and sync bidirectionally, creating two competing versions of the truth. Decide who owns what, once, explicitly.