Order to cash is 5 links: the order, the invoice, the delivery of whatever was sold, the payment, and the recognition of the revenue. Almost nothing ever goes wrong inside a link. It goes wrong at the joins.
A contract closes in the CRM and somebody retypes the terms into the billing system. An invoice goes out and settles into a bank account that has no idea which invoice it settled. Revenue recognises on a schedule maintained in a spreadsheet that stopped matching the contract in March. Each system does its own job correctly, and the chain still leaks, because the leaks live in the gaps.
invoices a month Tillo issues over the API with no review step, revenue in the books on T+1
to process revenue at Famly, per Rasmus Vogt, the company's VP Finance
entities All Gravy runs collections across, handled by an agent
Join 1: contract to invoice
The most common leak, and the most expensive, because everything downstream inherits it.
All Gravy's contract terms were always too bespoke for standard tools to generate correctly, which is why invoicing stayed manual in e-conomic for years. Rather than accept that, the team built its own CPQ tool and connected it straight to Light. A contract closes in HubSpot and the invoice generates without anyone re-entering a number.
Oper Credits had the same problem from a different angle: every client on a bespoke contract, and a manual invoicing schedule in Excel per client per entity, chased monthly. Contract and invoice lived in separate places connected only by a spreadsheet somebody had to keep current. Now Light generates the invoice when it is due and the finance manager reviews and sends.
The test for this join is simple. If a contract amendment requires touching more than 1 system, the join leaks.
Join 2: invoice to cash
An invoice going out is only half of receivables. The other half is knowing what came back, which is why so many collections conversations start with somebody checking whether the customer already paid.
When payment settlement feeds bank reconciliation directly, cash ties back to the invoice it settled without a matching exercise in between. Dreamdata runs this on the outbound side, with a payment link on the invoice so the customer pays from the document they were sent and the settlement reconciles to it.
The consequence is that the receivables ledger is current rather than current as at last month-end, and the chase list contains genuinely overdue invoices instead of invoices that were paid last Tuesday.
Join 3: cash to chasing
Collections is the link that gets skipped when the week is busy, which is precisely why it should not depend on somebody having a free afternoon.
At All Gravy it used to mean downloading balances, assembling a list, reading back through the history with each customer, and writing every chaser by hand, across 4 entities. It now runs as an agent that tracks outstanding balances across all 4, reads the correspondence history, and drafts and sends the reminders.
"The dunning agent gives us the full picture of what is outstanding and handles the chasing. That used to be my afternoon."
Linea Meldgaard Andersen, Finance Analyst, All Gravy
Where it leaks
At the joins
Contract to invoice, invoice to cash, cash to recognition. Each system works. The handoffs between them are where the errors and the delay live.
What closes them
One record, five states
The order, invoice, payment and recognition are states of the same record rather than documents in 4 systems that need reconciling.
What it buys
Cash arrives sooner
Invoices go out on time because nothing assembles them, and chasing happens on schedule because it does not need a free afternoon.
Join 4: cash to recognition
The last link, and the one auditors care most about.
Deferred revenue traditionally lives in a spreadsheet holding contract terms the ledger does not have: 1 row per contract, columns per month, a journal posted from the total. It is a second ledger, maintained by hand, and it drifts the first time a contract is amended without the model being updated.
Recognition running off release templates attached to the contract removes the second copy. The deferral unwinds month by month without a button, and an amendment propagates because the schedule was never a separate artefact. Oper Credits gets this as a side effect of contract-based invoicing: because the system knows which period each invoice relates to, it defers the associated revenue automatically, with no end-of-month reconciliation between a tracker and the GL.
What good looks like end to end
Tillo is the clearest version. 750 to 900 invoices a month leave over the API with no triage in the UI, and revenue lands in the books on T+1 rather than at the end of a review cycle. Famly's revenue processing went from 20 hours to 15 minutes.
Neither of those numbers came from a faster order to cash tool. They came from removing the joins, so there is no reassembly step to introduce a discrepancy and no queue to review the discrepancies that a reassembly would have created.
The test worth running: pick a deal that closed last quarter and trace it to the cash and the recognised revenue. Count the systems it crossed and the times a person retyped something. That number is the honest measure of an order to cash process, and it is the number that determines how long the whole chain takes.
See how billing and revenue run in Light, read about the invoice queue, or book a demo.