ASC 606 is the GAAP revenue recognition standard. Every SaaS company that wants audited financials — which is every venture-backed SaaS company — has to apply it correctly. Most don’t, until their first audit forces them to. This guide walks through what ASC 606 actually requires, how it applies to common SaaS scenarios, and where auditors most often find problems.
What ASC 606 is in one paragraph
ASC 606 (codified in the Financial Accounting Standards Board’s Accounting Standards Codification, Topic 606) replaced the previous revenue recognition guidance in 2017–2018. It introduced a single five-step framework for recognizing revenue across all industries: (1) identify the contract, (2) identify the performance obligations in the contract, (3) determine the transaction price, (4) allocate the transaction price to performance obligations, and (5) recognize revenue when (or as) the entity satisfies each performance obligation. The standard replaced industry-specific guidance with a principles-based model meant to apply consistently across software, services, manufacturing, telecom, and everything else.
What changed vs. ASC 605
ASC 605 was the previous regime. For SaaS, the practical changes that matter are:
- Identification of performance obligations is now explicit and prescriptive. Under ASC 605, software companies often bundled multiple deliverables together and recognized revenue ratably across the contract. Under ASC 606, each “distinct” performance obligation has to be identified separately, and revenue allocated to each based on its standalone selling price.
- Variable consideration is now estimable rather than ignored. Usage-based pricing, refundable amounts, performance bonuses — these now have to be estimated at contract inception, with a constraint to avoid significant revenue reversal.
- Customer acquisition and fulfillment costs must be capitalized in some cases. Sales commissions, in particular, may need to be capitalized and amortized over the customer life rather than expensed when paid.
- Disclosure requirements expanded significantly. Audited financials now require footnote disclosures on contract balances, performance obligations, and revenue disaggregation that didn’t exist before.
If you closed your last audit under ASC 605 and you’re moving toward your first GAAP audit, you’re not “switching” — you’re adopting ASC 606 for the first time, and the auditor will treat that adoption as a meaningful technical exercise.
Applying the five-step model to SaaS
Step 1: Identify the contract. A contract under ASC 606 is an agreement creating enforceable rights and obligations between the parties. For most SaaS companies, this is the signed MSA + order form, or the click-through subscription agreement. The contract has to be approved by both parties, have identified payment terms, and have commercial substance. Verbal commitments and pre-signed marketing pilots generally don’t qualify.
Step 2: Identify the performance obligations. A performance obligation is a promise to transfer a distinct good or service. For SaaS, the core performance obligation is “providing access to the software platform over the subscription term.” Other things that may be separate performance obligations depending on facts:
- Implementation services (often not distinct — the customer typically can’t use the software without implementation, so implementation is bundled with the subscription)
- Professional services or training (often distinct — the customer could buy them separately)
- Support and maintenance (usually not distinct — bundled with the subscription)
- Premium features or add-ons sold separately (distinct if they have independent functionality)
- Multi-year prepaid licenses (the prepayment of subscription doesn’t create a new performance obligation; it’s the same one)
The “distinct” test has two parts: (1) the customer can benefit from the good or service on its own, and (2) the company’s promise to transfer it is separately identifiable from other promises in the contract. Both have to be true for a performance obligation to be distinct.
Step 3: Determine the transaction price. For most simple SaaS contracts, this is just the contract value. It gets more complex when there’s variable consideration (usage-based pricing, performance bonuses), significant financing components (multi-year prepayments with discounts), or non-cash consideration. We’ll come back to these.
Step 4: Allocate the transaction price to performance obligations. If there’s only one performance obligation, this step is trivial — all the consideration goes to the one obligation. If there are multiple distinct performance obligations, you allocate based on relative standalone selling prices (SSPs). You have to establish SSPs for each distinct deliverable; if you don’t sell them separately, you estimate.
Step 5: Recognize revenue when (or as) each performance obligation is satisfied. For SaaS subscriptions, this is “ratably over the subscription term” because the customer is receiving and consuming the benefit over the period of access. For one-time deliverables (a custom integration with a clear delivery date), it’s at the point of transfer.
Common SaaS scenarios and how to handle them
Annual prepayments. Customer signs a 12-month contract on January 1 and prepays $120,000. Recognition: $10,000 per month ratably over the 12 months. The full $120,000 hits cash on day one; $110,000 sits in deferred revenue on the balance sheet at month-end and unwinds monthly.
Multi-year deals with discounts. Customer signs a 3-year contract at $90,000/year, total $270,000, with a 10% discount vs the list price ($100,000/year, total $300,000). Recognition: ratably over 36 months. The discount is allocated proportionally — there is generally no “front-loading” or “back-loading” of the discount.
Setup or implementation fees. A one-time $25,000 implementation fee charged at the start of a 12-month subscription. The key question: is implementation distinct? If the customer can’t use the software without implementation (which is usually the case), implementation is not distinct — it’s bundled with the subscription. The $25,000 is therefore recognized ratably over 12 months along with the subscription, not upfront. This is one of the single most common errors in pre-audit SaaS financials.
Professional services that are genuinely distinct. Training, optional integration consulting, custom analytics work where the customer could realistically buy these separately. These are typically recognized as services are delivered — either at the point of delivery (training session completed) or over time as work is performed.
Usage-based pricing. Variable consideration. You have to estimate it at contract inception. Most companies do this with an “expected value” approach — based on historical or expected usage — and apply a constraint to avoid recognizing revenue you might later have to reverse. For a usage-based contract with no minimums, revenue is generally recognized as usage is consumed, period by period.
Customer-specific customizations. If a feature is built specifically for one customer and they pay for it as part of a contract, the analysis depends on what’s built. If it’s a custom integration the customer effectively owns, the company may be recognizing professional services revenue at delivery. If it’s a custom feature that becomes part of the standard product, the company is generally recognizing subscription revenue ratably.
Contract modifications. A customer adds 50 seats mid-term. ASC 606 treats this either as a separate contract (if the addition is for distinct services at standalone selling prices) or as a modification of the original contract (if the addition is at a discount or affects existing terms). Modifications can be cumulative catch-up adjustments or prospective adjustments depending on the facts.
What auditors will flag
The five areas where SaaS revenue recognition most often goes wrong:
-
Setup fees recognized upfront. As discussed above, setup fees that aren’t separately distinct should be recognized ratably with the underlying subscription. Companies that recognize them upfront are inflating early-period revenue. Auditors will require restatement.
-
Multi-element arrangements without standalone selling prices. If you sell multiple deliverables together (subscription + premium support + onboarding) but you’ve never established what each one would cost standalone, the allocation step has no defensible basis. Auditors will require you to construct SSPs through analysis of similar transactions or market data.
-
Variable consideration ignored. Usage-based features, performance credits, refundable amounts treated as if they were fixed contracted value. Auditors will require an estimation methodology and a documented constraint.
-
Principal vs. agent for resellers. If you sell through resellers or marketplace partners, ASC 606 requires you to determine whether you’re the principal (recognize gross revenue, with the reseller’s commission as an expense) or the agent (recognize only the net commission as revenue). The principal-vs-agent analysis is fact-specific and often contested in audit.
-
Capitalized commissions handled inconsistently. Sales commissions are an incremental cost of obtaining a contract; under ASC 340-40, they may need to be capitalized and amortized over the customer life. Companies that expense commissions when paid (the cash treatment) and don’t establish a capitalization policy will have to do so during audit.
Documentation requirements
Even when the revenue recognition treatment is correct, auditors want to see the supporting documentation:
- A revenue recognition policy memo — a written document explaining how the company applies each of the five steps to its specific contracts. Updated at least annually, reviewed by the auditor at the start of each audit.
- A representative contract review — for each material customer type, a worked example showing how the policy is applied to that contract. Auditors will sample contracts and trace them through the recognition logic.
- Standalone selling price analysis — supporting how SSPs were determined for each distinct performance obligation in multi-element arrangements.
- Deferred revenue waterfall — month-by-month roll of deferred revenue showing additions (new bookings), reductions (recognized revenue), and the ending balance. Should tie to the balance sheet exactly.
- Variable consideration methodology — documented estimation approach for any usage-based or variable elements.
If you’re heading into your first audit and you don’t have any of the above, that’s where the first six weeks of audit prep will be spent.
What Pegacorn does
ASC 606 is one of the three areas where first audits most commonly go sideways (the other two being equity compensation and lease accounting). We’ve documented it for companies preparing for their first Big Four audit — written the policy memo, worked through their contracts, established SSPs, and built the deferred revenue waterfall — and would be happy to do the same for yours.
If you’re 6 to 12 months from your first audit and your revenue recognition hasn’t been formally documented under ASC 606, we can help before fieldwork starts.