What is ASC 606 revenue recognition for SaaS?
ASC 606 recognises revenue as the service is delivered rather than when cash arrives, so an annual subscription billed upfront is carried as a deferred balance and released across the term it covers. Applying it — identifying performance obligations, allocating the transaction price and setting the recognition policy — is a technical accounting position for the company’s own CPA or auditor; bookkeeping records the result.
If your SaaS business bills customers annually but delivers the service monthly, you can't simply record the full annual payment as revenue the day it hits your bank account. That's the core idea behind ASC 606 revenue recognition, and it trips up a lot of early-stage SaaS founders.
The Basic Idea
ASC 606 requires revenue to be recognized as the service is actually delivered, not when cash is received. If a customer pays $12,000 upfront for an annual subscription, that revenue gets recognized at roughly $1,000 per month over the year — not all at once in the month they paid.
What "Deferred Revenue" Means
The portion of that payment not yet "earned" sits on your balance sheet as a liability called deferred revenue (sometimes called unearned revenue). It represents an obligation — you've been paid, but you still owe the customer months of service. As each month passes, a slice of that deferred revenue moves over to recognized revenue.
Why This Actually Matters
- Investors and boards expect it — recognizing all cash upfront overstates revenue in the month collected and understates it later, distorting growth trends.
- It affects valuation conversations — ARR and MRR calculations depend on revenue being recognized correctly over time, not lumped at collection.
- Cleanup gets expensive later — fixing years of incorrectly recognized revenue during a fundraise or audit is far more costly than setting it up correctly from the start.
The Five Steps, Briefly
ASC 606 is a single framework applied in five steps, and knowing the shape of it is enough to see why subscription businesses trip over it:
- Identify the contract with the customer.
- Identify the performance obligations in it — the distinct things you promised to deliver.
- Determine the transaction price.
- Allocate that price across the performance obligations.
- Recognise revenue as each obligation is satisfied.
Steps two and four are where most SaaS contracts get interesting. An annual subscription bundled with an implementation fee, onboarding support and a premium-support tier may contain several distinct obligations that are satisfied on different timelines, which means the single invoice does not map to a single revenue stream.
Where the Bookkeeping Actually Breaks
In practice the recognition principle is rarely the hard part. These four are, and all of them are maintenance rather than theory:
- Mid-term changes. An upgrade, downgrade or seat change part way through a term alters both the deferred balance and the remaining schedule. Where that is handled in the billing system but not in the ledger, deferred revenue slowly stops agreeing with the contracts behind it. The check that catches it is reconciling the deferred balance to the active subscription base — monthly, not annually.
- Implementation and setup fees. Whether these are a distinct performance obligation or part of the subscription changes when they are recognised. It is a judgment, it depends on the contract, and it is not one a bookkeeper should make alone.
- Usage-based and hybrid pricing. A platform fee plus metered usage is two patterns in one contract. Treating the whole invoice on one basis is the shortcut that causes the restatement.
- Credits, refunds and cancellations. These reverse into a period that may already be reported. A policy for how they are handled, decided once, is worth more than resolving each one on its merits.
What a Reviewable Deferred Revenue Schedule Contains
The test is whether someone who was not there can tie the balance to the contracts. That means, at minimum: opening balance, additions from new and renewed contracts, releases to revenue for the period, adjustments from mid-term changes, and closing balance — with the closing balance agreeing to the general ledger and to the subscription base, and each movement traceable to a contract rather than to a plug.
Where that schedule exists and reconciles every month, a diligence request is a document you already have. Where it does not, the same request becomes weeks of reconstruction at the least convenient possible moment — which is the actual cost of getting this wrong, and it lands during a fundraise or a sale rather than during a quiet quarter.
Where the Line Is
Choosing the accounting policy — what counts as a distinct performance obligation, how the price is allocated, how a particular contract is treated — is your CPA's and your auditor's, not your bookkeeper's. What can be prepared and maintained is the schedule that implements the policy, the reconciliation that proves it still ties, and the supporting detail a reviewer can follow. That split matters: this article is general information about a standard, not advice on how your contracts should be treated.
Getting This Right From the Start
This becomes more complex with usage-based pricing, multi-year contracts, or bundled products and services — each has its own recognition pattern under ASC 606's broader framework. The key is setting up your accounting system to track this automatically as contracts are signed, not trying to reconstruct it later.
See how we support technology and SaaS companies with revenue recognition and investor-ready reporting.
For CPA firms preparing the related reconciliations, close schedules and reporting packages, see our accounting and month-end support scope.