Every close, something doesn't reconcile. The deferred revenue balance is off, or a contract modification ran through billing three weeks ago and nobody updated the waterfall. You find the gap, make a journal entry, and close. Next month, same thing.
The entries aren't the problem. They're the symptom. The problem is structural: somewhere in the path from contract to recognized revenue, there's a handoff that isn't formally owned, data that flows to billing but not to recognition, or a sequence of events that runs in the wrong order. Here's where it usually lives.
You're Recognizing Revenue When You Invoice
It happens gradually, and then all at once. The billing system fires an invoice, accounting sees the event, and revenue gets recognized. It's not a deliberate policy decision — it's just how the workflow developed. Invoice date and recognition date ended up being the same field.
Under ASC 606, revenue recognizes when a performance obligation is satisfied — when control of a good or service transfers to the customer. For a subscription, that's ratably over the service period. For an implementation milestone, it's when the milestone is genuinely complete, not when you invoice for it. For a software license, it's when the license is delivered and the customer can use it, which may or may not align with invoice timing.
The practical test: pull three contracts and compare invoice dates to actual delivery or fulfillment dates. If they match in every case, it's worth asking whether that's because each obligation genuinely satisfies at invoicing — or because the workflow never distinguished between the two events. The former is possible for some point-in-time obligations, but it warrants verification rather than assumption. For over-time obligations the gap is usually obvious; for point-in-time it's subtler — an implementation invoiced at kickoff with a milestone genuinely completed three weeks later.
Modifications Hit Billing Before Anyone Touches the Recognition Engine
A customer calls to add ten seats mid-contract. Sales updates Salesforce. Billing amends the invoice schedule. Finance gets a notification via email. The recognition engine doesn't find out until someone runs the period-end reconciliation and notices the deferred balance is wrong.
This is the modification sequencing problem, and it's almost universal in companies that run billing and recognition separately. The commercial process moves fast — amending the invoice schedule is how you collect more money, so it happens immediately. The accounting process runs slower — classifying the modification under ASC 606-10-25-12, determining which scenario applies, recalculating the remaining transaction price allocation — those steps happen when accounting gets around to it.
By the time accounting catches up, the billing records and the recognition records are describing different contracts. The deferred revenue balance is based on the original allocation; the invoices reflect the amended deal. Reconciling the two is a manual exercise that shouldn't exist.
The fix isn't faster accounting — it's sequencing. Modification classification has to happen before the invoice schedule changes, not after. That requires a workflow where billing can't finalize a contract amendment until the recognition engine has processed the modification. Most billing systems aren't built that way by default; it has to be designed in.
Your Variable Consideration Re-Estimation Is Running on Guesses
For consumption-based or usage-variable contracts, the pattern is usually this: usage data flows from the product or platform to billing, invoices get generated accurately, and customers pay the right amount. Meanwhile, the revenue recognition engine is re-estimating variable consideration based on management's judgment about likely usage outcomes, because nobody built a pipeline from the usage platform to the recognition model.
ASC 606-10-32-14 requires re-estimation of variable consideration at every reporting period. The constraint test — is it probable that including this amount won't result in a significant reversal? — should be applied to an updated estimate, not to the same estimate from contract inception. If your recognition engine doesn't have access to actual usage data, it's making that judgment on stale inputs.
When actuals are available — sitting in the usage system that feeds your billing invoices — and you're not using them, that's a harder audit conversation. The data exists; it just isn't flowing to the right place.
The Deferred Revenue Schedule Is Still a Spreadsheet
A spreadsheet isn't inherently the problem — the problem is what it represents: a manual process that's harder to control, harder to audit, and slower to close. If the deferred revenue rollforward has to be assembled by hand — pulling invoiced amounts from billing, recognized amounts from the GL, reconciling the two by contract and period — it will be slow, error-prone, and a bottleneck every quarter.
The deeper problem is what that manual process reveals: billing and recognition aren't sharing a data model. If they were, the rollforward would be a system report. Every column in the spreadsheet is a data handoff that isn't automated.
The practical question to ask: how long does it take your team to produce the deferred revenue rollforward at close? If the answer is more than a few hours, the integration has a gap worth addressing — not because auditors require a specific system, but because a system-generated rollforward is harder to challenge than a manually assembled one.
The common thread across all four patterns is the same: billing and recognition are operating on different data, on different timelines, with different people accountable for each. The journal entries that show up at close are the reconciliation cost of that separation. Fixing them one by one — entry by entry, quarter by quarter — is treating symptoms. The structural question is whether your billing and recognition systems share a data model or communicate through a reconciliation spreadsheet. If it's the latter, the close surprises aren't going away.
Frequently Asked Questions
Why is recognizing revenue when you invoice a problem?
Because ASC 606 recognizes revenue when a performance obligation is satisfied, not when a bill goes out. For subscriptions, that's ratably over the service period. For milestones, it's when the milestone is genuinely complete. Invoice timing and obligation satisfaction timing may coincide, but that requires verification. If they always match in your system, ask whether the workflow ever separated the two events or defaulted to invoice date for everything.
How should contract modifications flow between billing and revenue recognition systems?
Modification classification has to happen before the invoice schedule changes. That means billing can't finalize a contract amendment until the recognition engine has processed the modification. In most billing systems this sequencing isn't built in by default. If billing and recognition are running on different timelines, the deferred revenue balance is describing a different contract than the invoice records.
What's the risk of running variable consideration re-estimation without actual usage data?
The constraint conclusion is based on stale inputs. If actual usage data sits in the billing system feeding invoices, and the recognition engine is estimating from management forecasts instead, the re-estimation process is producing conclusions that don't reflect what's actually happening. ASC 606-10-32-14 requires re-estimation with current information; estimates based on inception-date projections don't satisfy that.
What does a manual deferred revenue rollforward signal?
That billing and recognition don't share a data model. Every column in that spreadsheet represents a data handoff that isn't automated. A system-generated rollforward is harder to challenge in audit than a manually assembled one. If assembling the rollforward takes more than a few hours, the integration has a gap worth addressing.
What's the root cause of close surprises in billing-to-rev-rec workflows?
Billing and recognition operating on different data, different timelines, with different people accountable for each. The journal entries at close are the reconciliation cost of that separation. Fixing them one by one treats symptoms. The structural question is whether the two systems share a data model or communicate through a reconciliation spreadsheet.
