What is the difference between deferred revenue and ARR?

Deferred revenue is a balance sheet liability representing cash received but not yet earned — it decreases as you recognize revenue. ARR (Annual Recurring Revenue) is a forward-looking operational metric representing the annualized value of active subscriptions. They are related but different: deferred revenue reflects historical collections, while ARR reflects the current run-rate value of your customer base. ARR is not a GAAP concept and does not appear in your financial statements.

Do early-stage startups need to follow ASC 606?

Yes, if you are a US-based company preparing GAAP financial statements. All US entities — including private companies — are subject to ASC 606. However, the complexity of your implementation should match your business complexity. A simple monthly subscription SaaS with no professional services can apply ASC 606 with straightforward ratable recognition. Private companies also benefit from certain practical expedients that reduce documentation burden.

How do I handle a customer who cancels mid-subscription?

Your recognition policy for cancellations depends on your contract terms. If you offer refunds for unused subscription periods, you need to account for variable consideration and may need to reverse previously recognized revenue. If subscriptions are non-refundable, recognize revenue through the end of the contractual period even after cancellation. Update your deferred revenue schedule accordingly and document your cancellation accounting policy for auditors.

What is standalone selling price (SSP) and why does it matter?

SSP is the price at which you would sell a distinct performance obligation separately to a customer. It matters because when a contract includes multiple performance obligations (e.g., subscription + implementation), you must allocate the total contract price across obligations based on their relative SSPs. Incorrect SSPs produce incorrect revenue allocations between periods and between P&L line items, which can misrepresent your gross margin and revenue by segment.

How often should we update our revenue recognition policy?

Review your revenue recognition policy at least annually, and immediately whenever you introduce new products, pricing models, or contract structures. Material changes to your business — adding professional services, moving to usage-based pricing, bundling multiple products — almost certainly require policy updates. Your policy should be reviewed by your auditors during your annual audit and approved by your board's audit committee or equivalent governance body.

How to Manage SaaS Revenue Recognition Under ASC 606

Why This Matters

Revenue recognition is the single most audited area of SaaS company financials. Get it wrong and you face restatements, investor mistrust, and potential SEC scrutiny. Get it right and you have clean, GAAP-compliant books that support fundraising, M&A processes, and eventual public market readiness.

ASC 606, the revenue recognition standard issued jointly by FASB and IASB, replaced the old software-specific rules (SOP 97-2) starting in 2019. The core principle is straightforward: recognize revenue when you transfer control of a promised good or service to a customer, in an amount that reflects the consideration you expect to receive. For SaaS businesses, this usually means recognizing subscription revenue ratably (evenly) over the subscription term — not when cash is collected.

The financial stakes are significant. A SaaS company that collects $120,000 for an annual subscription in January should recognize $10,000 per month over 12 months, not $120,000 upfront. The unrecognized portion sits as deferred revenue on the balance sheet — a liability. Sophisticated investors and acquirers scrutinize deferred revenue schedules carefully. A company that has been recognizing revenue incorrectly will face painful adjustments that can dramatically change reported ARR and growth metrics.

This guide walks through ASC 606's five-step model as applied to SaaS businesses and explains how to handle the edge cases that trip up most companies.

Prerequisites / What You'll Need

Accrual-basis accounting (ASC 606 is incompatible with cash-basis books)
A revenue recognition policy document approved by your board or audit committee
A way to track contract start dates, term lengths, and performance obligations — either in your CRM, billing system, or a dedicated revenue recognition tool
Understanding of your product's distinct performance obligations (subscription access, setup fees, professional services, etc.)
A billing system that separates cash collection from revenue recognition (Stripe, Maxio, Zuora, or NetSuite)
For companies with $25M+ ARR: a dedicated revenue recognition tool (Maxio, Stripe Revenue Recognition, Zuora Revenue)

Step 1: Identify Contracts with Customers

Under ASC 606, you start by identifying whether a valid contract exists. A contract can be written, oral, or implied by customary business practices. It must meet five criteria: both parties have approved it, each party's rights regarding goods or services are identified, payment terms are identified, the contract has commercial substance, and it is probable you will collect the consideration.

For most SaaS businesses, the customer clicking "I agree" to your terms of service and providing payment information constitutes a contract. But edge cases arise: What about free trials that convert to paid? What about customers who are clearly unable to pay? What about contracts signed but not yet activated?

Document a policy for each scenario. Free trials typically do not create a revenue-generating contract until payment information is provided and the trial converts. Customers with significant collection risk may require you to defer recognition even after service delivery — or you should not recognize revenue until cash is collected.

Also consider implicit contracts created by your business practices. If you routinely provide refunds for cancellations outside your stated policy, the IRS and your auditors may treat your implied policy as the contract term for revenue recognition purposes.

Step 2: Identify Performance Obligations

A performance obligation is a promise to transfer a distinct good or service to the customer. "Distinct" has a specific meaning under ASC 606: the customer can benefit from the good or service on its own or with other readily available resources, and the promise is separately identifiable from other promises in the contract.

For a typical SaaS subscription, performance obligations might include:

Subscription access — the right to access the software over the subscription term (recognized ratably)
Implementation or setup services — if distinct, recognized as performed; if not distinct, bundled with the subscription
Professional services or training — typically distinct, recognized as services are delivered
Support and maintenance — often bundled with the subscription as a single performance obligation
Premium add-ons — recognized when the distinct feature is made available

The hardest question is whether implementation fees and professional services are distinct from the subscription. If a customer cannot use your software without implementation, implementation is not distinct and must be bundled — meaning you cannot recognize any revenue until implementation is complete, and then you recognize the entire contract ratably from that point forward.

Document your performance obligation assessment in your revenue recognition policy. Your auditors will ask for this documentation.

Step 3: Determine the Transaction Price

The transaction price is the amount you expect to be entitled to in exchange for transferring goods or services. For a straightforward annual subscription at a fixed price, this is easy. Complications arise with:

Variable consideration: Discounts, refunds, usage-based pricing, performance bonuses, or penalties. You must estimate variable consideration using either the expected value method (probability-weighted average) or the most likely amount method, and include it in the transaction price to the extent it is probable you will not have a significant reversal later.

Significant financing component: If payment is collected significantly before or after performance, you may need to adjust the transaction price for the time value of money. Most SaaS annual prepayments are within one year, so the practical expedient applies and you can ignore financing.

Non-cash consideration: Equity received in exchange for services, barter arrangements, or discounts given to one customer that affect another require special treatment.

Customer payment to you: Discounts, coupons, or credits you give customers reduce the transaction price.

For usage-based SaaS, the transaction price may not be known until the end of the period. In this case, you typically recognize revenue monthly based on actual usage — which aligns economic performance with recognition.

Step 4: Allocate Transaction Price to Performance Obligations

If your contract has multiple performance obligations (e.g., subscription + implementation + training), you must allocate the transaction price to each obligation based on relative standalone selling prices (SSP).

SSP is the price at which you would sell the good or service separately. If you sell implementation separately for $5,000 and subscriptions for $25,000/year, and you bundle them for $28,000, you would allocate:

Subscription: $25,000 / $30,000 × $28,000 = $23,333
Implementation: $5,000 / $30,000 × $28,000 = $4,667

Document SSPs for each performance obligation. If you do not sell them separately, you must estimate SSP using observable inputs, a cost-plus-margin approach, or a residual approach for highly variable prices.

Contract modifications (upgrades, downgrades, add-ons) must be assessed to determine whether they create a new contract or modify an existing one — and whether the modification is treated prospectively or as a catch-up adjustment.

Step 5: Recognize Revenue as Obligations Are Satisfied

Revenue is recognized when (or as) control transfers to the customer. Performance obligations are satisfied either over time or at a point in time.

Over time recognition applies when: the customer simultaneously receives and consumes the benefits as you perform (SaaS subscription access), you are creating or enhancing a customer-controlled asset, or you have no alternative use for the asset and have an enforceable right to payment for performance to date.

SaaS subscription access is the classic over-time example. A one-year subscription sold for $12,000 recognized ratably = $1,000 per month. This means you maintain a deferred revenue balance that decreases by $1,000 each month as revenue is recognized.

At a point in time recognition applies to one-time deliverables — a training session, a data export, a completed integration. Revenue is recognized when the deliverable is complete and control has transferred.

Step 6: Handle Edge Cases

Setup fees: One-time setup fees that are not distinct (customer cannot benefit without the subscription) must be deferred and recognized over the expected customer life — not just the initial contract term. This is longer than most companies realize.

Professional services: If distinct, recognize as services are delivered, typically on a percentage-of-completion or time-and-materials basis.

Usage-based pricing: Recognize based on actual usage each period. If you have a committed minimum, recognize the minimum ratably and the overage as it is incurred.

Annual contracts billed monthly: The contract term is still annual — do not treat each monthly invoice as a new contract.

Renewal options: If a customer renewal option gives a material right (e.g., a locked-in discount), it is a separate performance obligation requiring partial allocation of the initial contract price.

Common Mistakes to Avoid

Recognizing upfront fees immediately: Setup fees that are not distinct cannot be recognized at contract signing; they must be deferred and amortized
Not tracking contract modifications: Every upgrade, downgrade, or add-on is a contract modification requiring assessment under ASC 606
Using the wrong SSP: SSPs must be updated regularly as your pricing evolves; stale SSPs produce incorrect allocations
Ignoring multi-year contracts: A three-year contract at $10K/year is $30,000 total — recognize $833/month, not $10,000/year in a lump sum at each anniversary
Cash-basis revenue schedules: Never recognize revenue based on when invoices are issued or cash is received
Missing variable consideration constraints: Including variable consideration you are not highly confident you will receive creates risk of significant revenue reversals

Recommended Tools

Maxio (formerly SaaSOptics): Purpose-built SaaS revenue recognition and subscription analytics; excellent for complex multi-element contracts
Stripe Revenue Recognition: Automated ASC 606 compliance built into Stripe Billing; ideal for Stripe-native businesses
Zuora Revenue: Enterprise-grade revenue recognition for high-volume, complex arrangements
NetSuite ARM (Advanced Revenue Management): Strong for companies using NetSuite as their ERP
QuickBooks (manual): Workable for simple single-element subscriptions using deferred revenue journal entries; not scalable

Final Tips / Next Steps

Document your revenue recognition policy in writing — auditors will require this. Review it annually as your product and pricing evolve. Build a deferred revenue rollforward schedule (beginning balance + new bookings - recognized revenue = ending balance) and reconcile it monthly. If you are approaching a Series A or preparing for an audit, engage a SaaS-specialized CPA to review your ASC 606 implementation before auditors arrive — fixing issues proactively costs far less than restating financials.

How to Manage SaaS Revenue Recognition Under ASC 606