A customer pays you £12,000 upfront for a year of software. Your bank balance jumps by £12,000 today. So how much of it did your business earn today? The honest answer is: almost none. Revenue recognition is the set of rules that turns "cash received" into "revenue earned", and getting it wrong is how companies end up restating their accounts, missing their own forecasts, and confusing everyone who reads their numbers.

The quick version

  • Revenue recognition decides when you can record a sale as revenue. The core rule (accrual accounting): you recognise revenue when you deliver the service or goods, not when the cash arrives.
  • Two near-identical global standards govern it: IFRS 15 (international) and ASC 606 / Topic 606 (US GAAP). They were issued together in 2014 and share one five-step model, so the rule is almost the same worldwide.
  • For a subscription, upfront cash sits on the balance sheet as deferred revenue (a liability, you owe the customer service) and converts to revenue month by month as you deliver it.
  • You don't need to be an accountant. You need to know the difference between cash, billings and recognised revenue, because mixing them up is how leaders mis-read their own business.

The idea in depth: cash is a fact, revenue is a judgement

Two foundations sit under everything here. The first is accrual accounting: revenue is recorded when it is earned and expenses when they are incurred, regardless of when cash changes hands. Pay in advance for a year of service and the seller has the cash but hasn't earned it yet; they owe you eleven-and-a-bit months of delivery. The second is the matching principle: the costs of earning revenue should land in the same period as the revenue itself, so a period's profit reflects what actually happened in it rather than the timing of invoices.

For any non-finance leader, this is the habit worth building: stop reading the bank balance as a scoreboard. A flush bank account can mean you collected a year of subscriptions upfront, most of which you still owe as service. A thin one can sit beneath a perfectly healthy, growing revenue line. Ask three separate questions instead. How much cash came in? How much did we bill? How much did we recognise? Three different numbers, and only the third is revenue.

One model, two names: IFRS 15 and ASC 606

Before 2014, revenue rules were a patchwork, different industries, different countries, different answers to the same question. The International Accounting Standards Board (IASB) and the US Financial Accounting Standards Board (FASB) fixed that with a rare joint project, issued in May 2014: IFRS 15, Revenue from Contracts with Customers internationally, and Topic 606 (ASC 606) in US GAAP. They are substantially converged, the same five-step model with only minor jurisdictional differences, so a business reporting under either is doing nearly the same thing. IFRS 15 took effect for annual periods beginning on or after 1 January 2018; ASC 606 applied to US public companies from 2018 and most private companies a year later (per the IFRS Foundation and the FASB codification).

The standard's core principle, in the IFRS Foundation's own words, is that "an entity recognises revenue to depict the transfer of promised goods or services to the customer in an amount that reflects the consideration to which the entity expects to be entitled in exchange for those goods or services." Translated: recognise revenue as you deliver, in the amount you expect to keep. That principle is operationalised through five steps.

flowchart TD
  A(["1 · Identify the contract
with the customer"]) --> B(["2 · Identify the performance
obligations (what you promised)"])
  B --> C(["3 · Determine the
transaction price"])
  C --> D(["4 · Allocate the price across
each obligation"])
  D --> E(["5 · Recognise revenue as each
obligation is satisfied"])
The five-step model at the heart of IFRS 15 and ASC 606, the same sequence under both standards. Leaders Loop

The two steps that trip up leaders most are 2 and 5. Step 2, performance obligations, asks what distinct things you actually promised. A SaaS deal might bundle software access, a one-off onboarding implementation, and ongoing support: potentially three obligations, each recognised on its own clock. Step 5, satisfaction, asks whether each obligation is delivered at a point in time (you ship a product, you recognise it) or over time (a subscription delivered continuously across the year). Most subscription revenue is "over time," which is exactly why it spreads.

Which leads to a practical point most teams learn the hard way: whoever sets your pricing and contracts should talk to whoever reports the numbers before the deal is signed. The way a contract is worded, what is bundled, what is promised, whether a discount attaches to one element or all of them, changes when revenue can be recognised. Sales teams optimise for the signature. The accounting consequence is decided in the same sentence, and nobody in the room is usually thinking about it.

An honest limitation. The five-step model is principles-based, not a calculator. Several steps require genuine judgement, estimating "variable consideration" (discounts, usage-based fees, refunds you might owe), splitting a bundle by standalone selling prices nobody lists separately, deciding whether onboarding is a distinct obligation or just part of the subscription. Reasonable accountants disagree, and the standard's own application guidance runs to hundreds of pages. Treat revenue recognition as an area where you ask your finance team to explain their judgement, not one where a single right answer falls out of a formula. For anything material, this is a question for a qualified accountant in your jurisdiction, not a blog.

Subscription revenue: deferred revenue and the bookings–billings–revenue gap

Subscriptions are where the rules bite hardest, because they invert the usual order: you get the cash first and deliver the value later. When a customer pays upfront, you cannot count it as revenue. It lands on the balance sheet as deferred revenue (also called a contract liability or unearned revenue), a liability, because you owe the customer service you haven't yet provided. Each month you deliver, a slice moves off the liability and onto the income statement as recognised revenue (see NetSuite's SaaS revenue-recognition guide for the mechanics).

That single fact forces a vocabulary on anyone running a subscription business, because four numbers that sound alike mean different things:

flowchart LR
  A(["Bookings
value of contracts signed"]) --> B(["Billings
what you've invoiced"])
  B --> C(["Cash
what's actually been paid"])
  C --> D(["Deferred revenue
paid but not yet earned"])
  D --> E(["Recognised revenue
delivered, on the P&L"])
For a subscription, money travels from bookings to recognised revenue through a deferred-revenue holding pen, and the four numbers rarely match in any given month. Leaders Loop

The discipline here is simple: never let a board deck quote one of these and imply another. A team can have a record bookings quarter while recognised revenue barely moves, because most of those contracts will be delivered, and therefore recognised, over the next twelve months. A growing deferred-revenue balance is usually good news: it's future revenue you've already been paid for. But it is not profit, and it is not yours to spend freely, it's a promise outstanding. Leaders who conflate "we collected a lot of cash" with "we earned a lot of profit" make exactly the planning errors that the accounting was designed to prevent.

A growing pile of deferred revenue is the sign of a healthy subscription business, and it's a liability, not profit.

This is also why the recognition rules matter for trust. Because revenue timing involves judgement, it has historically been one of the most common places for accounts to be misstated, which is precisely why a single, converged, principles-based standard was worth a decade of work to the IASB and FASB. Consistent recognition is what lets an investor compare two subscription companies and believe the comparison.

A worked example

Take a company, call it Larkfield Software, selling a project tool on annual contracts. (Illustrative figures throughout; this is a teaching example, not real accounts.) On 1 January, a customer signs a one-year deal and pays the full £12,000 upfront. The contract bundles two promises: software access for the year, and a one-off onboarding setup that Larkfield delivers in January.

Walk the five steps. There's a clear contract (step 1). There are two performance obligations (step 2): the year of access and the onboarding. The transaction price is £12,000 (step 3). Larkfield allocates it by what each piece would sell for on its own (step 4), say an illustrative £1,200 for onboarding and £10,800 for the year of access. Then it recognises (step 5): onboarding is delivered in January, so its £1,200 is recognised that month; the £10,800 of access is delivered evenly across twelve months, so £900 is recognised each month.

The result reads very differently from the bank statement. On 1 January, Larkfield holds £12,000 in cash but records only £2,100 of January revenue (£1,200 onboarding + £900 access). The other £9,900 sits as deferred revenue, a liability, and converts to revenue at £900 a month through December. The cash arrived in a single lump; the revenue arrives in a thin, predictable stream. Read only the bank balance and you'd think Larkfield had a blockbuster January. Read the income statement and you see the truth: one steady, earned £900 a month, plus a one-off setup fee.

Frequently asked questions

What's the difference between revenue and cash flow?

Cash flow is money actually moving in and out of your bank account. Revenue is value you've earned by delivering goods or services, whether or not the cash has arrived yet. They diverge constantly: a subscriber paying a year upfront gives you cash now but revenue spread over twelve months; a customer on 60-day payment terms gives you revenue now but cash later. A business can be profitable on paper and still run out of cash, which is why leaders watch both, not one.

Are IFRS 15 and ASC 606 actually different?

Barely, by design. The IASB and FASB built them as a joint project and issued them together in May 2014, sharing the identical five-step model. A handful of narrow technical differences remain (around things like collectibility thresholds and certain licences), but for a leader's purposes you can treat them as one standard with two names, IFRS 15 if you report internationally, ASC 606 if you report under US GAAP.

Why can't I just recognise revenue when the customer pays me?

Because payment timing has little to do with when value is delivered, and accrual accounting exists to report the latter. If you booked all upfront cash as revenue immediately, a year of prepaid subscriptions would show up as one giant profitable month followed by eleven empty ones, a wildly misleading picture. Spreading recognition over the delivery period is what makes the income statement reflect the actual shape of the business.

Is deferred revenue a good thing or a bad thing?

Usually good. Deferred revenue is future revenue you've already collected the cash for, a backlog of promises you're confident you can deliver. A growing balance signals a growing subscription base paying upfront. The caution is that it's a liability, not profit: it represents service you still owe, so it isn't free money to spend, and it isn't earnings until you've delivered it.

I'm not in finance, how much of this do I actually need?

The vocabulary, not the journal entries. Know that cash, bookings, billings and recognised revenue are four different numbers; know that subscription cash is mostly a liability until earned; and know that how a contract is structured changes when revenue can be counted. With that, you can read a board pack honestly, ask your finance team sharper questions, and avoid the planning mistakes that come from treating the bank balance as the score.

Related in the Toolkit

Revenue recognition is the rule that decides what lands on the top line of your financial statements, and it's a textbook case of the difference between the rule-bound, external world of financial accounting and the internal numbers you actually steer by.

Where to go next