Revenue recognition: when a sale becomes revenue (by industry)

A customer wires you $12,000 for a year of your software in January. How much of that is revenue this month? The tempting answer — all of it, the cash is in the bank — is the one that will quietly mislead you about your margins, your growth rate, and what your business is worth. The right answer is $1,000. The other $11,000 is money you've been paid but haven't yet earned.

That gap — between getting paid and earning it — is what revenue recognition is about. It's one rule with very different mechanics depending on what you sell, and it's the difference between books that tell you the truth and books that flatter you. Here's the rule, then how it lands for the four business shapes most founders are in.

Getting paid isn't the same as earning it

Cash answers when did the money move. Revenue answers a different question: when did you actually deliver the value you were paid for. Under accrual accounting — the basis every serious set of books and every standard (ASC 606, IFRS 15) runs on — revenue is recognized when it's earned, not when the cash arrives.

The two can land in the same month, or months apart in either direction. A customer who prepays a year is cash now, revenue later. A customer on net-30 terms is revenue now, cash later. The money you've collected but not yet earned sits on the balance sheet as a liability called deferred revenue — a promise you still owe in service, not income you get to keep counting.

The one rule: recognize revenue when you deliver the value

Strip away the accounting language and every standard says the same thing: recognize revenue as you transfer what you promised to the customer. The formal version (ASC 606) is a five-step test, and you can read it in plain English:

• Find the contract. An agreement, written or not, with real commercial substance.
• List what you promised.Each distinct good or service is its own "performance obligation" — software, setup, support, and training can each be separate.
• Set the price. The total the customer agreed to pay.
• Split the price across the promises. A $12,000 deal that bundles software and a one-time onboarding gets carved into the piece for each.
• Recognize revenue as each promise is delivered— all at once if it's a single hand-off, or spread over time if you're delivering continuously.

That last step is the whole ballgame, and it splits cleanly into two questions: do you earn this revenue at a point in time(you hand it over and you're done) or over time (you deliver it across weeks or months)? The answer is what changes by industry.

SaaS and subscriptions: earn it month by month

A subscription is the textbook case of earning revenue over time. You promise access for a period, so you earn the fee evenly across that period — "ratably," in the jargon. Collect $12,000 for an annual plan and you recognize $1,000 each month for twelve months. The cash showed up in January; the revenue shows up all year.

The roll-forward is the part worth seeing: cash stays put while the liability bleeds down into revenue, one month at a time.

Two wrinkles trip people up. A one-time setup or onboarding fee is usually its own performance obligation — if it delivers value on day one, you recognize it then, not smeared across the year. And usage-basedrevenue (per-seat overages, metered API calls) is earned as the usage happens, so it lands in the month it's consumed rather than evenly. The deferred-revenue balance, by the way, is why investors love subscription books: it's money already in hand for revenue you haven't even reported yet.

Software development and agencies: over time, or at the finish line

Project and services businesses — dev shops, design and marketing agencies, consultancies — sit on a fault line. The same studio can recognize revenue two completely different ways depending on how the deal is written:

• Over time, if you're building something the client controls as it's made, or that has no alternative use to you and you have a right to be paid for work done so far. Most custom development and retainers fall here — you earn revenue as the hours and milestones accrue, not at handover.
• At a point in time, if you're delivering one finished thing — a fixed-scope logo, a packaged template, a product you could resell — where the value transfers on delivery. Then nothing is earned until it ships, no matter how much you've been paid along the way.

This is exactly where a deposit bites. A 50% upfront payment on a fixed-scope build isn't revenue — it's deferred revenue until you deliver. Recognize it early and a great cash month masquerades as a great profit month, then the quarter you actually do the work looks thin. Match the revenue to the delivery and each month tells the truth about the work that happened in it.

Construction and long projects: percentage-of-completion

Construction, engineering, and any multi-month build take the over-time idea to its fullest form: percentage-of-completion. You don't wait until the building is done to book a year of revenue — you recognize it in step with how far along the job is. The most common gauge is the cost-to-costmethod: the share of total expected costs you've already incurred is treated as the share of the job you've completed.

Run that quarter by quarter and the revenue line follows the work, not the invoices:

The catch with cost-to-cost is that it's only as honest as your total estimated cost. If that estimate is wrong, your percentage is wrong, and your revenue is wrong — which is why long-project businesses re-forecast the cost to complete every period. A job that's headed for a loss has to recognize the whole expected loss the moment you see it coming, not when it lands. (Tiny jobs are the exception — a contractor with quick turnarounds may just book revenue at completion, the "completed-contract" method.)

Products, retail, and e-commerce: simple, until deposits and returns

Selling physical goods is the cleanest case: you recognize revenue at the point in time control transfers to the buyer — usually on delivery (or on shipment, depending on the terms). Cash and revenue mostly land together, which is why product businesses rarely carry much deferred revenue. Three things still pull them apart:

• Deposits and pre-orders are cash before delivery — deferred revenue until the goods actually go out.
• Gift cardsare a liability when sold, not revenue — you earn them only when they're redeemed (and estimate the slice that never will).
• Returnsmean you can't book 100% of a sale as final. You set aside a returns reserve so revenue reflects what you'll actually keep, not what rang up at checkout.

Why a founder should care

Revenue recognition isn't accountant box-ticking — it's what makes your numbers mean what you think they mean:

• Your margins read true. Recognizing revenue in the same period as the work that earned it is the matching principle in action. Book it early and the cost shows up later in a different month, and neither month's margin is real. It's the revenue side of how you read an income statement.
• Your growth rate is honest. Pulling a year of prepaid revenue into one month invents a spike and a cliff. Recognized properly, the trend line is the real one.
• It changes what you're worth. Buyers and investors value recognized, recurring revenue — and read your deferred-revenue balance as working capital they're effectively financing. Inflated revenue gets discovered in diligence, and it's an expensive moment to discover it.
• Taxes and covenants run on it. Lenders set covenants against recognized revenue and EBITDA; getting recognition wrong can trip a covenant or distort what you owe.

You don't need to memorize the standard. You need to know which bucket each of your revenue streams falls into — point-in-time or over-time — and let the books follow the delivery, not the deposit.