Financial Data Lineage: Making Every Analytical Number Traceable to Its Source

Define objects before drawing connections

A filename is not a lineage model. Nor is a workbook formula, report footnote, generic data catalogue, document confidence score or narrative reconstructed after calculation. A user-action audit log explains who clicked approve; unless it connects exact inputs, transformations and outputs, it cannot explain which evidence produced the approved number.

Give each object a stable identifier and each state an explicit version. Label the relationships: extracted from, transformed by, mapped to, calculated from, validated by, reviewed by, supports and used in. An untyped arrow hides whether two values are added, compared, reclassified or merely associated.

The W3C PROV data model provides a general vocabulary for entities, activities, derivation and responsible agents. The financial model here adds decision-specific meaning: reporting perimeter, accounting controls, materiality and approval. It is an Entimema methodology, not a claim of certification or a prescribed software implementation.

One evidence chain, two directions of inspection

Forward lineage asks: where did this source value contribute? Backward lineage asks: which evidence produced this reported value or finding? Both must work. A cash restriction may affect coverage, liquidity commentary and a funding recommendation; it need not affect gross margin. Dependency edges make that distinction explicit.

Register the source and location, preserve the observation, record extraction, retain transformations and map meaning before validating the value. Capture intervention, aggregate through explicit dependencies, then connect metrics to findings and decisions. This extends the FIR-05 analysis workflow with an inspectable evidence contract at every transition.

A document can support many fields, and one calculation can depend on several documents. The diagram is a readable view of a graph. Shared source nodes should be referenced, not copied into disconnected narratives whose histories later diverge.

Document provenance identifies the container; field lineage identifies the evidence

Register source identifier, file or system type, entity, reporting period, scenario, currency, unit, source system, received timestamp, version, owner and authority status. Keep an integrity identifier where implemented. A checksum can detect changed bytes; it does not establish accounting authority, completeness or economic truth.

A workbook may combine entities, hidden worksheets, comparative periods, calculated cells, pasted values, revised tables and inconsistent units. A PDF may contain subtotals, continuation tables, restatements and notes with different scales. Linking to either container leaves the reviewer to guess which observation was used.

The extracted record retains raw label, raw value, data type, sign representation, currency, unit, period, row and column context, extraction method, timestamp, confidence and source-location reference. Preserve a displayed dash as an observation until its meaning is established; converting it immediately to zero destroys the distinction between absence and amount.

For each material value, the reviewer must inspect origin, interpretation, transformation, mapping, passed controls, intervention, downstream uses, current version and earlier states. Successful document classification proves none of these individually. A confidently recognised Balance Sheet may still have cash scaled incorrectly, current and non-current debt reversed, the comparative column selected or restricted cash treated as available.

Extraction confidence therefore belongs to the field and method it describes. Mapping confidence addresses meaning; validation addresses defined constraints. The confidence and human-review framework keeps these separate. High confidence cannot repair a missing location or authorise an unsupported liquidity interpretation.

Preserve arithmetic changes and semantic changes separately

Every transformation event records input and output, type, rule, parameters, reason, timestamp, actor or process, version, reversibility, upstream references and downstream uses. Unit conversion is a multiplication; currency translation additionally requires rate source, effective date and convention. Neither permits replacement of the observed source value.

Sign normalisation, period harmonisation, monthly extraction from year-to-date flows, scaling, aggregation, splits, reclassification, elimination, normalisation adjustments, rounding and duplicate removal all need explicit operations. A monthly amount derived from two cumulative values depends on both snapshots and their comparable scope. An elimination depends on both counterpart populations and the approved matching rule.

Record whether an operation is reversible. Rounding and aggregation usually lose information if only the output survives; retaining inputs makes the path inspectable without pretending an inverse function can recreate them. Duplicate removal retains the excluded record and identity rationale, so a reviewer can distinguish deliberate exclusion from missing evidence. These controls extend financial data normalisation.

Canonical mapping is a semantic transformation with its own provenance. Retain source label and code, context, proposed and final concept, mapping type, scope, effective period, confidence, ambiguity, supporting evidence, alternatives, reviewer decision, mapping version and downstream impact. A numerically unchanged value can acquire a materially different meaning.

One-to-one and many-to-one mappings differ from splits, conditional, sign-dependent, entity-specific and period-specific rules. A split needs a supported allocation basis and a preservation check. An unresolved mapping is a valid state, not a defective record to conceal. Unknown values must not silently become zero, Other, the nearest label or the previous-period concept.

Reuse confirmed mappings only within their approved entity, account population, purpose and effective period. Contradictory current evidence reopens the rule even when its label and code are unchanged. The trial-balance mapping method explains why accounting balance cannot substitute for semantic validity.

A formula needs a population and an input version

Calculation lineage is the dependency graph connecting source-linked values to calculated results. Retain calculation identifier, formula or operation, input nodes and versions, output node, unit, period, currency, sign convention, calculation timestamp, deterministic rule version, validation result and rounding policy. A formula referencing whatever is currently in a cell cannot reproduce last month’s approved result.

The ratio requires compatible numerator and denominator populations and a defined zero-denominator treatment. Calculate using controlled precision, then round for presentation; do not feed a rounded displayed percentage back into another calculation. A validation result attaches to the tested versions, not indefinitely to a concept called Gross Margin.

Hundreds of accounts or thousands of transactions may contribute across entities and currencies. Retain every child reference or a reproducible governed query identifying the exact population. A query alone is insufficient when its underlying table changes: retain the data snapshot, query version, parameters, cut-off and membership evidence needed to recover the same rows.

Test population completeness, duplicate prevention, sign, unit, period, currency, mapping coverage and aggregation reconciliation. Retain explicit excluded populations and reasons. Adjustments and eliminations are separate nodes, never unexplained constants inside a total. Every material component must remain inspectable beyond the summary tab.

Equal totals can conceal offsetting omissions. Reconciliation establishes agreement under a test; it does not establish complete contributing-field lineage. Use deterministic validation alongside dependency coverage. The same discipline supports cash-flow reconstruction, where non-cash movements cannot be mistaken for cash evidence.

Traceability does not turn explanation into observation

A finding should identify supporting metrics, comparisons, calculation versions, materiality, evidence state and limitations. If it combines observation and inference, label each clause. “Available cash is below current debt” can be calculated; “the company cannot pay tomorrow” requires maturity, inflow, facility and payment-timing evidence that the ratio does not contain.

A hypothesis may remain open while a reversible information-gathering action proceeds. The action’s approval does not retrospectively validate the hypothesis. Financial KPI trees organise dependencies and competing explanations; lineage provides the evidence path needed to challenge each relationship.

Correct the current output without erasing how it became current

Reviewer intervention is a first-class event. Preserve the value before review, proposed interpretation, reason for review, evidence presented, alternatives, reviewer decision, resulting value or classification, permitted identity or role, timestamp, scope, version, downstream recalculations and approval status. A correction demonstrates that review changed the machine proposal; it is not evidence that the original proposal was accurate.

Distinguish confirmation, correction, reclassification, split, exception acceptance, override, rejection, abstention and request for evidence. Acceptance of a bounded limitation does not turn it into resolved evidence. An override must identify its authority and affected use; abstention must leave dependent conclusions blocked where the unanswered question is material.

Version source documents, fields, transformation rules, mappings, adjustments, calculations, analytical models, findings, reports and reviewer decisions. Each change event records event and object identifiers, prior and new versions, change type, timestamp, actor or process, reason, evidence, downstream invalidation and approval status.

Separate reporting effective time from processing time. A correction received in August may concern July. Store both meanings with an explicit time zone and event ordering; a timestamp alone does not establish which concurrent approval prevailed. Publish a coherent model snapshot, not a mixture of whichever inputs were most recently edited.

On upstream change, enumerate dependent outputs. Recalculate deterministic values, invalidate affected approvals and flag findings for review, or retain them explicitly as historical outputs tied to earlier inputs. Even an unchanged numerical result may need renewed review if its authority or classification changed. Never silently refresh an approved finding while keeping its old approval status.

Editable current state supports controlled correction. Historical record preserves observation, transformation, intervention, publication and later revision. An implementation claiming immutability needs evidenced storage permissions, retention, deletion controls, recovery and change-detection behaviour; an append-only table convention alone is not proof. This article claims no blockchain, write-once storage, cryptographic immutability or legally certified audit trail.

One cash finding, two critical evidence locations

Consider a fictional manufacturer assessing ordinary debt-service liquidity at 31 July. Every amount, location and event below is invented. Its registered population comprises a Balance Sheet PDF v2 in EUR thousands, a trial-balance Excel export v1 in EUR, a debt schedule v1, a restricted-cash note v1, a prior mapping rule M1 and one Controller intervention.

The PDF’s page 3, financial-position table, Cash row, current-period column contains 5,000. The note’s page 2, Restrictions table, ordinary-debt-service row, current-period column contains 1,200 EUR thousands. Both refer to the same entity and date. These are separate source locations; the note qualifies the cash population rather than adding another cash asset.

The fictional trial balance’s Cash worksheet, rows 8–10, closing-EUR column contains 2,400,000, 1,400,000 and 1,200,000. Their sum is EUR 5.0m. The debt schedule’s Maturity worksheet, closing-EUR column D, identifies current debt of EUR 5.1m in row 6 and non-current debt of EUR 5.4m in row 7. Coverage uses current debt only; total debt is EUR 10.5m.

At the fictional 09:00 UTC extraction event, retain the raw PDF field as 5,000 and its unit as EUR thousands. Transformation T1 multiplies by 1,000, producing EUR 5,000,000. A separately recorded application converts the note’s 1,200 into EUR 1,200,000. Canonical Total Cash reconciles to the three trial-balance children with zero residual.

Prior rule M1 proposes that every cash account is Available Cash, producing EUR 5.0m. The current note contradicts that interpretation. The workflow retains M1’s proposal, routes the EUR 1.2m restriction for review and withholds the dependent liquidity finding. It does not allow historical mapping convenience to override current evidence.

At 09:20 UTC, the Controller confirms that the note identifies cash unavailable for ordinary debt service. Intervention R1 records the contradictory note, rejected all-available alternative, unchanged total and revised classification. Approved mapping M2 applies to this entity, date and purpose; EUR 1.2m is Restricted Cash. This is one reclassification event, not an unexplained reduction in reported cash.

Pin the approved calculation to Total Cash TC1 v1, derived from PDF field E1 v1 through T1 v1, and Restricted Cash RC1 v2, derived from note field E2 v1 through scale event T2 v1 and reviewed mapping M2. Available Cash C1 v2 uses those two nodes. Coverage C2 v2 uses C1 v2 and debt field D1 v1 at Maturity!D6 in debt schedule v1. Finding F1 v2 references C2 v2, both cash branches and R1. These identifiers are illustrative, but their dependency contract is essential.

The source register records receipt and authority separately from approval. Here all four documents are accepted for the July snapshot before calculation; validation V1 records zero cash reconciliation residual against the retained trial-balance population. At 09:25 UTC, recalculation completes and F1 v2 is approved for the limited cash-versus-current-debt comparison. Approval does not extend to a daily funding forecast.

The earlier proposal implied approximately 98.0% coverage. M2 invalidates that proposal’s dependent finding; C1 v2 and C2 v2 are recalculated and reviewed. The original EUR 5.0m available-cash state remains historical. Total Cash is still EUR 5.0m: source agreement did not change, analytical availability did.

The EUR 1.3m difference is a point-in-time comparison, not a funding forecast or proof of default. Current debt is not necessarily payable immediately; future receipts, committed facilities and minimum operating cash remain outside this calculation. Treasury must align maturities and accessible inflows before recommending financing. The CFO can authorise that investigation without accepting an unsupported insolvency conclusion.

Completeness is necessary; decision sufficiency is separate

Assess seven dimensions: completeness of required connections; precision of field locations; reproducibility of outputs; integrity of retained states and interventions; currency of approved versions; interpretability of rules; and decision relevance of evidence. A technically complete graph may still lack the contractual information needed to establish cash availability.

Apply status to affected nodes and their dependent findings, not indiscriminately to the whole report. An unresolved liquidity restriction may block a borrowing recommendation while leaving a reconciled revenue comparison usable. Define who can accept limitations, for which purpose, until when, and what evidence would reopen the conclusion.

Test one material finding backwards to every contributor, then change one upstream version and inspect forward invalidation. Reproduce an older published result from its retained snapshot. Ask a reviewer unfamiliar with the preparation to locate the source and explain the adjustment. These tests expose both missing edges and technically complete but unusable evidence paths.

Controls that look complete can still conceal a broken path

The deliverable must carry its evidence architecture

For Entimema Financial Intelligence, lineage is a principal methodological differentiation layer: material values retain source context, transformations stay explicit, mappings preserve provenance, calculations retain dependencies, reviewer decisions remain visible, historical states are preserved and findings reconnect to validated evidence. Ambiguity is escalated rather than guessed. This is an architecture to scope and validate, not a claim that every control or integration is already deployed.

Model intelligence may interpret documents and fields, propose semantic mappings, detect ambiguity, suggest evidence relationships, request clarification and interpret financial relationships. Deterministic code owns transformations, arithmetic, aggregation, accounting controls, reconciliation, calculation dependencies, version propagation and fixed lineage rules. Human judgement owns material classification, policy-dependent mapping, authority conflicts, acceptance of limitations, intervention and the final management decision.

The month-end workflow governs when these states advance; management reporting determines which findings reach the CFO. Neither should detach the executive message from the evidence version that supports it. A delivered report needs stable finding references and an authorised inspection path, with source access governed by confidentiality and retention requirements.

Returning to the opening EUR 1.8m decline, the useful answer is an inspectable movement calculation, its exact inputs, transformations and review history. If that path is missing, reopen the conclusion instead of defending its formatting. The final analytical number is the visible endpoint of an evidence chain that must remain inspectable.