Revenue Recognition

Revenue recognition is the one accounting process where being right in principle and being right in practice are different problems. The five-step model is public, stable and thoroughly documented; the reason recognition projects overrun is almost never that the team misread the standard. It is that the contract data arriving from quoting and billing cannot support the model the accounting team designed, and nobody discovers the gap until the first period close runs on it.

Identify the contract, identify the performance obligations, determine the transaction price, allocate it, recognise as obligations are satisfied. That summary is available from every vendor glossary and every advisory firm, and reproducing it at length here would add nothing.

What those five steps do not tell you is which of them your systems can actually evidence. Steps two and four — identifying distinct performance obligations, and allocating price between them — are judgements that have to be expressed as data structures somewhere upstream, usually in a product catalog that was designed years earlier by people solving a different problem. The judgement is an accounting decision. Where it lands is a data-model decision. Recognition projects fail in the space between those two sentences.

A SaaS contract that bundles a platform subscription, an implementation project, a block of support hours and a training allotment is not automatically four performance obligations, and treating it as four because it has four line items on the quote is a common and expensive shortcut. The test has two limbs, and a promise has to clear both to be accounted for separately:

• Capable of being distinct — the customer can benefit from the good or service on its own, or together with resources already available to them.
• Distinct within the context of the contract — the promise is separately identifiable, and is not so integrated with, dependent on, or modifying of the other promises that the customer is really buying one combined output.

The second limb is the one that catches implementations. An implementation service that any competent partner could perform against a documented API is usually separately identifiable. An implementation service without which the platform does not function for that customer at all — heavy bespoke configuration, a required data migration, a build that materially modifies what the subscription delivers — is arguably a single combined obligation with the subscription, and recognising it as a separate obligation on delivery pulls revenue forward that has not been earned. The same two line items, on the same quote template, can fall on either side of that line depending on what was actually promised.

Once the obligations are set, the transaction price is allocated between them in proportion to standalone selling price. Where a product is routinely sold on its own at a consistent price, SSP is observable and the exercise is arithmetic. Where it is not — a module never sold separately, a service priced by negotiation, a bundled component that has no list price — SSP has to be estimated, and the standard constrains how.

In practice this means the SSP methodology has to be written down before it is configured, with the reasoning for each obligation recorded — because the question at audit is not what number the system produced, it is why that approach was the permitted one for that obligation.

This is the failure mode that generic revenue recognition content does not describe, because it is not an accounting failure. A performance obligation model in a revenue engine is only as good as whether the upstream billing structure resolves to it. If the accounting team has concluded that a bundle contains two distinct obligations, but the rate plan that bills it exposes a single charge, then the revenue system has nothing to allocate against. The model is correct and unimplementable at the same time.

The repair is almost always upstream and almost always more invasive than expected: splitting a charge on a rate plan that has live subscriptions against it means amending those subscriptions, which changes their billing history, which changes what the revenue engine already recognised. That is why catalog architecture belongs in the recognition design conversation rather than after it — the cheapest time to make the catalog match the obligation model is before either has customers on it.

Invoicing and recognition answer different questions — when payment is due, and when the obligation was satisfied — and they coincide only by accident. Annual upfront billing on a monthly-satisfied subscription produces eleven months of contract liability. Milestone billing on a project satisfied continuously produces revenue that is recognised before it is invoiced. Neither is unusual and neither is a problem, but a system configured on the assumption that the two schedules match will produce a deferred revenue balance nobody can reconcile.

• Subscription, satisfied over time — recognised rateably across the service period, independent of the invoice cadence.
• Usage or consumption — recognised as consumed, which requires the usage record to be reliable enough to be an accounting input rather than a billing convenience.
• Professional services, distinct — recognised as delivered, by output measure or input measure, and the choice has to be justified rather than inherited.
• Professional services, not distinct from the subscription — recognised with the combined obligation, not on delivery.

Audit-readiness is not a report. It is the ability to answer, for any recognised amount, three questions without assembling anything by hand: which contractual promise this relates to, which policy determined the timing and the allocation, and what the system did when the contract subsequently changed. Most recognition processes can answer the first two from documentation and fail the third, because the mid-term amendment path is the least tested part of any implementation and the most common in a real subscription book.

• A written performance obligation policy, and a record of the judgement made for each obligation type rather than the conclusion alone.
• A documented SSP methodology per obligation, including which estimation approach was used and why it was the permitted one.
• An amendment and modification path that has been tested, because prospective and cumulative-catch-up treatment produce different numbers from the same change.
• A traceable line from a recognised amount back to the contract, the obligation and the billing artifact — without a manual reconciliation step in the middle.