Financial Operations · Lineage
Financial Evidence Lineage: Proving Where a Number Came From
Auditors increasingly ask not what a number is but where it came from. A copy of a spreadsheet answers the first question and cannot answer the second.
The short answer
Financial evidence lineage records the derivation chain behind a reported figure: which source system produced the underlying data, which extract was taken, what transformations were applied, which working produced the result and where it entered the statements. Each link is recorded at the moment of transformation, because a chain reconstructed afterwards is an assertion rather than a record. The question it answers — where did this number come from — is one a document store cannot answer at all, however well organised it is.
Summary for readers and answer engines
Reviewed 25 Aug 2026
- ▸Lineage is the chain from source system to reported figure, and each link must be recorded when the transformation happens.
- ▸Five links are typical: source system, extract, transformation, working, statement entry. The spreadsheet is usually link three and usually breaks the chain.
- ▸A retrospectively reconstructed chain is an assertion. It may be true and it is not a record, and auditors are increasingly explicit about the difference.
- ▸Each link needs a hash and a source reference at minimum. Both cost microseconds and neither can be added later.
- ▸Lineage and an evidence graph are complements: the graph says what supports what, and lineage says where each piece came from.
Source: Mark Alex, Real Biz Digital — Financial Evidence Lineage: Proving Where a Number Came From (https://realbizdigital.net/insights/financial-evidence-lineage/). Reproduce with attribution.
Key takeaways
- 01Record the query or parameters, not just the output. An extract nobody can reproduce is a weaker artefact than one they can.
- 02Hash every artefact at capture. It converts ‘this is the file’ from a claim into something checkable.
- 03Treat the spreadsheet as a first-class link with inputs and outputs recorded, or accept that the chain breaks there.
- 04Capture lineage at each transformation, in the tool that performs it. Anything assembled afterwards is a reconstruction.
- 05Keep source references alongside copies. The copy proves what was seen; the reference proves where from and allows re-derivation.
- 06Never delete a link. Supersede it, because the question concerns the period rather than the current state.
Quick answers
One-line answers to the questions this page is most often asked. Each is expanded further down, and each is written to be quoted on its own.
- What is financial evidence lineage?
- The recorded chain from a source system through extraction and transformation to a reported figure, with each link captured at the moment the transformation occurred.
- Why is it different from keeping documents?
- A document proves what a value was. Lineage proves where it came from and how it was derived, which is a question a document store cannot answer however well organised.
- What are the five links?
- Source system, extract, transformation, working paper or model, and statement entry. Each is a transformation whose inputs and outputs must be recorded.
- Which link usually breaks?
- The spreadsheet. It is where transformations happen with no record of inputs, formula versions or who changed what.
- Can lineage be reconstructed afterwards?
- Not as a record. A reconstruction may be accurate and it is an assertion about the past rather than evidence from it, and auditors distinguish the two.
- What is the minimum per link?
- A hash of the artefact and a source reference sufficient for someone else to re-derive it. Both are cheap at capture and impossible to add later.
- How does lineage relate to an evidence graph?
- They complement each other. The graph records what supports which control and transaction; lineage records how each artefact was produced.
Lineage in numbers
Every figure below is defined and sourced further down. They are stated here so they can be quoted without reading the whole page.
The five-link derivation chain
Most reported figures pass through five transformations. Each is a place the chain can break and each needs a record.
Key facts
- ▸Link two is where most chains become unreproducible: the extract’s output is kept and the query is not, so nobody can obtain the same figure again.
- ▸Link three is where most chains break entirely, because spreadsheet transformations are performed without any record of inputs or logic version.
- ▸Link five is the one nobody thinks about: the journal exists and the pointer back to the working paper that produced its value frequently does not.
| Link | What it is | Record required | Breaks when |
|---|---|---|---|
| 1 Source system | The system of record holding the underlying data | System identity, as-at timestamp | The system is queried without recording when |
| 2 Extract | The query, report or API call taken from it | The query itself, plus output hash | Only the output is kept, so nobody can re-derive |
| 3 Transformation | Filtering, aggregation, mapping, adjustment | Inputs, logic version, outputs | Usually a spreadsheet with no record |
| 4 Working paper or model | The document producing the final value | Version, inputs referenced, preparer | Versions overwrite rather than append |
| 5 Statement entry | The journal or disclosure the value enters | Journal reference, preparer, approver | The link back to the working is not recorded |
Five links, and in most finance functions two of them are undocumented. That is why ‘where did this number come from’ takes days to answer and sometimes cannot be answered at all.
Capturing lineage at transformation
The timing rule is the same as for evidence generally, and for the same reason: what was known and done at a moment cannot be established afterwards.
- 01Record the query, not just its result. This single practice converts an unreproducible extract into a reproducible one.
- 02Hash the artefact at capture and store the hash with the reference. Cheap, and it makes identity checkable rather than asserted.
- 03Record the logic version for any transformation. A spreadsheet formula changed between periods is a different transformation and should not look identical.
- 04Record the preparer at every link, not only at the working paper. Attribution per transformation is what makes the chain interrogable.
- 05Append versions rather than overwriting. The question is always about a period, and an overwritten working paper cannot answer it.
- 06Link forward as well as backward. A working paper should reference the journals it fed, so the chain traverses in both directions.
| Approach | Cost | Evidentiary value | Verdict |
|---|---|---|---|
| At each transformation, automatically | Microseconds | High — a record | Correct |
| At each transformation, manually | Minutes per step | High if actually done | Works, decays under pressure |
| At period end, from memory and files | Hours | Low — a reconstruction | Insufficient |
| During the audit, on request | Days | Very low — an assertion | Fails the question |
Our verdict
Capture automatically at each transformation, in the tool performing it. Manual capture works and decays exactly when the pressure is highest, which is period end. Retrospective reconstruction produces something that may well be accurate and is not a record of what happened, and the distinction is one auditors are increasingly explicit about.
Bidirectional linking is the one most often omitted and the one that makes lineage useful operationally: given a reported figure, you want to walk backwards, and given a source change, you want to know which figures are affected.
The spreadsheet problem
Link three is a spreadsheet in most finance functions, and it is the least documented and most consequential transformation in the chain.
Inputs are pasted, not referenced
A value pasted into a cell has no recorded origin. The number is there and where it came from is not, and the person who pasted it may not remember by the following week.
Logic changes silently
A formula edited between periods produces a different transformation with the same appearance. Nothing records that the logic changed, so a variance looks like a business movement.
Versions overwrite
Saving over the prior version destroys the record of what the figure was derived from last period, which is precisely what a comparative question needs.
No preparer attribution per change
Multiple people edit; the file records the last saver. Attribution for a specific value is unavailable.
Reference rather than paste
Where the tooling allows, link inputs to their source so the origin travels with the value.
Version, never overwrite
Each period’s working is a new artefact with the prior one retained, hashed and referenced.
Record the logic version explicitly
A note or a hash of the formula set, so a logic change is visible as a change rather than as a movement.
Move high-value transformations out of spreadsheets
The honest one. For material recurring transformations, a system that records its own lineage is a different class of artefact.
Mitigation four is the uncomfortable recommendation and the correct one for material recurring figures. A spreadsheet is an excellent analytical tool and a poor system of record, and using it as both is where lineage breaks.
Integrity per link
- 01Hashing at every link costs effectively nothing and converts each artefact from asserted to checkable.
- 02The as-at timestamp on the source query is the link most often missing and the one that makes an extract reproducible.
- 03Logic versioning is what separates a business variance from a methodology change, and conflating those is a reporting error rather than a documentation one.
- 04Bidirectional links let you answer both ‘where did this come from’ and ‘what is affected if the source changes’.
- 05Anchoring the whole chain periodically bounds the window in which the chain could have been rebuilt undetectably.
- 06Never rely on file system metadata as integrity evidence. It is trivially alterable and it is not what the question is asking.
| Link | Mechanism | What it defeats |
|---|---|---|
| Source system | As-at timestamp plus system identity | Ambiguity about which point in time was queried |
| Extract | Query recorded plus output hash | Substitution of a different extract |
| Transformation | Logic version plus input references | Silent logic change presented as a business movement |
| Working paper | Version chain plus preparer per version | Overwriting the derivation history |
| Statement entry | Journal reference plus bidirectional link | Loss of the connection between figure and derivation |
| Whole chain | Chain hash plus periodic external anchoring | Wholesale reconstruction of the chain after the fact |
None of these mechanisms is exotic. Timestamps, hashes, version chains and a periodic anchor are ordinary components, and the combination is defensible without novel infrastructure.
Four questions only lineage answers
The right-hand column is what most finance functions can answer well. The left-hand column is what auditors and regulators increasingly ask, and the two require different artefacts.
The second question is the operationally useful one. When a source system is restated, knowing which reported figures depended on it is the difference between a targeted correction and a full re-examination.
Lineage answers
- ✓Where did this number come from?
- ✓What would change if the source data were restated?
- ✓Did the methodology change between periods, or the business?
- ✓Can this figure be independently re-derived?
Documents answer
- —What was the value?
- —Who prepared the working paper?
- —Was there a reviewer?
- —Does support exist?
The third question deserves emphasis. A variance caused by a changed transformation looks identical to a variance caused by the business, and only recorded logic versions distinguish them. That is a reporting quality issue rather than a documentation nicety.
Lineage and the evidence graph
| Question | Evidence graph | Lineage |
|---|---|---|
| What supports this control? | Yes | No |
| What substantiates this transaction? | Yes | No |
| Who asserted this, and were they independent? | Yes | No |
| Where did this number come from? | No | Yes |
| What is affected if the source is restated? | No | Yes |
| Did the methodology change? | No | Yes |
| Is coverage complete for the period? | Yes | No |
Our verdict
Build both, and connect them at the artefact. The evidence graph’s derived-from edge is where lineage attaches: a graph node says this extract supports the bank reconciliation control, and the lineage chain says the extract came from this query against this system at this timestamp. Neither is sufficient alone and together they answer everything in this table.
The connection point is the derived-from relationship. If your evidence graph already records it, you have the beginning of lineage and the remaining work is capturing the query, the logic version and the as-at timestamp at each transformation.
Next step
Trace the chain, verify the links
Barzel FinOps Atlas builds the evidence graph, traces evidence and verifies chains — so the derived-from relationship carries the lineage rather than existing only in someone’s memory. Free sandbox tier.
Limits
Two.
- 01Lineage proves derivation, not correctness. A figure derived through a fully recorded chain from a wrong source is wrong with excellent provenance, and lineage will document that faithfully.
- 02It cannot be established retrospectively for a completed period. Capture starts working from the next transformation, and the current audit still relies on whatever was recorded at the time.
Common misconceptions
Four claims we hear regularly that do not survive contact with a real estate. Each is stated as we hear it, then corrected.
Keeping a copy of the working paper is sufficient evidence.
A copy proves what a value was. It does not prove where the underlying data came from, which query produced it, whether the transformation logic changed since the prior period, or whether the figure can be independently re-derived — and those are the questions increasingly being asked.
Lineage can be reconstructed during the audit if needed.
A reconstruction may well be accurate and it is an assertion about the past rather than a record from it. Each link must be captured at the moment of transformation, and the distinction between the two is one auditors are increasingly explicit about.
A variance between periods reflects business movement.
Not necessarily. A changed transformation — an edited spreadsheet formula — produces a variance identical in appearance to a business movement, and only a recorded logic version distinguishes them. Conflating the two is a reporting error rather than a documentation gap.
Spreadsheets are adequate as a system of record for material figures.
They are excellent analytical tools and poor systems of record: inputs are pasted rather than referenced, logic changes silently, versions overwrite, and attribution for a specific value is unavailable. For material recurring transformations, that combination breaks the chain.
Frequently asked questions
What is financial evidence lineage?
The recorded chain behind a reported figure: which source system held the underlying data and as at when, which query or extract was taken, what transformations were applied and with which logic version, which working paper produced the result, and which journal or disclosure it entered.
How is lineage different from keeping supporting documents?
Documents establish what a value was and who prepared it. Lineage establishes where the value came from, whether it can be re-derived, and whether the methodology changed between periods — questions a document store cannot answer however well organised it is.
What are the five links in a derivation chain?
Source system, extract, transformation, working paper or model, and statement entry. Each is a transformation with inputs and outputs that need recording at the point it occurs.
Which link most often breaks the chain?
The transformation link, which in most finance functions is a spreadsheet. Inputs are pasted rather than referenced, formula logic changes without record, versions overwrite, and attribution for a specific value is unavailable.
Why is recording the query as important as the output?
Because without the query nobody can obtain the same figure again. An extract whose output is retained and whose query is not becomes unreproducible, which is a materially weaker artefact than one that can be re-derived independently.
Can lineage be reconstructed during an audit?
Not as a record. A reconstruction may be entirely accurate while remaining an assertion about the past rather than evidence created at the time, and that distinction is increasingly drawn explicitly.
Why does logic versioning matter for reporting quality?
Because a variance caused by an edited transformation looks identical to a variance caused by the business. Without a recorded logic version the two cannot be distinguished, which makes it a reporting accuracy issue rather than a documentation preference.
What is bidirectional linking and why does it matter?
Recording both which sources fed a figure and which figures a source fed. It answers where a number came from and, equally usefully, which reported figures are affected when a source system is restated.
What integrity mechanisms should each link carry?
An as-at timestamp and system identity at source; the query plus an output hash at extraction; logic version and input references at transformation; a version chain with preparer at the working paper; a journal reference with bidirectional link at statement entry; and periodic anchoring over the whole chain.
Should spreadsheets be eliminated from material processes?
For material recurring transformations, yes — a system that records its own lineage is a different class of artefact. Spreadsheets remain excellent for analysis; the problem is using the same file as both an analytical tool and a system of record.
How do lineage and an evidence graph relate?
They are complements connected at the artefact. The graph records what supports which control and transaction and whether coverage is complete; lineage records how each artefact was produced. The derived-from relationship in the graph is where lineage attaches.
Does lineage prove a figure is correct?
No. It proves how the figure was derived. A number produced through a fully recorded chain from an incorrect source is incorrect with excellent provenance, and lineage will document that faithfully rather than catching it.
Glossary
- Evidence lineage
- The recorded chain of transformations from source data to a reported figure.
- Derivation chain
- The ordered set of links through which a figure was produced.
- As-at timestamp
- The point in time a source system was queried, required for reproducibility.
- Logic version
- An identifier for the transformation rules applied, distinguishing methodology change from business movement.
- Reproducible extract
- An extract whose query is recorded, allowing the same figure to be obtained again.
- Bidirectional link
- A relationship recorded in both directions, enabling forward impact analysis and backward tracing.
- Version chain
- An append-only sequence of working paper versions with preparer per version.
- Chain anchoring
- Periodically publishing a hash over the lineage chain to bound undetected reconstruction.
- Pasted input
- A value entered without a recorded origin, the primary cause of broken lineage.
- Provenance without correctness
- A fully documented derivation from an incorrect source.
Standards and entities referenced
Every named framework on this page resolves to a public definition. If you are checking our claims, start here rather than with us.
Sources and further reading
Primary specifications and standards this article relies on. Where a claim is our own operating judgement rather than something a standard states, the text says so.
- 01 · W3CW3C PROV-O — The Provenance Ontology ↗A standard vocabulary for entities, activities and agents — the model an evidence graph is a special case of.
- 02 · PCAOBPCAOB AS 1105 — Audit Evidence ↗The standard defining sufficiency, appropriateness, relevance and reliability of audit evidence.
- 03 · COSOCOSO Internal Control — Integrated Framework ↗The control framework auditors map financial process evidence against.
- 04 · Institute of Internal AuditorsInternational Standards for the Professional Practice of Internal Auditing ↗What internal audit is required to evidence, and the independence expectations around it.
- 05 · U.S. SECSarbanes-Oxley Act — Section 404 ↗Where segregation of duties becomes an externally audited control.
- 06 · WikipediaMerkle tree ↗The structure behind append-only logs whose history cannot be silently rewritten.
- 07 · IETFRFC 3161 — Time-Stamp Protocol ↗How a third party attests that a record existed at a point in time.
- 08 · ISOISO/IEC 27001 — Information security management ↗The ISMS baseline that agent-layer controls have to fit inside rather than beside.
Last reviewed 2 September 2026 by Mark Alex. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). Financial Evidence Lineage: Proving Where a Number Came From. Real Biz Digital. https://realbizdigital.net/insights/financial-evidence-lineage/
Try the mechanics on a live server
To watch an MCP server answer a structured request before you let one read your ledger — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
Barzel FinOps Atlas is this assurance layer, sold as a running product
Thirty tools covering close readiness and blocker detection, cash position, cash variance and cash-flow risk, transaction risk scoring, policy exception detection, control risk, finance approvals, and the evidence surface — evidence-to-control mapping, evidence graphs, evidence tracing, chain verification, missing-evidence detection, auditor request answering and audit packet generation. A free sandbox tier means the first readiness report costs nothing.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Free Sandbox | Free | 500 calls/mo · close readiness, blockers, evidence checks | Testing readiness scoring against one real close |
| Starter | $29/mo | 1,000 calls/mo · evidence mapping, cash position, approvals | A single entity running one governed close cycle |
| Growth | $99/mo | 5,000 calls/mo · evidence graph, audit packets, control risk | A controller’s team with an external audit each year |
| Business | $249/mo | 15,000 calls/mo · the full 30-tool surface | Multi-entity close with SOX obligations and continuous audit readiness |
| Enterprise | $799/mo | 50,000 calls/mo · everything in Business, scaled | Group-wide finance operations across many entities |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
The five Barzel servers, and which problem each one is sold for
One estate rarely needs all five. This is the honest mapping, so you buy the layer your problem actually lives in.
| Server | Sold for | Entry price | Where it sits |
|---|---|---|---|
| Barzel Central Gateway | Knowing and governing the estate: inventory, registry, routing, risk scoring, approvals, evidence | Free, then $10–$149/mo | Control plane — decides what may be reached, and by whom |
| BarzelVault | Stopping a specific dangerous action before it executes, with proof afterwards | $199–$3,999/mo | Decision point — evaluates the individual call before execution |
| BarzelOps | Running real business workflows across HubSpot, Xero, Gmail, Drive and Slack under approval | Free, then $19–$199/mo | Execution layer — does the work the policy allowed |
| Barzel FinOps Atlas | Attributing AI spend to agents, tools and outcomes, then forecasting and capping it | Free, then $29–$799/mo | Economics layer — what the estate costs per outcome |
| Barzel Scripture Intelligence | A free, credential-free public MCP server to test clients and inspect real protocol traffic | Free, unmetered, no signup | Reference implementation — safe place to learn the protocol |
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.