Thursday close is underway. The billing platform shows €4.1 million in booked annual contracts, the CRM shows €380,000 of credits issued mid-quarter, and the auditor wants evidence that every euro of recognized revenue ties to a contract, an allocation, and a recognition event. The sales team sees bookings. Finance sees deferred revenue, contract modifications, and cut-off judgments.
Revenue recognition under IFRS 15 records revenue when control of promised goods or services transfers to the customer, not when the contract is signed or cash is collected. IFRS 15 applies a single five-step framework to identify contracts, identify performance obligations, determine and allocate transaction price, and recognize revenue when obligations are satisfied. The IASB issued IFRS 15 on 28 May 2014, and it became mandatory for annual reporting periods beginning on or after 1 January 2018. The standard replaced several earlier requirements, including IAS 11 and IAS 18, as documented by the IASB’s IFRS 15 standard overview.
The hard part isn’t memorizing five steps. The hard part is producing a deterministic, auditable run book for every revenue entry across CRM, contract storage, billing, and ERP.
Table of Contents
- Why Revenue Recognition IFRS Matters for Modern Finance Teams
- The Five-Step Model Explained Step by Step
- Identifying Performance Obligations in Multi-Element SaaS Contracts
- Measuring and Allocating the Transaction Price
- When to Recognize Revenue Over Time or at a Point in Time
- Variable Consideration and the Disclosure Burden
- Operating an IFRS 15 Finance Stack With Audit-Ready Evidence
- The IFRS 15 Readiness Checklist and Common Questions
Why Revenue Recognition IFRS Matters for Modern Finance Teams
IFRS 15 matters because the P&L must reflect transferred control, while commercial systems usually reflect signed bookings, invoices, collections, and concessions. The difference creates the audit question: can finance reconstruct why revenue was recognized in that period and at that amount?
A SaaS controller can have annual contracts booked in the sales system while the general ledger carries much of the consideration as deferred revenue. A mid-quarter credit can affect the transaction price, allocation, contract liability, and disclosure narrative. The sales dashboard may still report the original booking value. None of those systems is wrong in isolation. Together, they can produce an incomplete accounting record.
The operating gap behind the accounting judgment
IFRS 15 also replaced a broad collection of earlier revenue rules with a unified model. The IASB’s historical IFRS 15 material records that IAS 18 was originally issued in December 1993, replacing an earlier revenue recognition standard issued in December 1982. The IASB adopted IAS 11 and IAS 18 in April 2001, before IFRS 15 consolidated the requirements.
That history matters operationally. A unified model still requires contract-level judgments. Teams must decide whether implementation is distinct, whether credits are variable consideration, whether a modification creates a new contract, and whether performance occurs over time.
Practical rule: Bookings explain commercial activity. IFRS 15 evidence explains recognized revenue.
Deferred revenue can also distort management interpretation. A company may sign substantial annual commitments while recognizing revenue across the service period. Sales incentives may be tied to booked values rather than recognized values. The controller then needs reconciliations that explain movements between bookings, billings, deferred revenue, recognized revenue, and credits.
IFRS 15 disclosures add another layer. Paragraphs 110 through 129 require information that helps users understand revenue and related judgments. Finance therefore needs more than journal entries. The function needs a complete source trail, including contract terms, allocation logic, recognition schedules, modifications, estimates, approvals, and disclosure support. Teams can also streamline tax document workflows so supporting records remain organized alongside the accounting evidence.
The Five-Step Model Explained Step by Step
The IFRS 15 five-step model converts a customer contract into documented accounting outputs. For a SaaS agreement containing a €240,000 annual subscription, €30,000 implementation, and €12,000 usage credits, the finance team should produce a contract assessment, obligation analysis, transaction-price calculation, allocation table, recognition schedule, and journal-entry support.
The IFRS 15 requirements establish the mechanics. The workflow below turns those mechanics into artifacts.
Step 1 identifies the contract
The team confirms that the arrangement has approval, enforceable rights and obligations, payment terms, commercial substance, and an appropriate basis for assessing collectability.
Output: a contract checklist linked to the signed agreement, order form, amendments, and approval record.
The checklist should capture the customer, promised goods and services, payment structure, renewal terms, cancellation clauses, credits, acceptance language, and effective dates. A billing record alone isn’t enough. Billing may show what was invoiced, but the contract determines what was promised.
Step 2 identifies performance obligations
The team identifies each distinct promise. The working analysis may begin with the software access, implementation service, support, and usage credits. The team then tests whether each promise is capable of being distinct and separately identifiable.
Output: an obligation matrix with the conclusion, rationale, evidence, and reviewer approval for each component.
Step 3 determines transaction price
The stated consideration includes the subscription, implementation, and credits. The team assesses whether the credits are fixed, variable, refundable, or subject to usage conditions. Variable consideration is included only to the extent that it is highly probable a significant reversal won’t occur.
Output: a transaction-price calculation with assumptions, source data, constraint assessment, and change history.
Step 4 allocates the price
The team allocates consideration to performance obligations using relative stand-alone selling prices. Observable prices are preferable. Where prices aren’t directly observable, finance documents the estimation method and the evidence supporting it.
Output: an allocation table that links each obligation to its stand-alone selling price, allocation proportion, and allocated transaction price.
Step 5 recognizes revenue
The team recognizes revenue when or as each obligation is satisfied. Subscription access may be recognized over the service period. Implementation may be recognized over time or at a point in time, depending on control and the facts. Credits require a recognition trigger supported by the contract and usage evidence.
Output: a recognition schedule, journal entries, cutoff reconciliation, and linked source documents.
A controller should be able to hand an auditor the full chain at any moment. The chain should run from signed contract to obligation matrix, price calculation, allocation, schedule, journal entry, approval, and disclosure output.
The following video provides a visual explanation of the model:
Identifying Performance Obligations in Multi-Element SaaS Contracts
A SaaS component is a separate performance obligation only when the customer can benefit from it and the promise is separately identifiable within the contract. The second test often decides the outcome for implementation services, especially when implementation changes the core platform.
Consider a contract containing platform access, implementation, tiered support, and usage credits. Platform access may be capable of being distinct because the customer receives the service through the hosted product. Support may also be capable of being distinct when the customer can benefit from it with the platform and the support team isn’t delivering one inseparable combined output.
Implementation requires more judgment. If implementation consists of configuration that leaves the platform substantially unchanged, it may be separately identifiable. If the service customizes the core platform, combines several promised inputs, or creates an integrated output that the customer can’t use without the implementation work, the second limb of the test may fail.
Evidence should follow the judgment
Usage credits often require a separate analysis. The customer may control an unused balance, but the team still needs to examine the contract wording, redemption rights, expiry clauses, refund terms, and the nature of the promised service. A label such as “credits” doesn’t resolve the accounting.
Each conclusion should point to evidence:
- Contract wording: Identify the promised service, redemption terms, customer rights, acceptance language, and modification clauses.
- Vendor scoping notes: Show what implementation changes and whether the work produces a combined output.
- Product architecture documentation: Explain dependencies between platform access, configuration, support, and usage features.
- Operational records: Preserve provisioning, delivery, usage, acceptance, and service-completion evidence.
The table below provides a starting structure, not a substitute for contract-specific analysis.
| Contract Component | Capable of Being Distinct | Separately Identifiable in Contract | Distinct Performance Obligation? |
|---|---|---|---|
| Platform access | Usually assessable from the customer’s ability to receive hosted service | Depends on integration and customization | Contract-specific conclusion |
| Implementation | Customer may benefit from setup work | Often fails when it customizes or integrates the core platform | Contract-specific conclusion |
| Tiered support | May provide a service alongside platform access | Depends on whether support is integrated with another promise | Contract-specific conclusion |
| Usage credits | Customer may benefit as credits are used | Depends on redemption, expiry, and service terms | Contract-specific conclusion |
A weak workflow stores only the final conclusion. A stronger workflow stores the conclusion and the evidence that produced it. That distinction matters because revenue leakage can arise when contract terms, usage records, and postings drift apart. Finance teams assessing that exposure can review how revenue leakage develops across finance workflows.
Measuring and Allocating the Transaction Price
The transaction price is the consideration the entity expects to receive for transferring promised goods or services, adjusted for variable consideration and any significant financing component. The resulting amount is allocated to each distinct performance obligation using relative stand-alone selling prices.
A SaaS team starts with fixed consideration, then assesses credits, refunds, rebates, discounts, service-level penalties, and other contingent amounts. IFRS 15 permits variable consideration only when it is highly probable that including the amount won’t result in a significant revenue reversal. The KPMG IFRS 15 handbook describes the expected-value and most-likely-outcome approaches and explains that changes allocated to a satisfied obligation can affect profit or loss in the period of change.
Financing and estimation choices
IFRS 15 requires an adjustment for the time value of money when a contract contains a significant financing component. The practical expedient removes that adjustment when the relevant period between payment and transfer is one year or less, subject to the standard’s stated conditions. Longer arrangements require a documented assessment, even when the conclusion is that no significant financing component exists.
Stand-alone selling prices may be observable for a subscription. Implementation and usage credits may require estimation using adjusted market assessment, expected cost plus margin, or a residual approach where permitted. The method matters less than disciplined evidence, consistent application, and approval of material judgments.
| Performance Obligation | Stand-Alone Selling Price | Allocation % | Allocated Transaction Price | Recognition Pattern |
|---|---|---|---|---|
| Annual subscription | €240,000 | Derived from relative SSPs | Derived from relative SSPs | Usually over time if access is provided continuously |
| Implementation | €30,000 | Derived from relative SSPs | Derived from relative SSPs | Over time or point in time, based on control |
| Usage credits | €12,000 | Derived from relative SSPs | Derived from relative SSPs | Based on the related promised service and usage facts |
The allocation table should link directly to the recognition schedule. A spreadsheet that calculates an allocation but doesn’t preserve source contracts, assumptions, and reviewer approvals creates a fragile audit trail.
When to Recognize Revenue Over Time or at a Point in Time
A contract can be billed upfront, include milestones, or begin with a trial, yet those events do not by themselves set revenue timing. The accounting conclusion depends on when the customer obtains control of the promised good or service.
Revenue is recognized over time when the customer receives benefits as performance occurs, controls the asset being created or enhanced, or the entity has no alternative use for the work and an enforceable right to payment. Revenue is recognized at a point in time when control transfers at a specific event.
SaaS access commonly supports over-time recognition because the customer receives and consumes access as the provider performs. Implementation needs its own analysis. If the customer controls work in progress, recognition may occur over time. If the provider controls the work and the completed output transfers at a defined event, point-in-time recognition may be appropriate.
Control determines cut-off
Billing records, dispatch documents, customer acceptance, and milestone invoices are useful evidence, but none automatically determines the recognition date. The contract, the promised deliverable, and the facts surrounding transfer must support the selected pattern.
Apply that assessment to the workflow:
- Trials: A trial may require deferral until the customer converts or until the promised service becomes enforceable, depending on the arrangement.
- Shipping terms: Control may transfer on delivery rather than dispatch, depending on the contract and facts.
- Milestones: A milestone invoice may not equal performance. Recognition follows the transfer of control or progress toward satisfying the obligation.
For an auditable finance workflow, store the recognition pattern, measurement method, triggering evidence, and supporting contract clause with the schedule. Auditors can then test the conclusion against the arrangement instead of relying on a generic policy statement. A focused comparison of revenue recognition under US GAAP and IFRS can clarify framework differences, while the contract facts still govern the IFRS 15 conclusion.
Variable Consideration and the Disclosure Burden
A usage-based SaaS fee, service-level credit, refund right, or renewal rebate can change the amount recognized after the contract begins. Variable consideration is recognized only to the extent that it is highly probable a significant reversal won’t occur. The finance workflow therefore needs an estimate, a constraint assessment, and a controlled process for revising both when facts change.
Choose the estimation method that fits the contract economics. The expected-value method applies probability weights across possible outcomes. The most-likely-outcome method selects the single outcome that best predicts the consideration. Document the selection and the facts supporting it, rather than treating the method as a permanent policy choice.
The operational risk appears in the true-up. A revised estimate can create P&L volatility after partial performance. The KPMG revenue handbook notes that a transaction-price change allocated to a satisfied performance obligation is recognized in the period of change.
Build the evidence record around five items:
- Forecast inputs: Usage, renewals, refunds, credits, rebates, and penalties used in the estimate.
- Constraint assessment: The reasons the amount is or isn’t highly probable not to reverse.
- Approval record: The owner, reviewer, date, and policy version supporting a material estimate.
- Change history: The prior estimate, revised estimate, triggering fact, and resulting journal entry.
- Disclosure linkage: The calculation supporting disaggregated revenue, contract balances, remaining obligations, and significant judgments.
Disclosure preparation should reconcile to the same calculations that support the ledger. Readers of the financial statements need to understand why contract liabilities changed, how consideration was estimated, and which judgments affected timing. A useful control starts with a disclosure balance and traces it to the calculation, source contract, journal entry, and approval without depending on one employee’s memory.
Contract modifications and financing assessments should run through the same controlled process. A modification may change obligations or price, while a financing component may change the transaction price. Either can alter schedules and disclosures. Separate calculations are workable, but fragmented evidence makes the consolidated conclusion harder to test and defend.
Operating an IFRS 15 Finance Stack With Audit-Ready Evidence
An audit-ready IFRS 15 workflow must connect contract intake, obligation analysis, pricing, modifications, recognition schedules, journal entries, and disclosures through one inspectable evidence trail. In practice, this is the difference between explaining a revenue balance and reconstructing it under audit. Generic AI output can sound plausible, but plausibility does not provide repeatable execution or approval history.
Start with the systems that already hold the evidence. The CRM records commercial terms, the contract repository stores signed agreements and amendments, billing holds invoices, credits, and usage, and the ERP posts balances and journal entries. The revenue process should reconcile these records without making the controller a manual integration layer.
Build controls around repeatable execution
Loopfour can operate as a governed layer between CRM, billing, ERP, and document systems. Its documented workflow uses predefined, versioned steps, exception routing, approvals, execution logs, and evidence capture. Its revenue recognition workflow can read recognition schedules, calculate movements from deferred to recognized revenue, and connect journal entries to source contracts.
The trade-off is clear:
| Automation approach | What finance receives | Main trade-off |
|---|---|---|
| Generic AI agent | Interpreted output that may require manual reconstruction | Flexible interpretation, weaker deterministic control |
| Spreadsheet process | Visible calculations with fragile version and source control | Familiar operation, high dependency on manual maintenance |
| Rule-based workflow | Predefined steps, approvals, logs, and linked evidence | Strong auditability, less tolerance for undocumented exceptions |
AI remains useful for document parsing and term extraction. Set confidence thresholds, route uncertain results to a reviewer, and keep the accounting conclusion tied to policy, source evidence, and an approved workflow version. The system should show what changed, who approved it, and which calculation produced the journal entry.
Operationally, the stack needs five connected layers:
- Contract repository: Signed contracts, order forms, amendments, and acceptance records.
- Modification tracking: Reassessment of obligations, price, allocation, and recognition schedules.
- Financing assessment: Time-value-of-money analysis and documented use of any practical expedient.
- Disclosure dashboard: Calculations for revenue categories, contract balances, and remaining obligations.
- Audit run book: Execution trees, approvals, exceptions, system writes, and source links.
Finance teams comparing implementation options can review revenue recognition software for finance operations. The design test is straightforward: every output must be deterministic, predefined, and auditable.
The IFRS 15 Readiness Checklist and Common Questions
An IFRS 15-ready finance function can produce contract evidence, allocation support, recognition schedules, reconciliations, and disclosure calculations on demand. Readiness means the workflow survives staff changes, contract amendments, and audit sampling without undocumented manual reconstruction.
Operational checklist
- Contract repository: Store signed contracts and modifications centrally.
- SSP evidence: Preserve stand-alone selling price support for each obligation.
- Allocation memos: Document the rationale for allocating transaction price.
- Variable consideration estimates: Apply the constraint and update estimates with governed approvals.
- Timing assessments: Record evidence for over-time or point-in-time recognition.
- Disclosure support: Link reported balances and narratives to calculations.
- Cut-off reconciliation: Tie recognition schedules to billing, usage, deferred revenue, and the general ledger.
Questions finance leaders ask
How should IFRS 15 treat usage credits?
Usage credits require analysis of the promised service, customer rights, redemption terms, expiry, and consideration uncertainty. The accounting record should show when the related obligation is satisfied and how unused balances were assessed.
When should a team capitalize contract costs?
The team should assess whether incremental costs of obtaining or fulfilling a contract meet IFRS 15’s capitalization criteria. The conclusion needs supporting calculations, amortization logic, and impairment monitoring.
How should multi-year prepayments be handled?
Cash collection doesn’t by itself create recognized revenue. The team records the contract balance and recognizes revenue as the related performance obligations are satisfied, with financing assessment where relevant.
What changes for SME reporters?
The IASB has moved the IFRS for SMEs revenue chapter to revised Section 23, Revenue from Contracts with Customers, based on IFRS 15’s five-step model. The update is effective for periods beginning on or after 1 January 2027, according to the IASB’s IFRS for SMEs update. SME teams therefore need practical workflows for obligations, variable consideration, and audit evidence, not only a revised policy document.
The controller’s final test is simple. Every revenue entry should have a source contract, a defined obligation, a price allocation, a recognition trigger, a journal entry, and an approval trail.
Loopfour provides deterministic finance workflow automation for revenue schedules, contract changes, approvals, and linked journal-entry evidence across existing finance systems. Visit Loopfour to assess how an auditable IFRS 15 workflow could fit your ERP, CRM, billing, and document stack.