Revenue is recognized under ASC 606 when a performance obligation is satisfied — not when an invoice is issued, and not when cash is received (ASC 606-10-25-23 through 25-30). When billing and revenue recognition operate on separate data models, that distinction becomes a source of errors: revenue on the wrong date, allocations that don’t survive a contract modification, period-end adjustments that shouldn’t exist. The data flow from contract to invoice to recognized revenue requires a defined handoff at each stage, and those handoffs need to be formally owned — not discovered when the deferred revenue balance won’t reconcile.
Revenue recognition: ASC 606-10-25-23 through 25-30 · Right-to-invoice expedient: ASC 606-10-55-18 · Variable consideration re-estimation: ASC 606-10-32-14
Most revenue recognition problems that surface at audit don’t start in accounting. They start upstream, in a CRM deal closed with terms the billing system couldn’t represent, a contract modification processed in billing that never reached the recognition engine, or usage data that feeds invoicing but never reaches the revenue waterfall. Billing records what you’ve invoiced. Recognition records what you’ve earned. Those are different records, governed by different rules, and the distance between them is where errors accumulate.
Two Systems Answering Different Questions
A billing system answers one question: what does this customer owe us, and when? It tracks invoices, payment schedules, and collections. It’s built around the contract as a commercial document: what was sold, for how much, payable on what terms.
A revenue recognition engine answers a different question: what have we earned, and when did we earn it? It tracks performance obligations, satisfaction events, and the allocation of transaction price across those obligations. It’s built around the contract as an accounting document, not what was invoiced, but what was delivered.
The two systems share a source document but diverge from there. A customer prepaying for an annual subscription generates a single invoice but twelve months of ratable recognition. A usage-based contract generates invoices when usage is billed but requires an estimated variable consideration amount in the recognition model before any invoice exists. A contract modification generates a billing amendment and a recognition adjustment and the two adjustments follow different rules and often produce different numbers.
The architectural insight most finance teams reach too late
Recognition logic should drive billing outcomes , not be reconstructed from invoice data after the fact. Revenue recognition rules determine what can be invoiced and when, not the other way around. Companies that build recognition on top of billing data have inverted the dependency: when the contract changes, billing adjusts the invoice schedule and recognition must catch up. When the data model is designed the other way — with recognition logic determining what billing generates — the catch-up entries don’t exist.
What Data Needs to Flow — and When
Getting the data handoff right requires knowing which data elements matter at each stage of the revenue lifecycle. There are four points where data must transfer cleanly:
- Contract inception. Performance obligation identification, SSP allocation, and transaction price must reach the recognition engine before the first invoice is issued. If SSP allocation happens as a period-end adjustment rather than at contract setup, any mid-period modification compounds the error.
- Delivery and fulfillment events. Revenue recognizes when a performance obligation is satisfied (ASC 606-10-25-23 through 25-30) — a progress measure for over-time obligations, a delivery event for point-in-time. These events flow from fulfillment, implementation, CRM, or usage systems — not from billing, which records invoice events, not delivery events.
- Variable consideration updates. At every reporting period, variable consideration estimates must be revisited and the constraint re-evaluated (ASC 606-10-32-14). Updated usage actuals, revised bonus probabilities, and changed volume expectations feed this re-estimation. That data lives in CRM and usage platforms — not in billing.
- Contract modifications. When a contract changes, the modification must be classified under ASC 606-10-25-12 before billing adjusts the invoice schedule. The classification — separate new contract, prospective adjustment, or cumulative catch-up — determines how remaining transaction price is reallocated and whether existing deferred revenue is revised. Billing records what changed commercially; recognition determines what that means under the standard.
Where Revenue Recognition Data Flow Breaks Down in Practice
The failure patterns are predictable. Most teams encounter at least two of these before they build a formal data integration:
- Revenue recognized on invoice date, not delivery date. When the recognition engine pulls from billing, it picks up invoice timestamps. For over-time obligations, that produces lump recognition at billing milestones rather than ratable recognition over the service period. The catch-up at period-end is manual.
- Modifications processed in billing, invisible to recognition. A rep gives a discount on month 6 of a 12-month contract. Billing adjusts the remaining invoices. Recognition never hears about it. The deferred balance stays at the original amount; period-end reconciliation breaks; accounting makes a journal entry that should have been automatic.
- Usage data reaching billing but not recognition. For consumption-based contracts, usage flows to billing so invoices get generated correctly. If that same data isn’t flowing to the recognition engine, variable consideration re-estimation runs on estimates alone. The constraint calculation is operating without the actuals that already exist upstream.
- Multi-element contracts invoiced as a single line. When billing issues one invoice for a bundle — license plus implementation plus support — and recognition has to reverse-engineer the allocation from that invoice, the allocation should have flowed from the recognition engine to billing, not be reconstructed afterward.
The period-end manual adjustment problem
When the data flow has gaps, they show up as manual journal entries at close: revenue reclassifications, deferred revenue adjustments, variable consideration true-ups. Each entry is a data flow failure in disguise. More than one or two per period means the integration has a structural problem, not an accounting one.
What a Working Data Model Looks Like
A revenue recognition data model that can handle ASC 606 without manual workarounds requires five things:
- Contract as the master record. Every PO, SSP, and transaction price allocation lives at the contract level from inception. Modifications update this record, they don’t create parallel entries that need to be reconciled later.
- Event-driven recognition triggers. Revenue posts when a defined delivery or fulfillment event occurs, not when an invoice generates. The event catalog, what satisfies each PO type, is configured at contract setup.
- Usage data as a first-class input. For consumption-based contracts, usage data flows to the recognition engine on the same cadence it flows to billing. Re-estimation uses actuals, not just management estimates.
- Modification classification before invoice adjustment. When a contract changes, the recognition engine classifies the modification first. Billing adjusts the invoice schedule based on that output — not ahead of it.
- Single deferred revenue waterfall. One source of truth for billed-not-recognized, recognized-not-billed, and the period rollforward. Auditors ask for this; the answer shouldn’t require assembling it from three systems at close.
The rollforward connects directly to how contract assets and contract liabilities appear on the balance sheet. A contract liability (deferred revenue) arises when you’ve billed or collected before satisfying the related PO. A contract asset arises when a PO is satisfied but the right to payment isn’t yet unconditional. Both are driven by the recognition engine’s view of PO status — not by the billing schedule. Controllers who own the close own both balances; a data model that separates billing from recognition makes both harder to produce and harder to defend.
From an internal controls perspective, each handoff in the data flow, contract inception to recognition engine, fulfillment event to revenue posting, modification classification to billing adjustment, should be traceable and reviewable. If a given handoff is handled by a manual journal entry or a spreadsheet formula, that’s a control gap as much as a data gap. Auditors will ask about it; the answer should describe a system process, not a quarterly spreadsheet exercise.
Frequently Asked Questions
When does revenue recognize under ASC 606?
When a performance obligation is satisfied — over time (by a progress method) or at a point in time (when control transfers), per ASC 606-10-25-23 through 25-30. Invoice date is not a recognition trigger. The right-to-invoice expedient (ASC 606-10-55-18) is narrower than it sounds: it applies only when the invoiced amount directly corresponds to value delivered in the period, as with time-and-materials arrangements.
What is the difference between a contract asset and a contract liability?
A contract liability (deferred revenue) arises when billing or payment precedes satisfaction of the related PO. A contract asset arises when a PO is satisfied, but the right to payment is conditioned on completing something else. Both are driven by the recognition engine’s view of PO status — not by the billing schedule.
How should contract modifications flow to the recognition engine?
Classification under ASC 606-10-25-12 — separate new contract, prospective adjustment, or cumulative catch-up — should happen before the billing adjustment. The recognition engine determines how remaining transaction price is reallocated; billing adjusts the invoice schedule from that output. Reversing the sequence produces the deferred revenue errors that show up as manual entries at close.
What causes deferred revenue reconciliation to break at close?
Typically, one of three gaps: (1) modifications processed in billing before reaching the recognition engine, (2) usage data flowing to invoicing but not to variable consideration re-estimation, or (3) delivery events never triggering a revenue posting. Each appears as a manual journal entry — more than one or two per period points to a structural data flow problem.
When billing and recognition share a data model
The manual entries go away. Modifications flow through the recognition engine before billing adjusts. Usage data reaches variable consideration re-estimation automatically. The deferred revenue waterfall is a system output, not a spreadsheet. If your team is spending close week reconciling billing to recognition, the data architecture, not the accounting judgment, is the problem to solve. For a full guide to what ASC 606 requires of your revenue management platform, see the BillingPlatform Revenue Recognition guide.
