Ind AS 115's Five-Step Model, Tested Against a Real Contract
Ind AS 115's five-step revenue recognition model is easy to recite and genuinely easy to misapply on a real contract with multiple deliverables. Each step tests something specific, and skipping the test in favour of the label is where recognition timing goes wrong.
Step 1: Does the Contract Even Qualify? (Para 9)
Before any revenue can be recognised under Ind AS 115 at all, the contract must clear five conditions:
- The parties have approved the contract and are committed to perform
- Each party's rights regarding goods/services are identifiable
- Payment terms are identifiable
- The contract has commercial substance
- Collection of the consideration is probable
If any one condition fails, the contract doesn't qualify under Ind AS 115 — receipts are treated as a deposit or liability, not revenue, until the criteria are met. This is a genuine gate, not a formality: a contract with uncertain collectability, for instance, sits outside the model entirely rather than being recognised with an allowance.
Step 2: Identify the Performance Obligations (Para 22)
A performance obligation is a distinct promise to transfer a good or service. A single contract can carry several — a software licence bundled with implementation services and a year of support is, potentially, three separate performance obligations, each needing its own standalone price and its own recognition pattern, rather than one lump-sum contract recognised on a single timeline.
Step 3: Determine the Transaction Price (Para 47)
The transaction price is the amount the entity expects to be entitled to in exchange for the promised goods or services — which can be more complex than the invoiced figure once variable consideration, financing components, or non-cash consideration are in play.
Steps 4-5: Allocate and Recognise
The transaction price is allocated across the identified performance obligations, typically in proportion to each one's standalone selling price. Revenue for each obligation is then recognised either:
- Point in time — when control transfers, typically on delivery or completion, or
- Over time — progressively, as the entity satisfies the obligation (measured, for instance, by percentage of completion)
The choice between the two isn't optional per obligation — it depends on whether the obligation meets the over-time recognition criteria (the customer simultaneously receives and consumes the benefit as the entity performs, or the entity's performance creates or enhances an asset the customer controls, or the asset has no alternative use and the entity has an enforceable right to payment for performance completed to date). Getting this classification wrong is one of the more common Ind AS 115 errors — treating a genuinely over-time obligation as point-in-time defers recognition that should already be happening, and vice versa.
Why Multi-Element Contracts Are Where This Breaks
A contract with a single, simple deliverable rarely trips up the five-step model — contract qualifies, one performance obligation, transaction price equals the invoice amount, recognised at delivery. The model earns its complexity on multi-element contracts: a software company selling a licence, implementation, and ongoing support in one agreement has to separate three performance obligations, price each on a standalone basis, and potentially recognise each on a different pattern (licence at a point in time, implementation over the implementation period, support ratably over the support term) — three different revenue curves from one signed contract.
Frequently Asked Questions
What happens if a contract doesn't meet the Step 1 criteria?
Revenue recognition under Ind AS 115 doesn't begin. Amounts received are treated as a deposit or liability rather than revenue, until the contract criteria — particularly probable collectability — are actually met.
How is the transaction price split across multiple performance obligations?
Typically in proportion to each obligation's standalone selling price — the price at which the entity would sell that good or service separately, not an arbitrary or contractually-stated allocation.
What decides whether a performance obligation is recognised over time or at a point in time?
Specific criteria under the standard: whether the customer simultaneously receives and consumes the benefit as the entity performs, whether the entity's performance creates or enhances a customer-controlled asset, or whether the asset has no alternative use combined with an enforceable right to payment for work completed. If none apply, recognition is at the point in time control transfers.
Can one contract have performance obligations recognised on different timelines?
Yes — this is the normal case for multi-element contracts. A licence might recognise at a point in time while implementation services on the same contract recognise over time as work progresses, each based on its own obligation-specific assessment, not a single contract-wide pattern.
CORAA's Ind AS 115 Revenue Recognition Tester walks a contract through all five steps interactively — the qualification gate, performance-obligation identification, transaction price, and allocation across obligations with their own recognition patterns — rather than treating a multi-element contract as one lump-sum recognition event.