Series: Revenue Recognition for SaaS — Blog 7 of 10
Most B2B SaaS companies don't sell a subscription in isolation. The deal includes implementation, onboarding, training, data migration, premium support — sometimes all of them. That's a bundled deal. And under ASC 606, the number of performance obligations you identify in that bundle determines how revenue gets allocated and when it's recognized.
Identify too few obligations and you might defer revenue that should be recognized upfront. Too many and you might recognize revenue early on components that should be spread over time. Either direction attracts audit attention.
Here's how to get it right, based on KPMG's framework.
A promised good or service is a separate performance obligation only if it's "distinct." The test has two prongs that must both be true:
Can the customer benefit from this item on its own or with readily available resources? In other words, could the customer use it independently, or could another vendor provide a similar service?
Is the promise separately identifiable from other promises in the contract? Or is it highly integrated with other elements — effectively an input into a single combined output rather than a standalone deliverable?
The first prong is usually easier. Most services are capable of being distinct — someone else could do the implementation, the training, the data migration. The second prong is where judgment lives.
Configuring settings, importing initial data, training the team on the platform. This is usually distinct — the customer could hire a consultant to do it, and the onboarding doesn't modify the SaaS. Two obligations: onboarding (recognized as delivered) and SaaS (recognized ratably).
The vendor builds custom features, modifies workflows, or integrates deeply into the customer's systems. If the customization fundamentally changes the SaaS for that customer — creating something they couldn't get off the shelf — it's combined with the SaaS as one obligation. Recognized over the combined service period.
The test: would you sell the customized SaaS to another customer as-is? If it's so specific that only this customer would use it, the customization and SaaS are likely one obligation.
Technical support and unspecified updates that start and end with the subscription. Under 606, these are typically a single obligation combined with the SaaS — they're a series of distinct service periods with the same transfer pattern. One obligation, recognized ratably.
Support that runs on a different timeline than the subscription (e.g., 2-year SaaS with 3-year support). These are likely separate obligations because the PCS extends beyond the SaaS period — they have different transfer patterns and can't be a single series.
Advisory services, strategic consulting, or business process optimization delivered alongside SaaS. Usually distinct — the customer benefits from the consulting independently, and the services don't modify the software. Two obligations. Consulting recognized as delivered; SaaS ratably.
Data migration is often a setup activity — not a separate obligation. It doesn't transfer a service to the customer; it prepares the environment for the SaaS. Costs capitalized under ASC 340-40. Training, however, might be distinct — the customer receives a separate benefit (knowledge). Evaluate each component independently.
This one surprises companies every time. Setup activities — provisioning environments, configuring integrations, migrating data, building user interfaces — often don't qualify as performance obligations because they don't transfer a distinct good or service to the customer.
The customer doesn't benefit from the setup itself. They benefit from the SaaS access that the setup enables. The setup is a fulfillment activity.
The costs, however, are real. Under ASC 340-40, setup costs are capitalized as contract fulfillment assets (if they meet the criteria: relate to a contract, generate resources for future obligations, expected to be recovered). They're then amortized over the period the customer benefits — typically the SaaS term plus anticipated renewals.
Charging a one-time setup fee doesn't change this. The fee is an advance payment for the SaaS, not payment for a separate service. It gets combined with subscription fees and recognized ratably.
Under 606, if distinct goods or services are substantially the same and have the same pattern of transfer, they're combined into a single performance obligation called a "series." Each month of SaaS access is substantially the same service delivered the same way — so the entire subscription is one obligation.
This simplifies things considerably. One obligation means one allocation, one recognition pattern (time-elapsed, ratably). No need to separate January's access from February's.
The series concept breaks when the service changes materially over time — for example, if specific features are delivered in specific months, or if the nature of the service evolves during the contract. Rare for standard SaaS, but worth flagging if your product has a phased rollout.
Bundled SaaS deals require identifying obligations, estimating SSPs for each, allocating the transaction price proportionally, and then applying different recognition patterns to different components — all within the same contract.
JustPaid's AI Contract Extraction reads deal terms and identifies obligations automatically. SSP estimation uses your historical pricing data. Revenue schedules handle multi-obligation contracts natively — some components recognized upfront, others ratably, all tracked and auditable.
Bundling multiple services? Schedule a demo to see how JustPaid handles multi-obligation contracts.
Automate invoicing, streamline accounts receivable, and accelerate revenue with JustPaid.
Bundling SaaS with implementation, support, and training? Here's how to identify distinct performance obligations under ASC 606 and why it matters.
Upgrades, downgrades, and renewals change your revenue recognition under ASC 606. Here's the framework for handling SaaS contract modifications correctly.
ASC 340-40 requires SaaS companies to capitalize sales commissions. Here is what to capitalize, what to expense, and the practical expedient traps.
Free trials, renewal discounts, and customer options create hidden revenue recognition traps under ASC 606. Here is what SaaS companies get wrong.
SaaS and software licenses follow completely different revenue recognition rules under ASC 606. Here's how the distinction works and why it matters for your financials.
Usage-based billing creates unique revenue recognition challenges under ASC 606 — variable consideration, royalty exceptions, and the as-invoiced expedient explained.
Stay updated with the latest insights on AI-powered billing automation and financial operations.
Combinator (W23)
