SaaS Revenue Recognition: ASC 606 Basics for Founders

SaaS revenue recognition is the process of recording income as your service is delivered to the customer, not when cash hits the bank. Under ASC 606 and IFRS 15, a SaaS company earns revenue over the subscription period, which means recognized revenue, cash collected, and MRR each tell a different story about the business.

What Is SaaS Revenue Recognition?

SaaS revenue recognition is the accounting discipline of recording revenue only as you deliver the promised service. You sell access to software over time, so the income is earned gradually across the term rather than on the day the invoice is paid. Two frameworks govern this globally: ASC 606 in the United States and IFRS 15 internationally. Both share the same core idea, that revenue is recognized when a performance obligation is satisfied, not when money changes hands.

For a monthly subscription this is simple: you recognize one month of revenue each month. For an annual prepaid contract the gap is larger, because you may collect twelve months of cash on day one but can only recognize one month of revenue per month served. That timing difference is the heart of why founders need to separate cash from revenue in their heads.

Why Does Recognized Revenue Differ from Cash and from MRR?

The short answer is that each number answers a different question. Cash tells you what landed in the bank, bookings tell you what customers committed to, and recognized revenue tells you what you have actually earned under the contract. MRR is a forward-looking operating metric, not a financial-statement measure. The table below separates them so you can see what each one measures, when it moves, and who relies on it.

Notice that a single annual deal moves cash and bookings on day one, builds deferred revenue immediately, and only trickles into recognized revenue over twelve months, while MRR jumps once and stays flat. None of these numbers is wrong; they simply describe the business from different angles.

How Does the Five-Step ASC 606 Model Apply to a SaaS Contract?

ASC 606 lays out five steps that map cleanly onto a SaaS subscription. The model forces you to decide exactly what you are promising and when each promise is fulfilled, which is where most early-stage confusion starts. We will run a hypothetical example: a customer prepays 12,000 dollars for one year of software access. This is a hypothetical example, not a representation of any specific customer.

1. Identify the contract. In our hypothetical example the signed order form for the 12,000 dollar annual term is the contract.
2. Identify the performance obligations. The obligation is a single promise: ongoing access to the software for twelve months. Support and updates are typically bundled into that one obligation rather than sold separately.
3. Determine the transaction price. The price is 12,000 dollars for the year, assuming no variable consideration in this simplified case.
4. Allocate the transaction price. Because there is one obligation, the full 12,000 dollars is allocated to it with no split required.
5. Recognize revenue as obligations are satisfied. You recognize 1,000 dollars of revenue each month as the customer receives access, until the 12,000 dollars is fully earned at month twelve.

The discipline here is that step five happens on a straight line only because access is delivered evenly. If you promised a one-time onboarding service plus twelve months of access, you would allocate part of the price to that distinct obligation and recognize it earlier when the onboarding is performed.

What Is Deferred Revenue and How Does It Work on the Balance Sheet?

Deferred revenue is a liability that represents service you have been paid for but have not yet delivered. In our hypothetical annual prepay, when the customer pays 12,000 dollars you record 12,000 dollars of cash and 12,000 dollars of deferred revenue. Each month you reduce deferred revenue by 1,000 dollars and record 1,000 dollars of recognized revenue, so the liability unwinds in lockstep with delivery.

A large deferred revenue balance is a genuinely good signal for cash, because it means customers have prepaid you, but it is neutral for revenue, since none of it is earned until you deliver. Founders sometimes panic at a big liability on the balance sheet, when in fact it reflects healthy advance collections. On cancellation the treatment depends on your terms: if you refund, you reverse both cash and deferred revenue; if the fee is non-refundable, the remaining deferred balance is typically recognized immediately as the obligation ends. A mid-term upgrade is handled by allocating the incremental price to the remaining term and recognizing it prospectively.

How Do You Handle Setup Fees, Discounts, Usage, and Multi-Year Deals?

Before you book any non-standard contract you should answer a consistent set of questions so the recognition treatment is deliberate rather than accidental. Walking through these per contract type keeps your schedule clean and audit-ready.

1. Is there a distinct performance obligation, such as a one-time implementation or setup fee, that is separate from the software access, or is it just a cost of acquiring the customer?
2. If a one-time implementation fee exists, is it satisfied at go-live, which would let you recognize it then, or does it overlap the term?
3. For annual discounts or ramp deals, are you allocating the blended price across the full term on a straight line, and are early low prices being smoothed rather than recognized at face value?
4. For variable usage fees, are you recognizing revenue as the usage is consumed rather than when the overage is contracted or invoiced?
5. For credits and refunds, are you reducing revenue in the period the credit is issued, and is the deferred balance adjusted accordingly?

In practice, one-time implementation fees tied to a distinct setup service are recognized when that service is performed, while ramp deals and annual discounts are spread across the contract on a straight line. Variable usage fees are recognized as consumed, which is why a contracted overage is not the same as earned revenue. The usage-based pricing model makes this consumption test especially important, since usage can swing month to month.

What Revenue Recognition Mistakes Do Early-Stage Founders Make?

The patterns repeat so consistently that they are worth listing up front. Each mistake distorts how the business looks to investors and to your own team, and most are easy to avoid once you name them.

• Calling collected cash revenue. Booking a 12,000 dollar prepayment as revenue on day one overstates earnings by 11 months and will not survive diligence.
• Reporting bookings as ARR to investors. A signed three-year deal is not three years of earned recurring revenue, and mixing the two inflates your run-rate.
• Running no deferred revenue schedule. Without a contract-by-contract schedule you cannot reconcile the balance sheet to the income statement.
• Treating usage overage as contracted revenue. Overage is only earned as it is consumed, so recognizing it early breaks the consumption principle.
• Using inconsistent definitions between the board deck and the accounting system. If MRR in the deck differs from the ledger, investors lose trust fast.

The fixes are straightforward: keep a deferred revenue schedule, define MRR once and use it everywhere, and separate cash, bookings, and recognized revenue in every report. A clear pricing strategy also helps, because cleaner pricing produces cleaner recognition.

What Does a Founder Need in Place Before a Diligence Process?

Investor and acquirer diligence will test your revenue numbers hard, so the goal is to make the story reconcile on the first pass. You want a reviewer to move from your board deck to your ledger without finding a discrepancy. That means having the mechanics documented and the systems tied together before anyone asks.

• A revenue schedule per contract showing start date, term, total price, deferred balance, and monthly recognized amount.
• A written revenue recognition policy that states your treatment of prepaid terms, setup fees, discounts, and usage in plain language.
• A reconciliation between your billing system and your general ledger that ties invoice totals to deferred and recognized balances each period.
• Consistent definitions of MRR, ARR, and recognized revenue used identically in every investor-facing report and in the accounting system.

Getting these four items in place early is far cheaper than reconstructing them during a live process. It also sharpens your own operating view, because the schedule forces you to see the business the way a buyer eventually will.

Key Takeaways

• Recognized revenue is earned as the service is delivered, governed by ASC 606 and IFRS 15, not when cash arrives.
• Cash, bookings, deferred revenue, recognized revenue, and MRR each answer different questions and should never be used interchangeably.
• Deferred revenue is a liability that unwinds monthly and signals prepaid cash strength rather than earned income.
• The five-step ASC 606 model applies cleanly to SaaS through contract, obligations, price, allocation, and satisfaction.
• The most common founder mistakes are booking cash as revenue and reporting bookings as ARR to investors.
• Before diligence, keep a per-contract schedule, a written policy, a billing-to-ledger reconciliation, and consistent metric definitions.

Frequently Asked Questions

What Is the Difference Between Deferred Revenue and Recognized Revenue?

Deferred revenue is a liability on the balance sheet representing payments you have received for service you have not yet delivered. Recognized revenue is the portion of that service you have actually earned by delivering access over time, recorded on the income statement. In a hypothetical annual prepay of 12,000 dollars, deferred revenue starts at 12,000 and falls by 1,000 each month while recognized revenue rises by the same amount, so the two move in opposite directions until the contract ends.

Is ASC 606 the Same as IFRS 15?

The two frameworks are converged and follow the same five-step model, so for most SaaS subscriptions the recognition outcome is effectively the same under both. ASC 606 applies to US generally accepted accounting principles, while IFRS 15 applies to international financial reporting standards used outside the United States. A founder selling only in the US will typically work under ASC 606, but multinational customers and future acquirers may expect your numbers to be reconcilable to IFRS 15 treatment as well.

How Is Annual Contract Value Related to Revenue Recognition?

The annual contract value is a commercial metric describing the normalized yearly value of a contract, while revenue recognition is the accounting process of earning that value over the term. Annual contract value tells you the size of the deal, but it does not tell you when revenue is booked; a one-year 12,000 dollar contract has annual contract value of 12,000 yet recognizes only 1,000 per month. Keeping the two separate prevents the common error of treating a contracted value as earned revenue before delivery.

Do Usage-Based Contracts Change How Revenue Is Recognized?

Yes, variable usage fees are recognized as the usage is consumed rather than when the contract is signed or the overage is invoiced, which keeps recognition tied to delivery. Fixed access fees in a usage-based plan are still recognized on a straight line across the term, while the consumption-based portion is earned month by month as customers actually use the service. This is why a contracted overage estimate should not be booked as revenue until the underlying usage occurs and the obligation is satisfied.

This article is general information, not accounting, legal, or tax advice, and a founder should confirm treatment with their accountant.