SaaS + implementation: is it one performance obligation or two?

Usually two. A good or service is distinct — and gets its own performance obligation — when the customer can benefit from it on its own or with readily available resources, AND the promise to transfer it is separately identifiable from other promises in the contract, per ASC 606-10-25-19 to 22. Implementation only merges into one obligation when it's so integrated the SaaS is unusable without it.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

Published September 16, 2026Last reviewed September 16, 2026Editorial policy

Part of the revenue recognition guide.

Governing guidance	FASB ASC 606-10-25-19 to 25-22
Test 1 — capable of being distinct	Can the customer benefit from the item on its own or with other readily available resources?
Test 2 — separately identifiable	Is the promise to transfer the item separately identifiable from other promises in the contract?
Both tests must pass	Failing either one means the items are combined into a single performance obligation
Not the test	Whether the items are on one invoice, one contract, or sold together is irrelevant to distinctness

Why being sold together doesn't make them one obligation

The natural instinct is to treat a bundled sale as automatically one thing — it's one line on one invoice, negotiated as one deal. ASC 606-10-25-19 doesn't ask how the items were sold; it asks whether each promised good or service is distinct, evaluated against two specific criteria. A SaaS subscription and an implementation service can be quoted, invoiced, and contracted as a single bundle and still be two separate performance obligations, each recognized on its own timeline, if both criteria are met independently for the implementation work.

Applying the first test: capable of being distinct

This asks whether the customer could benefit from the implementation service on its own, or combined with resources readily available to them — not whether they'd actually choose to buy it separately. Implementation work usually passes this test on its own: a customer could, in principle, engage a different vendor or their own staff to perform data migration, configuration, or training, meaning the benefit isn't uniquely locked to this specific SaaS purchase. Where this test can fail is when the implementation involves deep custom engineering that only functions with proprietary, non-transferable access to this specific vendor's backend — at that point, no other resource could plausibly deliver the same benefit.

Applying the second test: separately identifiable

This asks whether the promise to deliver the implementation is separately identifiable from the promise to deliver the SaaS access — in effect, whether the implementation is really just an input into producing one combined output, or a standalone deliverable in its own right. Signals that point toward "not separately identifiable" include the vendor significantly integrating the two into a single combined output the customer couldn't otherwise get, one item significantly modifying or customizing the other, or the items being highly interdependent such that each significantly affects the other. Standard onboarding — configuring settings, importing existing data, running training sessions — is typically separately identifiable from the SaaS access itself, even though it's a prerequisite to actually using the product.

The narrow case where they really do combine into one

The two-obligation outcome isn't automatic. When the implementation work fundamentally reconfigures the software into something the customer couldn't use without it — deep custom development that produces a functionally different product, rather than making an off-the-shelf product usable — both tests can fail together, and the appropriate treatment is one combined performance obligation recognized over the period the combined service is delivered. This is the exception, not the default, and it needs to be supported by what the implementation actually does technically, not by how it was priced or bundled.

Next step

Map the finance workflow with the most exposure and prove the automation path.

Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.

Book a workflow review

Worked example

A $120,000 bundled SaaS + implementation deal, allocated as two obligations

A 12-month SaaS contract bundles a $96,000 annual subscription (observable standalone SSP, since it's sold on its own to other customers) with a standard onboarding package — data import, user configuration, and two training sessions — quoted at $24,000, for a bundled total of $120,000. The onboarding uses the vendor's standard implementation playbook, involves no custom engineering, and a customer could in principle hire a third-party consultant or use internal staff to perform equivalent setup work using the vendor's public documentation. Both distinctness tests pass: the onboarding is capable of being distinct (a substitute resource could deliver it) and separately identifiable (it isn't fundamentally modifying the software itself, just configuring standard settings).

Result: two performance obligations. The subscription's SSP is observable at $96,000; the onboarding's SSP is estimated via expected-cost-plus-margin at $18,000 (120 hours at a $150 loaded rate, plus a 40% margin — the same method covered on the standalone-SSP-estimation page). Allocating the $120,000 bundled price proportionally: subscription gets 96,000/114,000 × 120,000 = $101,053, onboarding gets 18,000/114,000 × 120,000 = $18,947. The subscription recognizes ratably over the 12-month term (~$8,421/month); the onboarding recognizes as it's delivered, typically over the few weeks the setup work actually takes — a meaningfully faster recognition pattern than if the whole $120,000 had been treated as one obligation and spread evenly over 12 months.

Frequently Asked Questions

Not on its own — being a required first step doesn't make a service non-distinct. Onboarding is routinely mandatory and still separately identifiable, because the test is about whether the promise to deliver it is distinguishable from the promise to deliver SaaS access, not about the order of operations.

A $0 or token price for the implementation doesn't remove it as a distinct performance obligation if it otherwise meets both tests — it still needs an estimated SSP allocated to it, which in practice shifts some of the subscription's allocated price onto the implementation obligation even though nothing was separately invoiced for it.

The distinctness analysis is unaffected by contract length — implementation is still evaluated as its own obligation, recognized as delivered (typically early in the contract), while the subscription recognizes ratably across the full multi-year term regardless of which year the implementation happened in.

Sources

Topic

Revenue Recognition

Revenue recognition determines when — not just how much — revenue hits the books. Under ASC 606 (US GAAP) and its international counterpart IFRS 15, revenue is recorded as a company satisfies its perf…

Definition

What is a performance obligation under ASC 606?

A performance obligation is a distinct promise to transfer a good or service to a customer. "Distinct" is the load-bearing word: it's only a separate obligation if the customer can benefit from it on its own (or with resources already available to them) and it's separable from everything else promised in the contract — otherwise it gets bundled with related items into one combined obligation.

How-to

How do I allocate transaction price across multiple performance obligations?

Allocate the total transaction price to each performance obligation in proportion to its standalone selling price (SSP) — what it would sell for on its own. When SSP isn't directly observable, ASC 606 permits estimating it via adjusted market assessment, expected cost plus margin, or a residual approach that backs out the observable prices from the total.

Diagnostic

How do I determine standalone selling price (SSP) when I never sell the item separately?

ASC 606-10-32-33 requires using all available information to estimate SSP, maximizing observable inputs. The two primary methods are adjusted market assessment (what the market would pay) and expected cost plus a margin (your cost to deliver it, plus a reasonable margin). A residual approach exists but is restricted to narrow cases. Never allocate by an arbitrary split.