Bundling SaaS with Services? Here's How to Identify Your Performance Obligations

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.

The Distinct Test: Two Parts, Both Required

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:

Capable of being distinct

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?

Distinct in the context of the contract

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.

Six Common SaaS Bundle Scenarios

Scenario 1: SaaS + light onboarding

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).

Scenario 2: SaaS + significant customization

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.

Scenario 3: SaaS + co-terminus PCS (support, updates, upgrades)

Technical support and unspecified updates that start and end with the subscription. Under ASC 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.

Scenario 4: SaaS + non-co-terminus PCS

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.

Scenario 5: SaaS + professional services (consulting, strategy)

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.

Scenario 6: SaaS + data migration + training

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.

Setup Activities: The Non-Obligation That Costs Real Money

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.

The Series Concept: Why SaaS Is (Usually) One Obligation

Under ASC 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.

How JustPaid Handles Bundled Deals

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.

Key Takeaways

• The distinct test has two prongs — capable of being distinct and distinct in context. Both must be true.
• Light onboarding is usually distinct (two obligations). Significant customization is usually combined (one obligation).
• Setup activities are often not performance obligations. They're fulfillment activities with capitalized costs.
• Co-terminus PCS is typically combined with SaaS. Non-co-terminus PCS is usually separate.
• The series concept simplifies SaaS to one obligation — but breaks if the service changes materially over time.

Frequently Asked Questions

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).

Bundling multiple services? Schedule a demo to see how JustPaid handles multi-obligation contracts.