Revenue recognition principles: The 5 step model with examples

Revenue recognition exists to solve one very specific mismatch: the gap between when money changes hands and when it becomes earned revenue. A customer can pay for a full year of service upfront, and still, only a sliver of that payment counts as revenue that month. The rest has to earn its way onto the income statement, recognized in pieces as the promise behind it actually gets delivered.

This is where the five-step revenue recognition model comes in. It's the standard that all regional revenue variations agree on, which is rare, since accounting rules across regions don't usually do so cleanly. So whether your billing runs out of New York or Nairobi, the underlying logic holds while the finer print may shift bit by region.

Step 1: Identify the contract with a customer 

Before anything gets recognized, there needs to be an actual contract in place. It doesn't need to be a formal, signed document. It just needs to check a few boxes:

• Both parties have approved it.

• Each side's rights are clear.

• The payment terms are identifiable.

• It's probable that you'll actually collect the money.

Industry scenario: Management consulting

Say a consulting firm has been in deep, promising conversations with a client about a $500,000 strategy engagement. The partner leading the deal is confident, the scoping calls went well, and the client's internal team even started referencing the project in their own planning docs. None of that is a contract yet. Not until the master service agreement and statement of work are signed does this box get checked. If the client's budget gets pulled the week before signing, which happens more often than firms like to admit, there was never anything to recognize in the first place.

This step matters more than it might seem. Consulting and other long sales cycle businesses sometimes start counting revenue too early, based on a verbal nod or a confident forecast call, only to walk it back later once the paperwork stalls or the terms shift. So it pays to be strict here, even when the deal feels done.

Step 2: Identify the performance obligations in the contract 

A performance obligation is a distinct promise made to the customer. Here, you define all the services and products you are going to provide to the customer for the payment they made. You should also define whether you are going to bundle it (highly interdependent) or if you're going to offer them separately (separately identifiable) based on the nature of the service or product delivery.

Industry scenario: Smart home security

A smart home security company, selling a camera system bundled with a year of cloud video storage, has the two items (the physical device and the ongoing monitoring subscription) in one order.

Why separate these in terms of revenue at all? Because they behave completely differently. The camera is a one-time transfer of a physical good, it's done the moment it ships and "control passes"to the customer. The subscription, on the other hand, keeps delivering value every day the footage is accessible on the cloud. Lump the two together as one obligation, and the revenue gets recognized at the wrong pace entirely, usually too early, since hardware ships quickly and subscriptions are ongoing. This applies to any kind of subscription models.

This step also looks different depending on what's actually being sold. A furniture company shipping a custom-built desk might have just one obligation on its hands, while a company with recurring services, like memberships or access to SaaS, almost always ends up with two or more.

Step 3: Determine the transaction price 

This is the total amount of money you expect to receive for delivering on your promises. For simple contracts, it is just the fixed price on the invoice. For some, such as the ones with the usage-based billing models, future usage is called "variable consideration." While it seems logical to just "wait and see," accounting rules require you to estimate this total price on Day 1 to ensure financial reports are accurate.

Industry: Cloud infrastructure

This is almost never simple for cloud infrastructure providers, since most charge a flat platform fee plus usage-based overages that aren't known until the customer's actual consumption comes in.

Say a company charges $2,000 a month flat, plus a per-gigabyte fee for storage that runs over a set limit. That variable piece has to be estimated upfront, using either the most likely outcome or an expected value across possible outcomes, rather than waiting until the invoice closes to find out what it turned out to be.

This can be done by identifying how a peer group behaves, a customer's previous history, or a similar trustworthy pattern. Moreover, the Day 1 estimate is not locked in forever. You must review and update your usage predictions at the end of every month, adjusting your baseline calculation to match actual customer behavior as it happens.

Usage-based businesses deal with this constantly, since the "final" transaction price is genuinely a moving target until the billing cycle wraps.

Step 4: Allocate the transaction price to the performance obligations 

This is where the total price gets split across the obligations identified in the original contract or purchase agreement. It has to be based on the standalone selling prices of each line item.

Industry: Mobile telecom

A telecom carrier selling a $30-a-month service plan bundled with a "free" handset is the clearest version of this problem. The handset isn't actually free, its cost is baked into that monthly rate. If the phone would normally retail for $600 and the plan for $360 a year standalone, the carrier has to allocate the bundled price across both based on those standalone values, not book the whole thing as service revenue just because that's what shows up on the customer's bill.

The handset's $600 standalone price and the plan's $360 make $960 of total standalone value, so the $360 the customer actually pays gets split $62.50/$37.50 ($225 for the phone, $135 for the service). The $225 hits hardware revenue the day the phone ships, offset by a contract asset since nothing's been billed for it yet. Each $30 invoice books $11.25 as service revenue and burns down $18.75 of that asset, hitting zero as the contract ends.

This is where manual errors creep in most, especially for companies running multiple bundles and tiers at once. Mismanagement here understates hardware revenue and overstates service revenue for the life of every contract signed that way.

Step 5: Recognize revenue as (or when) the performance obligations are satisfied 

This is the step it all comes down to, because it decides when money finally counts as revenue on your books. The recognition happens when the service is said to be delivered; it's neither the contract initiation day nor the day the cash hits your bank account.

Industry: Airlines

An airline selling a ticket today for a flight three months out can't recognize that fare the day the card is charged. The obligation, flying the passenger from one place to another, isn't satisfied until the flight actually happens. So that cash sits as deferred revenue for months, only converting the day the plane takes off.

Compare that to the same airline selling an annual airport lounge membership. That obligation isn't a single event, it's access delivered continuously across the year. So that revenue gets recognized ratably.

This is the part that confuses people the most: two products from the same company, sold the same day, recognized on completely different timelines. Recognize the ticket revenue the moment the card is charged, and the books look great that month and wrong for every month until the flight actually happens.

Why this model matters beyond compliance 

The foundational five-step model runs on judgment calls while it tries to solidify as many touchpoints as possible, and regulators keep an eye on that. At the AICPA & CIMA Conference on Current SEC and PCAOB Developments in December 2025, revenue recognition was named as one of the areas the SEC continues to focus on closely in its filing reviews.

Getting revenue recognition right not only protects you from compliance scrutiny but also gives you (and your investors) an accurate read on how your business is actually performing, month over month, which is the real trend.

The tricky part is that as businesses scale, so do the number of contracts with bundled pricing, discounts, add-ons, and renewal terms, each carrying its own version of these five steps. Doing this manually across hundreds or thousands of contracts is where things start to break down, and where a platform built to automate revenue recognition, like Zoho Billing, becomes less of a luxury and more of a necessity. If you're exploring what compliant, automated revenue recognition could look like for your enterprise, connect with our experts to see how it fits into your existing workflows.