Revenue recognition is the accounting question that most commonly separates founder-maintained books from investor-grade books. Two startups with identical cash flow can report dramatically different revenue numbers depending on whether their accounting follows ASC 606 or not. The one that follows it wins the diligence conversation. The one that does not spends two weeks explaining itself.
This guide walks through the five-step ASC 606 model as it actually applies to SaaS companies, with the specific scenarios that trip founders up and how to handle each.
Why ASC 606 Exists
Before 2014, US GAAP had a patchwork of revenue recognition rules scattered across industry-specific guidance. Software companies followed one set of rules, telecom another, and construction a third. The standards were inconsistent and in some cases contradictory.
FASB and the IASB jointly issued ASC 606 (and its international counterpart IFRS 15) to create a single framework. For public companies, it became mandatory in 2018. For private companies, 2019. It is now the only defensible revenue recognition standard for any startup expecting institutional investment.
The core principle is straightforward: recognize revenue when you transfer promised goods or services to a customer, in the amount that reflects what you expect to be paid.
The five-step model operationalizes that principle.
The Five-Step Model
Step 1: Identify the Contract With a Customer
A contract exists when both parties have approved it, rights and payment terms are clear, the contract has commercial substance, and collection is probable.
For most SaaS companies, this is the signed order form or subscription agreement. A verbal handshake does not count. A trial period before a paid contract is signed does not count. A contract that is cancellable at will by the customer with no penalty often does not count as a full commitment -- more on this below.
The gotcha: Pilot-stage customers who are "on paper" but have not actually committed to pay. If the customer can walk away at any time without penalty, your contract term for revenue recognition purposes may be monthly, not annual, even if the paperwork says annual.
Step 2: Identify the Performance Obligations
A performance obligation is a distinct promise within the contract. For a typical SaaS contract, the performance obligation is access to the software over the subscription period.
Contracts with multiple elements get more complex. A contract that includes software access, implementation services, training, and ongoing support may have two, three, or four distinct performance obligations.
The test for "distinct": would the customer buy this element separately, and is it clearly separable from the other elements? If yes, it is a separate performance obligation.
The gotcha: Implementation services. If the software cannot function without your implementation team configuring it, the implementation is typically not a separate performance obligation -- it combines with the software access into a single obligation. That changes when revenue gets recognized.
Step 3: Determine the Transaction Price
The transaction price is what the customer has agreed to pay for the entire contract. For a simple $60,000 annual subscription, the transaction price is $60,000.
For contracts with variable consideration -- usage overages, performance bonuses, rebates -- the transaction price includes an estimate of the variable portion. The estimate uses either the expected value method (probability-weighted average of possible outcomes) or the most likely amount method.
The gotcha: Discounts tied to future events. If you discount year one of a two-year contract on the condition that the customer renews, the discount may need to be allocated across both years rather than taken entirely in year one.
Step 4: Allocate the Transaction Price to Performance Obligations
If the contract has one performance obligation, the entire transaction price goes to that obligation. If it has multiple, the price is allocated based on the relative standalone selling price of each.
For most SaaS contracts, this means:
- Software subscription: the largest share, allocated at standalone price
- Implementation (if distinct): allocated at standalone price, often discounted to reflect the bundled nature
- Training (if distinct): usually a small allocation
The gotcha: Setup fees. If you charge a $10,000 setup fee for a service that is not distinct from the software (i.e., the customer cannot use the software without it), the $10,000 is allocated to the software subscription and recognized over the subscription period, not upfront.
Step 5: Recognize Revenue When or As Performance Obligations Are Satisfied
For most SaaS subscriptions, the obligation is satisfied ratably over the subscription period. $60,000 annual contract translates to $5,000 per month of recognized revenue.
For services and one-time deliverables, revenue is recognized when the specific obligation is satisfied.
Common SaaS Scenarios, Worked Through
Annual Contract Paid Upfront
Customer signs a $120,000 annual contract in January and wires $120,000 that day.
Correct treatment:
- January cash receipt: $120,000 (recorded as cash)
- January revenue: $10,000
- Balance sheet at end of January: $110,000 in deferred revenue (a liability)
- February through December: $10,000 revenue per month, deferred revenue drawdown
What founders often do instead: Record all $120,000 as January revenue because the cash came in. This overstates January revenue by 12x and creates a growing mismatch with cash flow forever.
Multi-Year Contract With Annual Billing
Customer signs a 3-year contract at $100,000 per year, billed annually at the start of each year.
Correct treatment:
- Contract value is $300,000 (total performance obligation is 36 months of software access)
- Revenue is recognized ratably: $8,333 per month for 36 months
- In year 1, you invoice and receive $100,000; in year 2, another $100,000; in year 3, another $100,000
- Balance sheet treatment: deferred revenue builds as you receive cash, draws down as revenue is recognized
What founders often do: Recognize $100,000 in year 1 (the billed amount) and ignore the forward obligation. This understates year-1 revenue slightly and creates no problem -- until year 3 when billings drop. At that point, the revenue trend looks wrong because earlier billings should have been deferred across years.
Setup Fee Plus Subscription
Customer pays $10,000 setup fee plus $5,000 per month for 12 months.
Correct treatment (setup is not distinct):
- Total contract value: $70,000 ($10K setup + $60K subscription)
- Recognized ratably over 12 months: $5,833 per month
- Both the $10,000 setup and the $60,000 subscription flow through deferred revenue
Correct treatment (setup is distinct -- e.g., customer could use the software without it):
- Setup is a separate performance obligation
- $10,000 recognized when setup is complete (often month 1 or 2)
- $5,000 per month recognized for subscription
Most early-stage SaaS setups are not distinct. Defaulting to the "not distinct" treatment is usually correct.
Usage-Based Pricing
Customer signs a contract with a $2,000 per month minimum plus $0.01 per API call above 200,000 calls per month.
Correct treatment:
- $2,000 per month minimum is recognized ratably each month (ratable obligation)
- Usage overages are recognized when the usage occurs (variable consideration tied to actual usage)
- If month 6 sees 500,000 calls, recognize $5,000 in usage revenue that month ($2K base + $3K overage)
This is one of the cleanest scenarios because usage billing and revenue recognition align.
Free Trial Converting to Paid
Customer signs up for a 14-day free trial, converts to a monthly subscription on day 15.
Correct treatment:
- No revenue during the 14-day trial (no consideration expected)
- Revenue starts on day 15 at the subscription rate
- The trial is not a separate performance obligation because the customer did not pay for it
The gotcha: A common mistake is recognizing the first month of subscription revenue at the signup date even though the trial started 14 days earlier. The revenue and the subscription start date should align.
Contract Modifications
Customer upgrades from a $2,000 monthly plan to a $4,000 monthly plan mid-year.
Correct treatment:
- If the upgrade represents a distinct additional service at its standalone selling price, it is treated as a new contract from the upgrade date forward
- If the upgrade represents an expanded version of the existing service, the remaining performance obligation is re-measured and allocated across the remaining months
In practice, most SaaS upgrades are treated prospectively: old rate applies to periods before the upgrade, new rate from the upgrade forward.
The Bookings, Billings, Revenue Distinction
SaaS founders frequently conflate three different numbers. ASC 606 forces you to separate them:
Bookings. New contracts signed in a period. A $120,000 annual contract signed in January is $120,000 of January bookings.
Billings. Invoices sent in a period. If the January contract is invoiced upfront, January billings are $120,000.
Revenue. Value delivered in a period. January revenue from that contract is $10,000.
All three are legitimate metrics. Investors track all three. The definitions are not interchangeable, and your financial statements should distinguish them clearly. Once your definitions are locked down, use our free SaaS revenue forecast tool to project MRR and ARR over the next 24 months under different growth and churn assumptions.
What This Looks Like on Your Balance Sheet
A SaaS company that is ASC 606 compliant will typically have:
- Accounts receivable: invoices sent but not yet collected
- Contract assets: revenue recognized but not yet billed (rare for SaaS, more common with milestone-based services)
- Deferred revenue (liability): cash received but revenue not yet earned -- this is usually the largest balance
The deferred revenue balance is often 50 to 100 percent of annual revenue for a SaaS company that collects upfront. A $5M ARR company with annual upfront billing might have $3M to $4M in deferred revenue at any given moment.
Investors look at the deferred revenue balance closely. A growing deferred revenue balance signals healthy upfront collections. A shrinking balance can signal either churn or a shift toward monthly billing -- both worth understanding.
The ASC 606 Disclosure Requirements
For private companies, ASC 606 also requires specific disclosures in the financial statement notes:
- Disaggregation of revenue by type (subscription, services, etc.)
- Contract balances (receivable, contract asset, deferred revenue) with changes during the period
- Performance obligations, including transaction prices allocated to remaining obligations (RPO -- remaining performance obligations)
- Significant judgments in applying the standard
Early-stage startups often skip these disclosures. The moment you are audited for a Series A or beyond, the disclosures become non-optional.
Where Founders Go Wrong
The three most common ASC 606 mistakes in practice:
Recognizing upfront billings as upfront revenue. The most common, and the most visible during diligence. Accrual books should never do this.
Treating setup fees as distinct when they are not. Results in over-recognized revenue in month 1 and under-recognized revenue across the contract.
Ignoring variable consideration. If you have usage overages, rebates, or performance bonuses, estimating the variable portion is required. Recording only the minimum is conservative but incorrect.
All three create reconciliation gaps that surface in diligence. None are hard to fix if caught early.
What We Do for SaaS Clients
ClariFi's accounting layer applies ASC 606 automatically to every contract, separating subscription, setup, and usage revenue and posting the correct journal entries each period. Deferred revenue, remaining performance obligations, and all three top-line metrics (bookings, billings, revenue) are visible in real time.
If your books do not currently follow ASC 606, converting is typically a one-to-two-week project. Doing it before a fundraise is a very good idea. Doing it during one is a very bad one.
Book a free consultation if you want us to look at your current treatment and tell you what would change under a clean ASC 606 implementation.
