A certificate is only as good as the answer to one question: where did this number come from? In Olycor that answer is stored, not reconstructed, for every line on every report.
Source-level auditability means every figure on a borrowing base certificate or servicer report can be traced backward through the full chain that produced it: the output line, the rule version applied, the mapping decisions made, the row in the input file, and the file itself, with timestamps and responsible users at each step.
A lender funding against receivables is trusting a number the borrower produced. Field exams exist because that trust needs testing: an examiner samples invoices, traces them to source documents, reperforms the eligibility math, and reconciles the certificate to the aging and the GL. The single biggest driver of how long and painful that is, is whether the borrower can produce support on demand.
A spreadsheet-built certificate usually cannot. The file that fed it was overwritten at the next month end, the analyst who applied the exclusions applied them by hand, and the "support" is a pivot table nobody can regenerate. The examiner's finding is rarely fraud. It is almost always "unable to substantiate", which reads nearly as badly in a credit file.
Lineage flips that. When every exclusion is a stored decision and every line is a sum of identified rows, substantiation is an export, not an excavation.
Lineage is not a log bolted on afterward. It is the data model: each stage of the pipeline writes its part of the chain as it runs, so a certificate cannot exist without its own support.
Every input is stored as received, with a hash, an upload timestamp, and the account that supplied it. The certificate can always point back to the exact file version it was built from.
Each invoice in the pool keeps its coordinates: file and row number. No aggregation step loses the connection between a certificate line and the rows underneath it.
Which column became the due date, how the obligor name was matched into a group, how a credit memo was classified. Every interpretation, automated or human, is recorded as a decision.
Each eligibility test, concentration limit, and reserve formula runs as versioned configuration. The lineage records the rule, its version, the threshold, and the value it compared.
The output line is the sum of identified invoices, each carrying the full chain above. Open any number and the chain unrolls back to the source rows.
The June certificate shows $412,000 of cross-aged exclusions. The lender asks about one invoice inside that number. Here is the full chain Olycor returns for it.
| Input file | aging_detail_2026-06-30.csv, uploaded July 2 at 09:14, hash recorded |
| Row | Row 214: invoice 10482, $18,750, obligor "MERIDIAN COMP", due April 28 |
| Mapping | "MERIDIAN COMP" matched to obligor group Meridian Components LLC (match confirmed by J. Ortiz, June 4) |
| Obligor test | Meridian group balance $412,000, of which $224,000 is more than 90 days past due, so 54.4% past due |
| Rule applied | cross-aging v3.2: exclude all receivables of an obligor when more than 50% of its balance is 90+ days past due |
| Output line | Invoice 10482 lands in "Less: cross-aged obligors" with the other 11 Meridian invoices, $412,000 total |
Note what the chain contains: a human decision (the obligor match), a computed fact (54.4 percent past due), and a versioned rule (cross-aging v3.2 at a 50 percent threshold). Change any one of them and the outcome changes, which is exactly why each one is on the record.
The most common lender question is a variance question: eligible receivables fell $2.1 million, why? With lineage, the answer is a diff between two runs: 46 invoices aged past 90 days, one obligor group crossed the cross-aging threshold, and a $310,000 dispute flag came in from the ERP. Each item opens to its invoices. The response takes minutes and reads like the work of a team in control of its numbers.
Field exams change the same way. Instead of an examiner requesting twenty support schedules and waiting days for each, the borrower exports invoice-level support for any sampled line: source file, row, mapping decisions, rule evaluations. Exams get shorter, findings get rarer, and the credit file starts describing reporting as a strength. Olycor does not replace the exam or the lender's review, and it is not supposed to. It makes both faster to pass.
Olycor is an early-stage product handling sensitive financial data, and we would rather be precise than impressive. Certifications such as SOC 2 and ISO 27001 are on our roadmap and are not yet attested; we do not claim them, and you should not accept the claim from any early-stage vendor without a report. What exists today: encryption in transit and at rest, role-based access with separation between preparer and approver, tenant isolation, and audit logging of user and system actions. We share our current control documentation and roadmap with prospective customers under NDA, and we expect your security team to ask.
Or browse the full receivables finance glossary and the eligibility rule library.
Last updated July 9, 2026. Olycor does not provide legal, tax, accounting, or credit advice. Facility terms, eligibility criteria, and reserve mechanics vary by credit agreement; your agreement governs.
Olycor is onboarding borrowers who want every number on their certificate to carry its own support.