Most SaaS companies run 2 sets of revenue numbers and hope nobody asks about the gap.
There is the ARR number, built in the data warehouse from CRM and product data, which the board sees and the company manages against. And there is recognised revenue, built in the ledger from invoices and deferral schedules, which the auditor sees. They are calculated from different sources by different people on different cadences, and reconciling them is an annual event that everybody dreads.
The gap is not an accounting failure. It is the predictable result of recognising revenue in a system that never saw the contract.
revenue in the books at Tillo, across 750 to 900 invoices a month issued over the API
to process revenue at Famly, per Rasmus Vogt, the company's VP Finance
of the journal population an auditor extracts through the API, deferral entries included
The deferral schedule as a second ledger
Ask how deferred revenue works at a typical subscription business and the answer usually involves a spreadsheet: 1 row per contract, columns for each month of the term, a formula spreading the amount, and a journal entry posted monthly from the total.
That spreadsheet is a second ledger. It holds contract terms the general ledger does not have, it is maintained by hand, and it drifts. A contract amended in March gets updated in the CRM, invoiced correctly, and forgotten in the deferral model until somebody notices in Q4 that the release schedule no longer matches the invoice. Every finance team running this has a story about the reconciliation that took a week.
The fix is not a better spreadsheet or a bolt-on revenue tool that maintains its own copy of the same data. It is recognising revenue from the contract itself, so the schedule is derived rather than maintained.
When release is a property of the contract
Recognition runs off release templates attached to the contract. The contract knows its term, its amount and its billing rhythm, so the deferral unwinds month by month without a button to press and without a parallel model to keep in step. An amendment changes the contract, and the schedule follows because the schedule was never a separate artefact.
At Tillo the downstream effect shows up as timing: 750 to 900 invoices a month go out over the API with no review step, and revenue is in the books on T+1 rather than at the end of a cycle. At Famly, processing revenue went from 20 hours to 15 minutes.
750 to 900 invoices a month at Tillo, revenue in the books on T+1. At Famly, a 20 hour revenue process now runs in 15 minutes.
Old model
Maintain a schedule
A deferral spreadsheet holds contract terms the ledger does not have. Somebody updates it, posts from it monthly, and reconciles it when it drifts.
Light's model
Derive from the contract
Release templates unwind deferred revenue month by month from the contract itself. Amendments propagate because there is no second copy.
What changes
1 revenue number
ARR and recognised revenue derive from the same records, so the annual reconciliation between them stops being an event.
The question the auditor asks
Every SaaS finance lead has been asked to walk an auditor from an ARR number to audited revenue, and the exercise is unpleasant for a structural reason: the 2 numbers came from different systems, so the walk is a reconstruction rather than a trace.
When contracts, invoices, payments and recognition sit in 1 ledger, the trace is a lookup. An ARR figure resolves to the contracts behind it, each contract to its invoices, each invoice to the payment that settled it, and each period's recognition to the release schedule the contract generated. The auditor pulls 100% of the journal population through the API rather than sampling, and tests the calculation instead of rebuilding the inputs. Customers at $500M ARR have completed audits on this basis.
The practical value is not audit comfort. It is that the company stops carrying 2 stories about its own revenue.
Where the judgment still lives
None of this removes revenue recognition as a discipline. Multi-element arrangements, usage-based components, contracts with unusual terms and the genuinely debatable cases still require a decision, and they should.
What changes is the ratio. A finance team that spends most of its month maintaining schedules and reconciling models has very little time left for the handful of contracts that actually need thought. Deriving the mechanical majority from the contract is what creates room for the judgment on the rest, which is the work a revenue lead was hired to do and rarely gets to.
The companies furthest along here did not buy a revenue engine to sit beside the ledger. They put the contract in the ledger and let recognition fall out of it. The spreadsheet did not get better. It stopped being necessary.
See how contracts, billing and revenue connect in Light, or book a demo.