Performance Obligations Under ASC 606: Examples and Identification

Identifying performance obligations under ASC 606 is the first step in revenue recognition: a contract’s obligations must be broken down into distinct, separately identifiable performance obligations so that revenue can be recognized when (or as) each one is satisfied. The distinction between a single performance obligation and multiple obligations turns on whether goods or services are separately identifiable and whether the customer can benefit from them independently.

What Defines a Performance Obligation

Under ASC 606, a performance obligation is a promise in a contract to transfer a distinct good or service (or a series of distinct goods or services that are substantially the same) to the customer. This is deceptively simple: the devil lies in “distinct.”

A performance obligation is distinct if two conditions hold:

1. The customer can benefit from the good or service on its own or with other resources the customer has readily available. This means the customer could theoretically use or resell the item without needing anything else from the contract.

2. The company’s promise is separately identifiable from other promises in the contract. This test looks at whether the transfer of the good or service is distinct from the company’s other obligations—are they bound together, or can they be supplied independently?

These tests are not mechanical. They require judgment about the customer’s intent, the market’s norms, and whether the company is selling a bundle as a single unit or as separable pieces.

When both tests are met, you have a separate performance obligation. Each obligation gets its own treatment: its own satisfaction condition, its own transaction price allocation, and its own revenue timing.

Single Obligation: The Bundled Product With Customization

Consider a software company that sells a cloud-based platform plus mandatory onboarding and integration work. On the surface, there are two deliverables: software access and implementation. But are they separate performance obligations?

The platform alone is not useful to the customer without configuration and data migration. The customer cannot benefit from the software access without the company’s integration work. The implementation work is so intertwined with the software delivery that they form a single combined performance obligation.

The company’s obligation here is not “provide software access” and “provide implementation”—it is “provide a fully operational, integrated platform.” Revenue is recognized over time (for the software access period) or upon completion (if the implementation is a lump-sum deliverable), but it is treated as a single obligation.

Key point: the fact that the company uses different resources (engineers vs. support staff) to deliver each piece does not make them separate obligations. The customer’s inability to benefit from one without the other is what matters.

Two Obligations: License Plus Maintenance

Now consider a company that sells a perpetual software license plus a three-year maintenance and support contract. The customer receives:

• A license to use the software indefinitely
• Technical support, bug fixes, and access to updates for three years

These are two separate performance obligations:

1. The license is separately identifiable: the customer can use the software without support. The customer can theoretically hire a third-party support vendor.
2. The maintenance and support is separately identifiable: the customer receives value from support services independently of owning the license.

The transaction price is allocated between the two. The license fee might be recognized upon sale; the maintenance fee is recognized ratably over the three-year service period.

This separation is permitted by ASC 606 because the customer can benefit from the license alone, and the two promises are not bundled together in a way that makes them inseparable.

Three Obligations: Infrastructure, License, and Implementation

A more complex example: a company sells a data platform to a large enterprise. The deal includes:

1. Cloud infrastructure (compute, storage, bandwidth)
2. A proprietary data-processing software license
3. Custom implementation and integration

Are these one obligation, two, or three?

• Infrastructure is separately identifiable: the customer could use other cloud providers or host internally. It is not dependent on the other deliverables.
• License is separately identifiable: the customer could deploy the software on its own infrastructure (though it would be impractical). The software itself has standalone value.
• Implementation is intertwined with the license and infrastructure: it is not separately identifiable because the customer cannot benefit from it without the infrastructure and license.

The result: two performance obligations—one for “infrastructure plus implementation” and one for the “software license.”

Allocation might look like: 40 percent to the combined infrastructure/implementation (recognized over time), 60 percent to the license (recognized over the contract period, typically over time for a SaaS license).

The judgment here is that the infrastructure and implementation are bundled (the customer needs both to get going), but the license is separable (it has independent value and the customer could theoretically switch infrastructure providers).

When the Customer Dictates Bundling

Sometimes the customer insists on bundling even when the company would prefer to separate. A customer might say: “I will only buy the platform if you include two years of free support and training.”

In this case, the customer’s ability to benefit from the platform independently is reduced or eliminated by the contract terms. The free support and training are so intertwined with the platform sale (as a practical matter, the customer will not proceed without them) that they may constitute a single performance obligation.

Conversely, if the customer agrees to pay separately for support (at an identifiable, arm’s-length price) and can choose to decline it, then it is a separate obligation even if purchased in the same contract.

This illustrates that performance obligation identification is not just about technical features—it is about the economic substance of the deal.

The Distinction From Satisfaction Conditions

Do not confuse performance obligation identification with satisfaction conditions. A satisfaction condition is a clause that determines when revenue is recognized (e.g., “upon the customer’s acceptance” or “upon delivery”).

A single performance obligation may have one or more satisfaction conditions. For example, “provide a completed software implementation” (one obligation) may have the condition “customer must sign off in writing before revenue is recognized.”

The conditions affect timing; they do not create multiple obligations.

Common Pitfalls and Audit Red Flags

Pitfall 1: Treating every deliverable as separate. A company delivers a product and also offers a free installation. It might wrongly split these into two obligations, delaying the installation revenue to a later date. If installation is inseparable from the customer’s ability to benefit from the product, it should be bundled.

Pitfall 2: Bundling when you should not. A company sells a car and separately offers a five-year warranty. Some teams treat these as a single obligation, recognizing all revenue upfront. The correct treatment is two obligations: the car is separate; the warranty is separate. This matters for cash flow and deferred revenue accounting.

Pitfall 3: Ignoring contract modifications. If a customer amends an existing contract to add new goods or services, the amendment may create new performance obligations. The company must reassess the contract at modification.

Auditors scrutinize performance obligation identification because it is the foundation of revenue recognition. Misidentification cascades into misstatement of revenue timing and amount.

Working Through the Decision Tree

To identify performance obligations consistently, follow this discipline:

1. List all promises in the contract (goods, services, warranties, support, training, etc.).
2. For each promise, ask: Is it separately identifiable? (Test both conditions: benefit, and independence from other promises.)
3. Group promises that fail the test. Inseparable promises are one obligation.
4. Assign each obligation a satisfaction condition: point in time, or over time (with method: output, input, proportional, etc.).
5. Allocate transaction price to each obligation using standalone selling price or expected cost plus margin.

This discipline ensures that revenue is recognized when economic value is actually transferred, not artificially accelerated or deferred by bundling or splitting.

See also