Most quote-to-cash diagrams show a clean line: quote, order, invoice, revenue, cash. In practice every arrow in that diagram is a handoff between two systems and usually two teams — and handoffs, not systems, are where quote-to-cash breaks.
The four handoffs that matter
Each handoff has a completeness test, and “the record arrived” is never it. What matters is whether the record arrived carrying everything the next system needs in order to act without a human filling in a gap from memory.
- CPQ to order management — does every approved quote become an order with its products, dated terms, discounts and approvals intact, with no re-keying?
- Order to billing — does billing receive the full charge model, not just a price: unit of measure, billing period, billing-day alignment, proration behaviour, effective dates?
- Billing to revenue — does every billed line map to a defined performance obligation, carrying the attributes the allocation rules key on?
- Revenue to the general ledger — does the journal run tie out without a manual plug entry?
If any one of those four requires a person to check or re-enter data, you do not have a quote-to-cash process. You have four processes bridged by whoever has time that week — and the quality of the bridge varies with the week.
What “complete” means at each boundary
The quote-to-order boundary fails on the things that are not price. Ramp schedules, co-termination dates, contracted minimums, and special terms captured in a free-text field that no downstream system can read. A quote that is correct as a PDF and incomplete as a data structure passes every human review and fails every automated one.
The order-to-billing boundary fails on charge modelling. Billing does not need to know what you sold; it needs to know how to rate it — which is a unit of measure, a billing period, an alignment rule, a proration policy and a set of effective dates. Teams discover which of those were never specified on the first mid-cycle amendment, which is exactly the wrong moment to discover it.
The billing-to-revenue boundary fails on missing attributes. Revenue rules group and allocate by reading fields on the transaction line. If the field that distinguishes a distinct service from a bundled one is not on that line, no amount of revenue configuration can recover it — the information was lost one system upstream, and the sub-ledger is simply the place where its absence becomes visible.
The revenue-to-ledger boundary fails on account determination and on timing. Accounting codes assigned per product rather than per obligation, periods closed in one system while open in another, and foreign-exchange treatment that differs between sub-ledger and ledger will each produce a difference that somebody plugs at nine in the evening on the third working day.
Every boundary needs a control, not just an integration
An integration moves data. A control proves the data arrived intact, and the two are not the same investment — which is why so many organisations have four integrations and no controls. The cheapest useful control at any boundary is a count and a value: how many records went in, how many came out, what the totals were, and what is sitting in the exception queue.
- A reconciliation that runs on a schedule, not on request
- An exception queue with a named owner and an agreed response time
- An alert on the reconciliation failing to run — not only on it finding a difference
- A retained record of what was reconciled, for as long as audit needs it
Who should own what
Sales operations typically owns CPQ and the quote-to-order handoff. Revenue or billing operations owns order-to-billing. Finance owns billing-to-revenue and the ledger reconciliation. That division is conventional and it works — but the ownership that actually matters is ownership of the boundary, not of the system on either side of it.
Name a person for each of the four boundaries and give them the reconciliation output. The moment a boundary has two half-owners, errors accumulate silently until close, because each side can quite reasonably believe the other one is looking.
Systems are owned. Boundaries are assumed. That asymmetry is the whole problem.
Where to start: trace ten real deals
Map your actual data flow, not your intended one. Pull ten real deals from the last quarter — deliberately including the awkward ones: a mid-term amendment, a multi-entity deal, a usage contract, and one that was cancelled and rebooked — and trace each one end to end, recording four things.
- Every system the record passed through, in order, with its identifier in each
- Every field that was populated by hand, and by whom
- Every point at which the record waited, and for how long
- Every correction made after the fact, and what triggered it
The manual touches you find are your actual quote-to-cash requirements. They will be far more specific than any generic process diagram, they arrive ranked by frequency for free, and they are defensible in a business case in a way that “we should automate quote-to-cash” never is.