How IFRS 15's core framework maps to Dynamics 365 Business Central, using Meridian Tech Solutions, a software and hardware reseller, to show multiple performance obligations, SSP allocation, and revenue timing in practice.

IFRS 15 Revenue from Contracts with Customers introduced a single, principles-based five-step model for recognising revenue across all industries and contract types.

This series applies IFRS 15 to Dynamics 365 Business Central across five posts. One contract, TechCo Ltd's £150,000 deal with RetailCo (the case walked through at the D365PPUG UK user group), runs through all five as a common thread. Each post then adds a second, deeper example in a different business context. This first part builds the foundation on Meridian Tech Solutions, a reseller whose software-plus-hardware bundle makes every step of the model concrete.

The Five-Step Model

IFRS 15 requires revenue to be recognised by applying five sequential steps to every contract with a customer. No step can be skipped. Here is each step and what it means:

1. Identify the contract with the customer

A contract exists when it has commercial substance, both parties have approved it, rights and payment terms are identifiable, and collection is probable. A contract modification (scope or price change) is accounted for separately or as part of the original contract, depending on whether it adds a distinct good or service.

→ Meridian: the signed order form and statement of work together form the contract.

2. Identify the performance obligations

A performance obligation is a promise to transfer a distinct good or service. A good or service is distinct if the customer can benefit from it on its own or with other readily available resources, and it is separately identifiable from other promises in the contract. If bundled items are not distinct, they are combined into a single performance obligation.

→ Meridian's contract has three distinct POs: software licence, implementation, hardware.

3. Determine the transaction price

The transaction price is the amount of consideration the entity expects to receive. It includes fixed amounts and estimates of variable consideration (discounts, rebates, returns, performance bonuses), but excludes amounts collected on behalf of third parties (for example, VAT). Variable consideration is included only to the extent it is highly probable that a significant revenue reversal will not occur.

→ Meridian's contract price is a fixed £185,000.

4. Allocate the transaction price to performance obligations

The transaction price is allocated to each performance obligation in proportion to its standalone selling price (SSP), the price at which the entity would sell the good or service separately. Where observable SSPs are not available, estimation methods are used: adjusted market assessment, expected cost plus margin, or the residual approach (only where SSP is highly variable or uncertain).

→ SSPs: software £95k, implementation £55k, hardware £45k (total £195k).

5. Recognise revenue when (or as) a performance obligation is satisfied

Revenue is recognised when control of the promised good or service transfers to the customer, either at a point in time (most goods) or over time (services where the customer simultaneously receives and consumes the benefit, or where the entity's performance creates an asset controlled by the customer). Over-time recognition requires a reasonable measure of progress.

→ Hardware and licence: point in time. Implementation: over time, on a percentage-of-completion basis.

Setting It Up in Business Central: Three Surfaces, One Contract

Business Central has no cross-module SSP-allocation engine, and no single document holds all three obligations. Only the goods belong on a Sales Order (the perpetual licence and the hardware), and they bill at their quoted prices. The implementation service is a Project (Job). The SSP allocation touches none of these documents: it is a recognition-only calculation, posted by journal. What ties the three together is the CONTRACT dimension, not a shared header.

Configure related documents:

1. Sales Order

Sales Order in Business Central, billing the licence and hardware at quoted prices.

2. Project

Project (Job) in Business Central, tracking the implementation service against the same contract.

The implementation service does not belong on a Sales Order at all. It is set up as a Project (Job) against the same contract, with planning lines and WIP Method = Percentage of Completion. It bills by milestone and recognises revenue over time as hours are posted. (The mechanics of this are the subject of Post 4. Had the contract also carried a support element, that would be a third surface again: a Subscription contract, billed and released monthly, covered in Post 3.)

3. Where the allocation actually lives

The SSP allocation is worked out once, in a revenue-allocation worksheet (or an ISV that stores an IFRS 15 recognition schedule per obligation), never as a field on the Sales Order or the Project. Each module keeps billing at its quoted price; the difference between billed and allocated posts to a Balance Sheet contract-control account by journal, tagged with the CONTRACT dimension.

Business Central is the execution engine; the allocation is the practitioner's overlay. There is no native “Multiple PO Allocation” method or IFRS 15 template that does this for you.

Step-by-Step Posting in Business Central

1. Deposit on signing

On contract signing, Meridian is eligible for 50% of payment, i.e. £92,500 (50% × £185,000). Under IFRS 15, this creates a contract liability: Meridian has received (or is entitled to receive) payment before transferring the goods or services. It is not revenue yet.

Using the standard prepayment invoice for the goods portion (50% of the £130,000 quoted for licence and hardware combined) against the Sales Order creates the following accounting entry:

Configuring the correct accounts and generating a sales invoice (50% of the £55,000 implementation price) from the Project module creates the following accounting entry:

2. Delivery of hardware and licence

When the hardware and licence are delivered, posting the Sales Invoice from the Sales Order creates the following accounting entries:

Since there is no native SSP engine in Business Central, an extension needs to be developed; otherwise the following journal needs to be posted manually:

3. Implementation services: revenue over time (% completion)

Implementation services of £52,188 are recognised over time using the input method: hours worked as a proportion of total estimated hours (220). As consultants post time to the job in Business Central, revenue is released incrementally as the related WIP is posted.

* The balance of the implementation fee (50%) is invoiced per the milestone schedule agreed with the customer, posted as a sales invoice from the Project: Dr Customer / Cr Contract Liability £27,500.

Additionally, a proportionate journal for release of the Revenue Allocation Clearing balance must be posted:

Contract Asset vs Contract Liability

A contract asset arises when Meridian has performed but does not yet have an unconditional right to payment. A contract liability arises when cash (or an unconditional right to it) arrives before the related good or service transfers. Both must be shown separately on the balance sheet.