Treasury Data Lineage: From Source Transaction to Reported Number

Every treasury report makes a promise: this number is real. Data lineage is how you keep it. A cash position, a liquidity forecast, an exposure figure, a covenant ratio — each is the end of a chain that started as a source transaction and passed through mappings, enrichments and aggregations to reach the report. When someone asks "where did this come from?" — an auditor, a CFO, you at close — lineage is the difference between a confident, traceable answer and an uncomfortable "the system produced it." This is how you build the chain, and own it.

What lineage actually traces

Lineage isn't a diagram you draw once and frame. It's the answer to a specific, repeatable question: for this reported number, what is the exact path back to source, and who is accountable at each hop? A treasury figure typically travels through the same stages:

Source transaction        e.g. an FI document, a treasury deal, a bank statement item
      │  (capture)
      ▼
Transformation            derive cash relevance, value date, direction, amount in currency
      │
      ▼
Enrichment                add house bank / account, counterparty, GL mapping
      │
      ▼
Liquidity-item mapping    classify the flow into the reporting taxonomy
      │
      ▼
Aggregation               roll up by account, entity, currency, horizon
      │
      ▼
Semantic / reporting layer   the model the report reads: named measures, hierarchies
      │
      ▼
Reported number           the figure a human sees and decides on

Each arrow is a transformation with an owner. The reported number is only as trustworthy as the least-understood hop in that chain — and the hops people understand least are usually the mapping and the semantic layer, where business meaning gets attached and quietly encoded.

The lineage record: what to capture per hop

For lineage to be usable — in an audit, in an incident, in a redesign — each hop needs the same handful of facts recorded. This is the artefact, and it's deliberately boring:

The value isn't the table — it's the two columns people skip: transformation rule and owner. A lineage with boxes and arrows but no rules is a picture; a lineage with rules but no owners is a document nobody maintains. Both columns, or it won't survive contact with a real question.

Lineage and the system of record are a pair

Lineage doesn't replace the system-of-record discipline — it depends on it. The system of record names the single owning source for each data domain; lineage is the owned path from that source to the report. If two systems both claim to own "cash balances," lineage forks and every downstream number inherits the ambiguity. So the sequence is: name one owner per domain first, then trace the lineage from it. One without the other leaks — a clear owner with an untraced path, or a documented path from a source nobody agreed was authoritative.

"

The system of record tells you where the truth starts. Lineage tells you what happens to it on the way to the report. A number you can't trace to a single owned source isn't a fact — it's an assertion.

Reconciliation evidence falls out of good lineage

Here's the payoff most teams miss: you don't reconcile a well-traced number — you reproduce it. When every hop has a rule and an owner, reconciliation stops being a search for where two numbers diverged and becomes a walk down a known path: this source produced these flows, this mapping classified them, this aggregation rolled them up, and the report shows the result. A discrepancy points at a specific hop.

That's the same method that debugs cash flows in FQM_FLOW and postings in TRM: localise the stage, then the rule, then the cause — never "correct" the output. Lineage is what makes that method possible across the whole reporting chain, not just inside one module.

Where lineage breaks

The failure modes are consistent, and all of them are ownership failures wearing a technical disguise:

• The unmapped hop. A transformation everyone relies on and nobody owns — usually a spreadsheet or a mapping table maintained by one person who's since moved on.
• The silent taxonomy. Liquidity-item or classification rules that encode business meaning with no documentation, so the why behind a number lives only in someone's head.
• The forked source. Two systems claiming the same domain, so lineage can't resolve to one origin.
• The opaque semantic layer. A report model with derived measures whose formulas aren't traceable back through the aggregation to source.
• Lineage as a one-off. Drawn for a go-live, never maintained, wrong within a quarter. Lineage is a living record or it's decoration.

What good looks like

• Every reported number traces to a single owned source, through hops that each have a documented rule and a named owner.
• The taxonomy is explicit. Liquidity-item and classification rules are written down, not folklore.
• Reconciliation is reproduction. You can walk any figure back to source on demand — for an auditor, a CFO, or yourself.
• Lineage is maintained, versioned alongside the reporting model, and updated when a rule changes — not redrawn in a panic before an audit.

Treasury spends enormous effort producing numbers and comparatively little proving they're real. Data lineage closes that gap: it turns "the system says so" into "here's the path, hop by hop, owner by owner." Build it once as a living artefact and every downstream question — audit, incident, redesign — gets easier. Skip it, and you'll rebuild the chain from memory every time someone asks the one question that matters: where did this number come from?

Part of the Treasury Systems Architecture guide. See also the treasury system of record and treasury reporting & analytics architecture. The newsletter sends one finance-systems pattern, product decision or build lesson every two weeks.