Accounting standard changes usually land as a disclosure exercise. ASC 606 and IFRS 15 landed as a systems project, and a great many finance teams discovered that fact roughly a quarter too late. The new revenue standards became effective for most public companies in 2018, with private entities following a year later, and they replaced a patchwork of industry-specific guidance with a single five-step model: identify the contract, identify the distinct performance obligations within it, determine the transaction price, allocate that price across the obligations, and recognise revenue as each obligation is satisfied. Read as a principle, it is elegant and arguably an improvement. Read as a data requirement, it asks for something most ERP systems of the period simply did not hold. Because the model is contract-centric, and enterprise systems are order-centric. That single mismatch generated most of the work.
Why the systems could not do it
Legacy revenue logic in ERP was built around billing events. You raised an invoice; revenue was recognised. Where a deferral was needed — a maintenance contract, a subscription — a schedule spread it over time, usually straight-line. That model was adequate under the previous guidance for most businesses, and it is structurally incapable of supporting the five-step approach. The gaps showed up in four places. Performance obligations are not line items. A contract bundling software, implementation, training and support may contain one performance obligation or four, depending on whether each is distinct. That determination is a judgement, it is made per contract, and there was nowhere in the system to record it. Organisations ended up creating a revenue layer whose granularity did not match their order structure. Standalone selling price is required even when nothing is sold standalone. Allocating the transaction price across obligations requires a standalone selling price for each. Where an item is never sold separately — which describes most bundled implementation and support — it must be estimated, with a documented methodology, applied consistently, and revisited. That is a new master data domain that no ERP had a field for. Variable consideration must be estimated and constrained. Rebates, volume discounts, penalties, bonuses, rights of return and price concessions all have to be estimated at contract inception and included to the extent it is probable there will be no significant reversal. Systems that recorded a rebate when it was claimed now needed to accrue an estimate at the outset and true it up. Contract costs became capitalisable and amortisable. The related guidance on contract costs requires incremental costs of obtaining a contract — sales commissions being the obvious case — to be capitalised and amortised over the period of benefit, which may extend well past the contract term if renewals are expected. This turned a payroll expense into a balance sheet asset with its own amortisation schedule, and almost nobody had a system for it. Add the transition itself — full retrospective or modified retrospective, either requiring parallel calculation of prior periods — and a standard that sounded like a policy change became twelve months of implementation work.
| Data domain | What to capture |
|---|---|
| Performance obligations | The documented judgement on distinct promises in the contract. |
| Standalone prices | A consistent estimation method, owner and review history. |
| Variable consideration | Estimates, constraints and subsequent adjustments. |
| Contract history | Scope, price modifications and relevant contract-cost schedules. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
What worked and what did not
Three patterns emerged, and their durability differed sharply. Spreadsheet workarounds were the most common response and the least sustainable. Extract contracts, calculate allocations offline, post a journal. This got organisations through adoption and left them with a material, unauditable, single-person dependency sitting between the operational system and the financial statements. Several are still there. Specialist revenue engines bolted onto the ERP handled the calculation well and created an integration and reconciliation burden. They work when the contract data feeding them is clean, which returns the problem to the source system. Restructuring the source data — capturing performance obligations, standalone selling prices and contract modifications properly at the point of sale — was the most expensive option and the only one that actually solved the problem. It also required changing how sales operations and contracting worked, which is why it was unpopular and why the organisations that did it stopped having revenue recognition as a recurring quarter-end crisis. The pattern worth noting: the accounting problem was solvable in the accounting system, and the data problem was only solvable upstream. Every organisation that tried to solve the second in the first ended up with a reconciliation.
Practical Guidance for Revenue Recognition Assessment
- Start from the contract, not the invoice. The standard is contract-centric and most ERP is order-centric; the whole project follows from closing that gap.
- Inventory your contract types and identify the performance obligations in each. A small number of templates usually explains the majority of revenue, and the judgements only need making once per type.
- Build a documented standalone selling price methodology. It is new master data, it must be consistent and defensible, and it needs an owner and a review cycle.
- Capture contract modifications as events, not amendments in a document. Changes in scope and price drive reallocation, and systems that only hold the current version cannot produce the history.
- Treat sales commissions as a capitalisation problem early. Amortisation over a period of benefit that may exceed the contract term needs a schedule, not an accrual.
- Avoid permanent spreadsheet bridges between the ERP and the ledger. They pass the first audit and become an unauditable key-person dependency by the third.
- Fix the data upstream in sales operations. Anything solved only in finance becomes a reconciliation that recurs every close.
- Involve the auditor on methodology before adoption, not after. Judgements agreed in advance cost days; judgements challenged at year end cost quarters.
The Regional Angle
Gulf finance teams engaged with IFRS 15 on a different footing from their US counterparts, and the local complications are specific. IFRS is the reporting framework across the region, so IFRS 15 applied broadly — to listed entities, to subsidiaries of international groups reporting up, to companies with bank covenants requiring IFRS accounts, and to entities in DIFC and ADGM. What differed was capability. A large number of regional groups run finance functions sized for statutory compliance rather than technical accounting, frequently with a single qualified accountant supported by bookkeepers, and the judgement-heavy nature of the standard — distinct obligations, estimated standalone prices, constrained variable consideration — is exactly the kind of work that structure is not built for. The practical consequence was heavy reliance on external advisers for the methodology and on spreadsheets for the execution. The contracting sector felt it hardest, and it is a very large part of the regional economy. Construction and engineering contracts had been accounted for under the previous construction contract guidance, and IFRS 15 replaced that with the general model — requiring an assessment of whether revenue is recognised over time or at a point in time, and, where over time, a defensible measure of progress. Add the regional realities: long payment cycles, retention amounts held for extended periods, variation orders agreed verbally on site and documented months later, claims that may or may not be recovered, and liquidated damages exposure. Variation orders are the sharpest issue — they are contract modifications requiring a decision about whether they represent a separate contract or a reallocation of the existing one, and in an environment where the paperwork routinely trails the work by a quarter, the accounting cannot be produced on time without changing how site and commercial teams document change. Three further regional specifics. Agency and distribution arrangements are ubiquitous and force the principal-versus-agent assessment, which determines whether you recognise gross revenue or a net commission — a distinction that can transform reported turnover and that regional groups had not always analysed rigorously. Rebate and incentive structures with suppliers and customers, common in distribution, are variable consideration requiring estimation at inception rather than recognition on claim. And multi-entity groups spanning mainland, free zones and several countries must apply the standard consistently across entities with different systems, different local practices and different levels of finance capability — which usually means the group policy is only as good as its weakest subsidiary's ability to apply it. One timing note worth recording. For UAE entities, IFRS 15 adoption coincided almost exactly with the introduction of VAT in January 2018, which imposed its own invoicing, tax point and systems requirements. Two substantial finance systems programmes landed in the same quarter on teams that were already thin. The organisations that coped best treated them as one programme touching the same contract and billing data, rather than two projects competing for the same people.
The objection worth taking seriously
The strongest criticism is that the standards imposed very large costs to produce financial statements that are, for most companies, not materially more informative. For a business with straightforward transactions — sell a product, deliver it, get paid — the five-step model arrives at the same answer the old guidance did, after considerably more analysis. The implementation cost across the economy ran into billions, and the genuine improvement in comparability was concentrated in a relatively small set of industries with complex bundled arrangements, principally software, telecommunications and licensing. Everyone else paid for a convergence project that mattered to standard setters and analysts more than to them. The judgement load carries a second cost that is less discussed. Identifying distinct performance obligations, estimating standalone selling prices and constraining variable consideration all require management estimates — which means revenue, the single most scrutinised line in the accounts, now depends on more discretionary inputs than it did before. That is defensible when the estimates are disciplined and disclosed. It is a wider door for earnings management than the previous rules-based guidance offered, and the disclosure requirements that came with the standard are a partial rather than a complete answer. The fair counter-argument is that the previous position was genuinely bad — dozens of industry-specific rules producing incomparable treatment of economically identical arrangements, and a bright-line regime that was gamed routinely by structuring contracts around it. Principles-based standards are harder to apply and harder to game structurally. And the discipline had a real side-benefit that finance teams tend to concede privately: the exercise forced many organisations to read their own contracts properly for the first time, and what they found — inconsistent terms, undocumented side agreements, obligations nobody was tracking — was frequently worth knowing for reasons that had nothing to do with accounting. The practical conclusion for a mid-market business is proportionality. Do the contract inventory and the performance obligation analysis once, properly, per contract type. Document the methodology. Then keep the ongoing process as mechanical as possible, because a judgement-heavy process re-performed every quarter by a small team is where errors and audit adjustments come from.
Common Questions
Does the standard change how much revenue a business earns?
No — it changes when revenue is recognised and how it is presented. Total revenue over the life of a contract is unchanged; the pattern, and sometimes the gross-versus-net presentation, is what moves.
What causes the most difficulty in practice?
Standalone selling prices for items never sold separately, and contract modifications. The first is new master data requiring a documented methodology; the second requires capturing change as an event rather than as a replacement document.
Can this be handled without changing the ERP?
For simple contract structures, yes. For bundled arrangements, variable consideration or high contract volumes, an offline calculation becomes an unauditable dependency — and the data gap is upstream, so it cannot be closed in the ledger.
How would AI change this work today?
Most usefully in contract reading, which is where the cost sits. Extracting obligations, terms, pricing, renewal options and modification clauses from a contract population that exists as PDFs and scans is exactly the task language models are good at, and it turns a multi-month manual exercise into a reviewable draft — with the strong caveat that revenue is an audited assertion, so extraction must be sampled and verified rather than trusted, and the methodology must remain human-owned and documented. Three further points. Bilingual contracts, common regionally, are now practical to process at scale, which removes a real barrier. Anomaly detection across recognition schedules catches the contract booked against the wrong template far better than quarterly review does. And auditability is the binding constraint on anything further: an AI-generated allocation that cannot be explained and traced to contract language will not survive an audit, so the defensible pattern is AI for extraction and exception-finding, and deterministic, documented logic for the calculation itself.
Revenue Recognition Assessment — start from the contract, fix the data upstream, and keep the ledger free of permanent spreadsheet bridges.