Revenue Recognition: When Does a Sale Count?

The single most-argued question in accounting

You already know the headline from the income-statement rung: under the accrual basis, [[revenue|revenue]] is recorded when it is *earned*, not when the cash arrives. That one sentence settles the easy cases. But the real world serves up messier ones — a software seller who bundles a program, a year of updates, and a help line into one $1,200 price; a builder mid-way through a two-year bridge; a phone carrier that throws in a 'free' handset with a 24-month plan. For every one of these, the same blunt question returns: *how much revenue counts this period, and how much must wait?* Answering it well is what [[revenue-recognition|revenue recognition]] is about, and it is the single most-argued, most-restated, most-litigated topic in all of financial accounting.

Why does it matter so violently? Because revenue is the top line, and almost everything below it is judged against it. Pull a dollar of next year's revenue into this year and profit swells, the stock looks cheaper, a bonus target is hit, a loan covenant is met. The temptation to recognize too early, too eagerly, is enormous — which is exactly why the standard-setters fenced the question in with a precise, shared rulebook rather than leaving it to instinct. Get this guide and you hold the key that unlocks the entire revenue-and-receivables rung that follows.

Why "risk and reward" stopped being enough

For decades the old test was the [[realization-principle|realization principle]] phrased a certain way: recognize revenue once the *risks and rewards of ownership* have transferred to the buyer. For a baker handing a customer a loaf across the counter, that works beautifully — possession, risk, and reward all change hands in the same instant. The trouble is that modern commerce sells far more than loaves. When a sale bundles a product, a warranty, ongoing updates, and a return right, asking 'have the risks and rewards transferred?' gives a foggy, all-or-nothing answer to a question that is really about *several* separate promises, each fulfilled at its own time.

Worse, 'risk and reward' was vague enough to be gamed. Two companies in the same situation could read it differently, and an aggressive one could argue the risks had passed the moment it shipped a box — even if the customer could send it all back. The old US and international rulebooks had also drifted apart, so the very same transaction could show up as revenue in one country and not the other. So in 2014 the two standard-setters, the FASB and the IASB, jointly published a single converged standard — ASC 606 in the United States and [[ifrs|IFRS 15]] internationally — that replaced the foggy slogan with a structured procedure. It shifted the core question away from *'when did risk pass?'* to a sharper one: *'when does the seller satisfy each promise it made to the customer?'*

The five-step model, walked through once

The heart of the standard is the [[five-step-revenue-model|five-step revenue model]] — a checklist you run on every sale of any size. Do not let the word 'model' scare you; for a simple over-the-counter sale all five steps collapse into a single heartbeat, and you only feel the gears turn on the complicated bundles. Here is the whole machine in order.

1. Identify the contract. Is there a real agreement — approved by both sides, with rights, payment terms, and commercial substance, where collection is probable? A casual 'maybe I'll buy someday' is not a contract; a signed order or a clicked 'Place order' is.
2. Identify the performance obligations. Break the contract into its separate promises — each distinct good or service the customer could benefit from on its own. The software bundle splits into three: the program, the year of updates, the help line.
3. Determine the transaction price. Work out the total you expect to be entitled to — net of discounts, expected returns, and any variable bits — and excluding amounts you merely collect for others, like sales tax.
4. Allocate the price to the obligations. Split that total across the separate promises in proportion to what each would sell for on its own (its stand-alone selling price). A 'free' phone in a plan is not free — some of the monthly price is really paying for it.
5. Recognize revenue as each obligation is satisfied. Book each slice of revenue at the moment — or across the span — that its promise is kept. Some promises finish at a *point in time* (the program downloads); some are satisfied *over time* (the year of updates earns revenue month by month).

Steps two and five are the new heart of the standard, and the link between them is the idea you must carry away from this guide: a [[performance-obligation|performance obligation]] is one distinct promise inside a contract, and revenue is earned promise by promise, not contract by contract. That single shift — chopping a sale into its promises and recognizing each as it is kept — is what 'risk and reward' could never do cleanly, and it is why the new model can handle a phone plan and a bridge with the same five steps.

A worked bundle: the $1,200 software deal

Numbers make this concrete. On January 1st a customer pays $1,200 cash up front for a one-year deal: a downloadable program, twelve months of updates, and a help line for the year. Sold separately, those would price at $700, $360, and $140 — $1,200 in total, so here no discount needs allocating. Step five now does the real work. The program is handed over on day one: that is a point-in-time obligation, so its $700 is earned immediately. The updates and the help line are each delivered evenly across the year: those are over-time obligations, earning $360/12 = $30 and $140/12 ≈ $11.67 a month. On January 1st, only $700 of the $1,200 is revenue.

So what happens to the other $500 of cash you already hold? It is not yours to call revenue yet — you still owe a year of updates and support. It sits on the balance sheet as a liability called [[unearned-revenue|unearned revenue]] (deferred revenue): a promise of future service that you are paid for but have not yet delivered. Month by month you keep your promises, and that liability shrinks as the revenue is earned — the exact mechanism you met as a deferral adjusting entry one rung back, now seen from the revenue side. The sketch below shows day one and one ordinary month.

Stand-alone prices ->  Program 700 | Updates 360 | Support 140  (= 1,200)

Jan 1  (collect 1,200 cash; deliver program now)
  Dr  Cash ................. 1,200
      Cr  Revenue ............... 700   <- program: earned at a point in time
      Cr  Unearned revenue ..... 500   <- updates+support: still owed

Each month  (deliver 1/12 of updates and support)
  Dr  Unearned revenue ...... 41.67
      Cr  Revenue ............... 41.67  (= 30 updates + 11.67 support)

After 12 months: unearned revenue 500 -> 0; total revenue = 1,200

What changes — and what doesn't — when payment isn't cash up front

In the example the customer paid first, but the five steps care nothing about cash timing. Flip it: a consultancy finishes a $9,000 project in March and bills the client on 30-day terms. The performance obligation is satisfied in March, so all $9,000 is March revenue — even though no cash has moved. The other side of that entry is not cash but [[accounts-receivable|accounts receivable]]: a legal claim to be paid, an asset, recorded the instant the work is done. Cash up front parks money in a liability you owe; work done before payment parks it in an asset you are owed. Recognition tracks the *promise kept*, and the cash, whenever it comes, is just the settling-up.

One last honesty, because this field is full of traps. The five-step model is a disciplined framework, not a formula that removes judgement. How many obligations a contract really contains, what each would sell for alone, how far along a multi-year project is, how many goods will be returned — every one of these is an estimate made in good faith, and each is a place where an aggressive company can lean too hard. The point of ASC 606 and IFRS 15 is not to abolish judgement but to put a shared, transparent structure around it, so that two honest accountants reach the same answer and a dishonest one has fewer shadows to hide in. Mastery here is less about memorizing five steps than about seeing where the judgement lives.