Have You Ever Faced These Challenges?
- Your entity sells software licences bundled with implementation services and multi-year maintenance — and you are not confident whether these should be treated as one performance obligation or three
- The question of whether a good or service is “distinct” comes up every year in your audit, and the answer never feels settled
- You recognised a bundled arrangement as a single performance obligation, only to discover that the correct treatment would have required significantly earlier revenue recognition for the licence component
What You Will Learn From This Article
- How to apply the two-part distinct test — capable of being distinct, and distinct within the context of the contract
- How the number of performance obligations identified affects the timing and amount of revenue recognised
- Industry-specific patterns for software, SaaS, manufacturing, and construction
Who This Article Is For
- Finance and accounting professionals at entities that sell bundled goods and services
- Practitioners in the software, SaaS, IT services, and telecommunications industries
- Finance professionals who regularly discuss performance obligation identification with their auditors
Why Step 2 Is the Most Judgement-Intensive Step in the Model
Step 2 sits at the heart of IFRS 15. The number of performance obligations identified in a contract determines both when revenue is recognised (Step 5) and how much revenue is allocated to each recognition event (Step 4). A misidentification at Step 2 therefore flows through the entire model and can result in material misstatement of the timing and amount of revenue.
The challenge is that the boundary between a single performance obligation and multiple separate obligations is not always clear. Two entities with commercially similar arrangements can reach different conclusions — and both may be able to defend their position. This is what makes Step 2 one of the most frequently debated areas between preparers and auditors in IFRS 15 application.
What Is a Performance Obligation?
A performance obligation is a promise in a contract with a customer to transfer either (IFRS 15.22):
- A distinct good or service (or a distinct bundle of goods or services), or
- A series of distinct goods or services that are substantially the same and have the same pattern of transfer to the customer
The second category — a series of distinct goods or services — is particularly relevant for subscription services, cleaning contracts, payroll processing, and other arrangements where the entity delivers the same type of service repeatedly over a period.
Explicit and Implied Promises
Performance obligations arise not only from explicitly stated contractual terms, but also from implied promises — those created by the entity’s customary business practices, published policies, or specific statements that give rise to a valid customer expectation (IFRS 15.24).
Implied promises that are frequently overlooked in practice include:
- Free initial training provided as a matter of course, even though not mentioned in the contract
- Complimentary software updates delivered to all customers under a standard policy
- Unconditional return and exchange policies that create an implicit obligation to accept returns
The test for whether an implied promise constitutes a performance obligation is whether the customer would reasonably expect the entity to perform it. If so, it must be identified and assessed under Step 2, even if it is not written into the contract.
The Two-Part Distinct Test
A good or service is a distinct performance obligation if — and only if — both of the following criteria are met (IFRS 15.27):
Criterion 1: Capable of Being Distinct
The customer can benefit from the good or service either on its own, or together with other resources that are readily available to the customer.
“Readily available” resources include goods or services that the entity sells separately, as well as goods or services that the customer can obtain from other sources in the market. The key question is whether the good or service has standalone utility — whether the customer derives value from it independently, without necessarily relying on other elements of the same contract.
Examples where Criterion 1 is met:
- A software licence that functions on a standalone basis and is compatible with third-party support services
- A piece of standard equipment that the customer or a third party can install without specialist assistance
- A one-year maintenance contract that provides value independently of any associated hardware sale
Examples where Criterion 1 is not met:
- A highly customised software module that cannot function without proprietary infrastructure developed and maintained exclusively by the vendor
- A component that is physically incorporated into a larger assembly and has no standalone utility in its intermediate form
Criterion 2: Distinct Within the Context of the Contract
The entity’s promise to transfer the good or service is separately identifiable from other promises in the contract (IFRS 15.27(b)).
This criterion looks at the relationship between promises in the contract, rather than the nature of the good or service in isolation. IFRS 15.29 identifies three indicators that a promise is not separately identifiable — that is, that the entity is providing a significant integration service combining the inputs into a single combined output:
- The entity provides a significant service of integrating the goods or services into a combined item or items for which the customer has contracted
- One or more of the goods or services significantly modifies or customises another good or service in the contract
- The goods or services are highly interdependent or highly interrelated — each is significantly affected by the other
Examples where Criterion 2 is met:
- A standard software licence and a separately priced annual maintenance agreement, where the licence functions independently of the maintenance
- Hardware and a standard installation service, where the installation does not significantly alter the product
Examples where Criterion 2 is not met:
- A large-scale ERP implementation where design, development, configuration, testing, and deployment are highly interdependent and collectively produce a single integrated system
- A construction contract where structural, mechanical, electrical, and fit-out works are all performed by the same entity under a single project scope and cannot be disaggregated without fundamentally altering the nature of the output
The Practical Consequence of Getting Step 2 Wrong
To illustrate the financial impact of misidentifying performance obligations, consider the following example.
Contract terms: An entity sells a software licence (standalone selling price: ¥80 million) together with three years of maintenance and support (standalone selling price: ¥30 million) for a bundled price of ¥100 million.
Scenario A — Incorrectly treated as a single performance obligation: Revenue of ¥100 million is recognised evenly over the three-year maintenance period — approximately ¥33 million per year.
Scenario B — Correctly treated as two separate performance obligations: The transaction price is allocated based on relative standalone selling prices:
| Performance obligation | SSP | Allocation ratio | Allocated amount |
|---|---|---|---|
| Software licence | USD 80m | 72.7% | USD 72.7m |
| Maintenance (3 years) | USD 30m | 27.3% | USD 27.3m |
| Total | USD 110m | 100% | USD 100m |
The licence is recognised at the point the customer obtains control (contract inception in most cases). Maintenance is recognised evenly over three years at approximately USD9.1 million per year.
Year 1 revenue comparison:
| Scenario | Year 1 revenue |
|---|---|
| Scenario A (single obligation) | USD 33 million |
| Scenario B (two obligations) | USD 81.8 million (USD 72.7m licence + USD 9.1m maintenance) |
The difference in Year 1 revenue is approximately USD 49 million — purely as a result of the Step 2 judgement. This is why auditors pay close attention to performance obligation identification, particularly in the software and technology sector.
Industry-Specific Patterns
Software and SaaS
On-premise software with maintenance: Where the software licence and maintenance are sold together, the licence is generally a separate performance obligation if the software functions without the maintenance (i.e., the current version continues to operate independently). The licence is recognised at a point in time; maintenance is recognised over the contract period.
The analysis becomes more complex where the maintenance includes significant updates that are integral to the software’s ongoing functionality. In such cases, the licence and maintenance may be a single performance obligation recognised over time — a treatment more common in cloud-hosted SaaS arrangements where the customer accesses a continuously updated service rather than owning a static version.
SaaS subscriptions with onboarding: Whether onboarding and implementation services constitute a separate performance obligation depends on whether they provide a standalone benefit to the customer. In most cases, standard onboarding (configuration, data migration, initial setup) does not have independent utility — it is preparation for the subscription service rather than a service the customer could benefit from on its own. In such cases, onboarding is combined with the subscription into a single performance obligation.
Where onboarding involves substantive consulting, process design, or training that has standalone value — and that the customer could purchase independently — it is more likely to qualify as a separate performance obligation.
Manufacturing (Product Plus Installation)
The key variable is the complexity of installation. Where a product can be installed by the customer or by a third party without specialist knowledge, product and installation are typically two separate performance obligations. Where installation requires proprietary expertise that only the manufacturer possesses — for example, precision calibration of specialised equipment — product and installation may be a single performance obligation.
Construction and Engineering
Large EPC (engineering, procurement, and construction) contracts typically involve a single performance obligation. The design, procurement, and construction phases are highly interdependent — the contractor provides a significant integration service combining all inputs into a single facility. Separating the phases would misrepresent the nature of what the customer has contracted for.
Smaller, modular construction contracts — where, for example, civil works and fit-out are distinct scopes that could be performed by different contractors — may give rise to separate performance obligations depending on the specific facts.
Decision Framework for Step 2
① List all promises in the contract — both explicit and implied.
② For each promise, apply Criterion 1: → Can the customer benefit from this good or service on its own or with readily available resources? → No: Not capable of being distinct → combine with related promises and reassess as a bundle.
③ For promises that satisfy Criterion 1, apply Criterion 2: → Is the promise separately identifiable from other promises in the contract? → No: Not distinct within the context of the contract → combine with related promises.
④ Promises that satisfy both criteria → separate performance obligations.
⑤ Consider whether any series of distinct goods or services that are substantially the same with the same pattern of transfer should be treated as a single performance obligation.
Comparison with Japanese GAAP
Japan’s revenue recognition standard (ASBJ No. 29) is substantially aligned with IFRS 15 on performance obligation identification. The two-part distinct test, the treatment of implied promises, and the series concept are all consistent.
One area of practical difference is the availability of certain simplifications under Japanese GAAP — for example, the option to treat shipping and handling activities as fulfilment costs rather than as a separate performance obligation. This simplification is not available under IFRS 15.
Summary
The key takeaways from Step 2 are as follows:
- A good or service is a distinct performance obligation only if both criteria are met: capable of being distinct (standalone utility) and distinct within the context of the contract (separately identifiable)
- Implied promises — those arising from customary practice or published policies — must be identified and assessed alongside explicit contractual terms
- The number of performance obligations directly determines how much revenue is allocated to each recognition event and when it is recognised
- Industry context matters significantly: the same analytical framework produces different outcomes in SaaS, manufacturing, and construction due to the nature of the goods and services involved
- Misidentification at Step 2 can result in material differences in the timing of revenue recognition — making this one of the highest-risk areas under IFRS 15
The next article examines Step 3: determining the transaction price — with a focus on variable consideration estimation and the constraint.
Comments