Five Revenue Recognition Pitfalls Under ASC 606

ASC 606 sets out a five-step model, and by now most finance teams can recite it. The companies that still take findings under it rarely misunderstood the standard — their contract, catalog and billing data simply could not support it. Each of the five pitfalls below starts as an accounting judgement and quietly becomes a data-modelling problem.

The failures localise predictably. Steps two and four depend on how the product catalog is modelled. Step three depends on whether the rating engine can forecast as well as invoice. And the whole chain depends on whether a contract change is recorded as an amendment or as a cancellation and a rebook. None of that is judgement. It is configuration.

Step two asks whether a promised good or service is distinct, and the standard sets two tests that both have to pass: the customer can benefit from it on its own or together with resources readily available to them, and the promise is separately identifiable from the other promises in the contract. Fail either test and it is bundled with whatever it cannot be separated from, and the combined bundle is recognised as a single obligation.

In practice the argument is almost always about implementation services attached to a subscription. Implementation that configures the platform using capabilities a competent third party could also have delivered is usually distinct: the subscription works without it, it works without the subscription, and neither significantly modifies the other. Implementation that builds the integrations, migrations and data model without which the subscription delivers nothing is usually not distinct. Same line item, same invoice, opposite treatment.

The system-level failure is that this judgement has nowhere to live. Billing platforms model a contract as rate plans and charges. Revenue sub-ledgers group the resulting billing lines into revenue contracts and performance obligations using rules that key off transaction attributes — product, charge type, charge model, custom fields. If the catalog carries one undifferentiated “Implementation Services” product, the rule engine has nothing to test, and every engagement receives whichever treatment the default rule happens to encode.

So make the distinctness call at the catalog level rather than the deal level. Split the product, or carry an explicit attribute on the charge, and drive obligation grouping from that attribute. The accounting judgement is then recorded once, applied consistently by rule, and defensible in review — because a reviewer can read the rule instead of interviewing whoever booked the deal.

Allocation in step four is proportional to standalone selling price, and SSP follows a hierarchy. Where a good or service is actually sold separately, the observed price is the SSP and there is nothing to estimate. Only where it is not directly observable do you estimate — by adjusted market assessment, by expected cost plus a margin, or, in the narrow case where the selling price is highly variable or uncertain, by the residual approach.

The most common error is treating list price as SSP. List price is evidence of SSP only if you sell at it. If the great majority of deals close at a discount off list, the list price is a negotiating anchor rather than an observable standalone price, and an auditor will say so. What you need instead is a distribution of actual standalone transactions, refreshed on a defined cadence, expressed as a range with a written policy for what happens inside it and outside it.

That range matters mechanically, not just conceptually. A contract pricing an item inside the SSP range needs no reallocation; one pricing outside it does, and the discount is then spread across obligations in proportion to their standalone prices. Revenue sub-ledgers implement exactly this as an SSP catalog with effective dates and tolerance bands, reallocating automatically when a line falls outside the band — which only works if somebody maintains the catalog.

Effective dating is the part teams skip and the part audit asks about. The question is never “what is the SSP.” It is “what SSP was in effect on the date this contract was signed, and who approved it.” A spreadsheet that has been overwritten four times cannot answer that. A dated, versioned SSP catalog answers it in one query.

ASC 606 gives a modification three possible treatments, and the choice among them is not discretionary. If the modification adds distinct goods or services and the price increase reflects their standalone selling prices, it is a separate contract and the original is left untouched. If the remaining goods and services are distinct but the pricing does not reflect SSP, the original is treated as terminated and a new contract created, with the unrecognised amount plus the new consideration allocated prospectively across what remains. And if the remaining goods and services are not distinct — they form part of a single obligation that is only partly satisfied — the change is a cumulative catch-up against the existing schedule.

Subscription businesses hit all three routinely. A mid-term upsell adding seats at the same per-seat rate as the original is usually a separate contract. The same upsell at a deep, term-wide discount usually terminates and re-creates. A retroactive price correction applied to volume already delivered is usually a catch-up. Nothing in the sales conversation distinguishes them; only the pricing and the distinctness of what remains do.

That sentence explains the single most common structural mistake we see. When an operations team cannot get an amendment to do what they want, the workaround is to cancel the subscription and rebook it. Billing is satisfied — the invoices come out correctly. Revenue is not, because the sub-ledger sees a terminated contract and a brand-new one, and prospective treatment has been chosen for a change that may never have qualified for it.

Cancel-and-rebook also destroys the evidence. A genuine amendment leaves an ordered history of order actions and dated charge segments, and that history is the support for the accounting position. A cancel-and-rebook leaves two unrelated subscriptions and a gap where the reasoning used to be. Fix the amendment path in billing before arguing about the revenue treatment: the treatment is downstream of it.

Step three requires the transaction price to include variable consideration, estimated up front rather than discovered later. Two methods are permitted and they are not interchangeable. Expected value — probability-weighted across a range of outcomes — suits a large population of similar contracts. Most-likely-amount suits a binary or near-binary outcome. Whichever you use, the estimate is then constrained: you include it only to the extent that a significant reversal of cumulative revenue is not probable.

Usage-based businesses often skip this and recognise usage revenue as it is billed. That is legitimate only where the right-to-invoice practical expedient genuinely applies — where the amount you have the right to invoice corresponds directly to the value transferred to the customer to date. A flat per-unit rate usually qualifies. Several extremely common pricing shapes do not.

• Graduated tiers that reprice earlier volume once a threshold is crossed — month three's invoice no longer corresponds to month three's value
• Minimum commitments with overage, where the committed amount is earned on a different pattern from the usage consuming it
• Annual volume commitments settled by a year-end true-up, which is variable consideration for the whole year rather than a fourth-quarter event
• Banded discounts that depend on cumulative volume across several products or legal entities

Where the expedient does not apply, you need a rating engine that can forecast as well as invoice — one that can take contracted commitments and observed usage and produce an expected full-term amount, not merely this period's charge. That capability is the practical dividing line between a billing platform that can support ASC 606 for usage and one that can only bill it.

Then document the method, the constraint and the reasoning per contract type, and apply it identically every period. Auditors test the consistency of the methodology far harder than they test the arithmetic. An estimate that moves because the inputs moved is just an estimate; an estimate that moves because the policy moved is a finding.

The four pitfalls above share a root cause: recognition schedules built and adjusted by hand, with nothing connecting the number to the contract terms that produced it. The chain that has to survive is short, and every link in it is a real identifier — contract, performance obligation, allocated transaction price, recognition schedule, journal entry, general ledger account.

What an auditor does is sample in the hard direction. They take a revenue balance in the general ledger and walk it backwards to the clause in the contract that justifies it. In a system of record, that walk is a query. In a spreadsheet, it is a person reconstructing from memory a decision made eleven months ago by a colleague who has since left.

Retrospective change is where spreadsheets fail hardest. A cumulative catch-up requires every prior-period schedule for that contract to be recomputed and the difference booked in the current period, while the superseded schedule remains retrievable. That is an append-only problem, and a spreadsheet is an overwrite-only tool: once a cell has been changed, the prior position is simply gone.

What good looks like is unglamorous. Revenue contracts and obligations as first-class records. Schedules generated by rules rather than typed. Adjustments recorded as new entries rather than edits. A journal run that ties to the ledger without a manual plug. And the ability to answer “why is this number what it is” without opening a file. Fixing that chain is almost always the highest-leverage first step, because it is what makes the other four pitfalls visible while they are still cheap to correct.