IFRS 15: Why the Ledger Differs from the Invoice
Last updated 12 Oct 2026
At a glance
The invoice says what the customer owes this month. The ledger, under IFRS 15 (ASC 606 in the US), says what the operator has earned. For a handset sold with a plan the two deliberately differ, and the gap has to be calculated by a revenue engine fed with catalog and order data, not only billing output.
The picture
One contract, two views: what is invoiced on day one, and what has been earned
1 · Contract
The invoice view: £30 a month, nothing for the handset
2 · Allocate by standalone selling price
Handset
Service plan, 24 months
£720 split in proportion to £480 : £600
3 · Day one
£320
contract asset
Unwinds as each £30 invoice exceeds the £16.67 of service revenue earned that month
How it works
Earned is not the same as invoiced
IFRS 15 recognises revenue when each promise in a contract is delivered, at a share of the contract price. Billing invoices on the commercial schedule. When a handset and a plan are sold together, the two schedules diverge on purpose, and the ledger’s revenue will not equal what was invoiced.
Why the handset changes the numbers
When a handset and a service plan are sold as one contract, IFRS 15 splits the total price across the two by their standalone selling prices. A heavily subsidised handset is therefore allocated more revenue than the customer paid for it up front, and that revenue is recognised when the handset is handed over. The difference becomes a contract asset: revenue already earned that will only be invoiced over the life of the plan.
Three more effects
- Commissions paid to dealers and sales staff to win a contract are capitalised and amortised over its life, rather than expensed at once.
- Instalments for a handset paid over more than twelve months can contain a financing component.
- Plan changes mid-contract can force the allocation to be recalculated.
What the revenue engine needs
To do the allocation, the revenue engine, whether the ERP’s own or a dedicated one, needs the bundle’s composition, the contract term and the standalone selling price of each element. Those come from the product catalog, COM and product inventory, not only from billing. This feed is the one most often missed: a programme connects billing to the ledger and discovers at audit that the contract data never arrived.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Contract asset / contract liability | ERP or a dedicated revenue engine | — | Billing, COM | The accounting view of revenue; never shown on the invoice. |
| Standalone selling price | Product Catalog | — | Revenue engine | Held per element of the bundle so the engine can allocate. |
| Bundle composition and contract term | COM (order), then Product Inventory (TMF637) | — | Revenue engine | What was sold, as which elements, for how long. |
| Invoice | Billing | — | Revenue engine | What the customer owes; one input, not the answer. |
| Capitalised contract cost (commissions) | ERP | Commission engine | — | Amortised over the life of the contract. |
In practice
The revenue engine is either the ERP’s own revenue recognition or a dedicated product beside it. Either way it sits downstream of BSS and needs contract-level data from it. Billing integrations built before IFRS 15 often carry only summarised totals, which is enough for the ledger and not enough for allocation.
The trade-off
What it solves
A revenue engine fed with contract data recognises revenue as each promise is delivered, and can explain the gap between invoice and ledger contract by contract.
What it does not solve
- Missing contract data for customers sold outside the catalog.
- Standalone selling prices that the catalog never held.
- Receivables ownership, which is a separate decision.
What it adds
- A contract-level feed from catalog, COM and product inventory, beside the billing feed.
- Reallocation whenever a plan changes mid-contract.
- A fourth truth to reconcile: ledger revenue against invoiced amounts.
Architecture decision
Where is the IFRS 15 allocation calculated?
The ERP’s own revenue recognition
Choose when contract volumes and bundle structures are within what the ERP module handles, and finance wants one platform.
A dedicated revenue engine
Choose when contract volumes are high or bundles complex, and the engine posts results to the ERP ledger.
Breaks if the engine is fed from billing alone. Without bundle composition, term and standalone selling prices it cannot allocate, and the gap shows at audit.
Takeaways
Key Takeaways
- IFRS 15 splits a bundle’s price across handset and service by standalone selling price
- A subsidised handset creates a contract asset the invoice never shows
- Commissions are capitalised, long instalments can carry financing, and plan changes force reallocation
- The revenue engine needs catalog and order data, not just billing output
Check yourself
A handset is given free with a 24-month plan. Why does the ledger show handset revenue on day one when nothing was invoiced for it?Show answerHide
IFRS 15 allocates the contract price across handset and plan by standalone selling price and recognises the handset’s share at handover. The earned but unbilled amount is a contract asset that unwinds as monthly invoices exceed the service revenue earned each month.
A programme has connected billing to the ERP ledger and calls the revenue integration done. What do you check?Show answerHide
Whether the revenue engine receives bundle composition, contract term and standalone selling prices from the catalog, COM and product inventory. Billing totals alone cannot drive the allocation.