ASC 606 for SaaS: The 5-Step Model Explained

Revenue recognition is the number one cause of financial restatements in software. It's also where SEC enforcement actions hit hardest. Most SaaS founders don't think about it until an auditor shows up asking questions they can't answer.

We went through KPMG's 770-page Revenue for Software and SaaS handbook so you don't have to. This is the stuff that actually matters for SaaS founders — no accounting jargon, no fluff.

The rules that govern when and how you count revenue live in ASC Topic 606 — a single standard that replaced a messy patchwork of industry-specific guidance in 2018. Whether you're billing $5,000 a month or $5 million a year, it applies to you.

What Is ASC 606 and Why Should SaaS Founders Care?

ASC 606 — formally, Accounting Standards Codification Topic 606, Revenue from Contracts with Customers — is the universal revenue recognition standard under US GAAP. Public companies adopted it in 2018; private companies in 2019.

Before 606, software companies had their own rules under ASC 985-605. The big requirement was VSOE — vendor-specific objective evidence. Sold a software license bundled with three years of support? You needed concrete proof (standalone renewal rates, typically) to separate the revenue. No VSOE? You'd often defer everything and recognize it ratably over the full arrangement. Rigid.

Topic 606 killed the VSOE requirement. More flexibility — but also more judgment. You now estimate stand-alone selling prices, assess whether components are "distinct," and determine the right recognition pattern for each piece. And you document the reasoning.

Here's what early-stage founders miss: your billing structure is making revenue recognition decisions right now, whether you're paying attention or not. That free trial? That bundled onboarding? That annual discount? All have accounting implications. Getting the foundation right while things are simple saves you from restatements later.

The 5-Step Model: How It Works for Subscription Businesses

Topic 606 uses one framework across every industry. Same five steps whether you're a construction company or a SaaS startup, selling a $99/month plan or a $2 million enterprise deal. What changes is how each step plays out for subscriptions.

Step 1: Identify the Contract

A "contract" under 606 isn't just a signed PDF. It's any agreement — written, verbal, or implied by how you normally do business — that creates enforceable rights and obligations. Click-through Terms of Service count.

Five criteria must all be met:

• Both parties approved and committed to their obligations
• Each party's rights to goods or services can be identified
• Payment terms can be identified
• The arrangement has commercial substance
• Collection is probable

That last one — collectibility — catches people. Sign a big enterprise deal but genuinely doubt they'll pay? You might not have a contract under 606. Cash received gets treated as a deposit, not revenue, until collectibility becomes probable.

Free trials don't create contracts. No enforceable payment obligations exist during a trial. The contract starts at conversion.

Month-to-month SaaS where either side can cancel without penalty: each month might be its own contract. The term isn't what your order form says — it's the period where enforceable rights actually exist.

Step 2: Identify the Performance Obligations (Where Most SaaS Companies Get It Wrong)

A performance obligation is a promise to deliver a distinct good or service. How many you identify here determines how revenue gets split. Mess this up and everything downstream breaks.

The "distinct" test has two parts — both must be true:

• Capable of being distinct — The customer can benefit from it on its own or with readily available resources.
• Distinct within the contract — The promise is separately identifiable. You're not using it as an input to a combined output.

How this maps to real SaaS deals:

Pure SaaS subscription — One obligation. Each month of access is substantially the same service — the standard treats it as a "series." Revenue recognized ratably. Clean.

SaaS + implementation — Could be one or two. Light onboarding (configs, data import, training) is usually distinct — the customer could hire someone else to do it. Significant customization that changes how the SaaS fundamentally works? Combined into one obligation. The line between "light" and "significant" is a judgment call auditors love to probe.

SaaS + post-contract support (PCS) — Technical support, updates, and upgrades are usually one obligation. If co-terminus with the SaaS (same end date), often combined with the SaaS entirely.

Setup activities — Data migration, environment provisioning, UI configuration — often not performance obligations at all. They don't transfer a service to the customer. They're prep work. Costs get capitalized under ASC 340-40 and amortized over the service period.

Don't assume a bundled deal is one bucket. Each promise needs the two-part test. The revenue pattern depends entirely on getting this right.

Step 3: Determine the Transaction Price (Not Always the Invoice Amount)

The transaction price is what you expect to receive for delivering your promised goods and services. Not always the number on the invoice.

Four things that commonly change the number:

Variable consideration — Usage overages, SLA credits, volume discounts, performance bonuses. Estimate using "expected value" (probability-weighted) or "most likely amount" (single best estimate). For simple overages, most companies use the most likely amount.

The constraint — Only include variable amounts where you're confident there won't be a significant revenue reversal later. Uncertain? Pull the estimate down. Adjust upward as things clarify.

Significant financing component — Payment timing differs significantly from delivery? You may need to adjust for time value of money. Practical expedient: gap of 12 months or less, skip it. Most SaaS billing qualifies.

Consideration payable to the customer — Referral fees, rebates, credits to customers — these reduce the transaction price. They're not a separate marketing expense. Companies with referral programs miss this.

Simple fixed-price subscriptions? This step is a formality. It gets complex with usage-based tiers, outcome-based pricing, or token-based models. AI companies billing by compute hours face a particularly tricky version — usage fees tied to IP licenses have their own rules.

Step 4: Allocate the Price to Each Obligation (The "Free Onboarding" Trap)

Multiple performance obligations? Divide the transaction price among them based on relative stand-alone selling prices (SSP) — what you'd charge for each if sold separately.

SaaS companies routinely bundle things and never sell them individually. No observable SSP for onboarding? Estimate using:

• Adjusted market assessment — What would the market pay?
• Expected cost plus margin — Your delivery cost plus reasonable profit.
• Residual approach — Only when SSP is genuinely highly variable. Allocate known SSPs first, assign the remainder.

Here's what founders miss: selling SaaS at $500/month with "free" onboarding doesn't make the onboarding free from an accounting perspective. It has an SSP. A portion of that $500 gets carved out and allocated to onboarding — recognized when delivered (upfront), not ratably with the subscription. Changes the shape of your revenue curve. Getting this wrong is one of the most common audit findings in SaaS.

Step 5: Recognize Revenue (Over Time vs. Point in Time)

Revenue hits your income statement when control transfers to the customer — over time or at a point in time.

Over time if any of these are true:

• Customer receives and consumes the benefit as you perform (SaaS access)
• Your work enhances an asset the customer controls as you build it
• No alternative use to you + enforceable right to payment for work done

None apply? Point in time.

SaaS subscriptions — Over time. Recognized ratably. $12,000 annual subscription = $1,000/month, regardless of when you invoiced. Straightforward.

On-premise software licenses — Point in time. All revenue hits when the customer gets access and can use it. This is why the SaaS-vs-license distinction matters — completely different recognition timelines.

Usage-based fees tied to IP licenses — As usage occurs. Topic 606 has a specific royalty exception — don't estimate upfront; recognize as the customer actually uses. AI companies charging per API call or per token: this is your rule.

Professional services — Combined with SaaS as one obligation? Over the combined period. Separate? As delivered.

Real complexity: mixed arrangements. License bundled with SaaS. Fixed fees next to usage-based components. Each piece in the same contract can follow a different pattern. That's by design.

What Actually Changed for Software Companies Under 606

The shift from ASC 985-605 to Topic 606 was the biggest accounting change for software in decades. Four things that moved:

• VSOE is gone. Estimate SSPs with best available info instead. Easier to separate elements, but the judgment burden is on you.
• One model for everyone. Software lost its special status. Same framework as construction and telecom. Not as simple as it sounds.
• More judgment, more documentation. SSP estimation, the distinct test, variable consideration — all require documented judgment. Your auditor will ask to see the work.
• Contract modifications have rules now. Explicit framework for upgrades, downgrades, renewals. Under the old standard, this was a gray area.

Straightforward SaaS subscription? Your pattern probably didn't change much. Bundle services, add usage-based pricing, handle frequent contract changes? Materially more analysis required.

How JustPaid Handles This

606 requires SaaS companies to identify obligations, estimate selling prices, and maintain recognition schedules across every contract — continuously. Spreadsheets work until they don't. For most growing companies, that happens faster than expected.

JustPaid's AI Contract Extraction reads billing terms from contracts and CRM data, identifies performance obligations automatically. Revenue schedules handle over-time and point-in-time patterns. ASC 606 and IFRS 15 compliance monitored in real time. Audit-ready docs generated without touching a spreadsheet.

Implementation: 3–7 days. Built for the current standard from day one — not retrofitted from something designed for the old rules.

Key Takeaways

• ASC 606 applies to every SaaS company with customer contracts. No exceptions for stage or size.
• Same 5-step model for everyone. How each step applies depends on your deal structures.
• SaaS revenue: over time, almost always. Complexity enters through bundles, variable pricing, and mixed arrangements.
• "Free" onboarding and bundled services still need stand-alone selling prices. This is where most companies get caught.
• Getting this right early is dramatically cheaper than fixing it later.

Sources

• KPMG LLP, Revenue for Software and SaaS Handbook, December 2025 Edition
• Financial Accounting Standards Board (FASB), ASC Topic 606: Revenue from Contracts with Customers (ASU 2014-09).

Ready to automate ASC 606 compliance? Schedule a personalized demo with JustPaid.