Source-level traceability
Source-level traceability means every figure on a certificate or report can be traced back to the input file it came from, the row in that file, the mapping decision that interpreted it, and the version of the rule that processed it. It turns a reported number into an evidence chain a reviewer can follow.
The question every reported number must survive
Sooner or later someone asks where a number came from. A credit analyst querying a $1.4 million drop in eligibles, a field examiner sampling invoices, an auditor testing the certificate. The answer cannot be that the spreadsheet says so. In a typical workbook, the figure is the output of formulas over a pasted extract, the extract was overwritten last month, and the analyst who built the tab has left. Reconstructing one number can take days.
Source-level traceability is the property that makes the question cheap to answer. Each figure carries its lineage: which file, which rows, which interpretation decisions, which rules, which rule versions. The number and its evidence travel together.
One excluded invoice, traced end to end
Take a single exclusion and walk the whole chain. Invoice 10482, Cascade Foods, $84,600, excluded from the June certificate. The trace reads: the invoice arrived in file AR_OPEN_2026_06.csv, received June 30 at 18:42, row 3,117. The column headed Due Dt was mapped to due date, a mapping decision approved on March 12 and unchanged since. The facility's aging rule, rule set version 2.3, makes invoices ineligible at 60 days past due. The invoice was due April 28, which was 63 days past due at the June 30 cutoff. Result: excluded, reducing eligible receivables by $84,600 and availability by $71,910 at an 85 percent advance rate.
Every link in that chain is a fact a reviewer can check: the file and its timestamp, the row, the mapping, the rule version, the arithmetic. Multiply by every invoice and every rule and you have a certificate that explains itself.
What full traceability requires
- Immutable input files: the exact bytes received, kept with a timestamp, not a working copy someone cleaned up.
- Row level identity: each invoice tied to the file and row it came from, surviving every transformation.
- Recorded mapping decisions: which source column became which field, who approved it, and when it changed.
- Versioned rules: the eligibility criteria, thresholds, and formulas in force for each period, so a rerun uses the rules of record.
- Deterministic calculation, because a trace is only meaningful if rerunning the inputs reproduces the output.
Olycor was built around this chain. Files are retained as received, every invoice keeps its file and row identity, mapping decisions are recorded and reviewable, rules are versioned per facility, and any figure on any certificate opens into its lineage. When your lender samples 60 invoices in a field exam, each one is a click, not an archaeology project.
Frequently asked questions
How is source-level traceability different from an audit trail?+
Can a spreadsheet based process be traceable?+
Why do rule versions matter for traceability?+
Ship certificates that carry their own evidence.
Olycor keeps the chain from every reported figure back to file, row, mapping, and rule version, so any question about a number takes minutes to answer.
Get early accessRELATED READING
Last updated 2026-07-09. This page explains general market practice. Your credit agreement governs how these concepts apply to your facility. Olycor does not provide legal, tax, accounting, or credit advice.