"Did BC post it?" is the wrong question

Yesterday I spoke at the D365PPUG UK meeting in Manchester on a topic I keep coming back to: the point where an accounting standard meets a Business Central setup page. This post is the written companion to that session - the same argument, the same worked examples, in a form you can keep on your desk for Monday morning.

Let me start where I started on stage.

Picture a perfectly configured Business Central. Every process automated. Every entry posted. No errors, no warnings, no audit exceptions. And the revenue figure is still wrong.

Not a bug. Not a typo. The system did exactly what it was told to do. The problem is that the specification it was told to follow was never aligned with the accounting standard. That gap - between what BC will happily post and what the standard actually requires - is the whole subject of the talk, and it runs through every one of the standards below.

Business Central is a configurable ERP. It gives you the tools. Knowing the standard is what lets you configure those tools correctly and recognise where they run out. The D365 community has deep functional BC knowledge and it is necessary too; the IFRS accounting bridge is the part that's underserved. So, here's the bridge, standard by standard.

Two layers of one craft

Getting a BC finance build right is really two skills sitting on top of each other.

The first is architecting Business Central: knowing where every setup page lives, how posting groups drive the G/L, how dimensions flow, how Subscription Billing, Project WIP, Fixed Assets, currency adjustment and consolidation actually behave. That's the functional layer, and the community is strong on it.

The second is knowing when the result is correct - understanding that compliance is determined by the standard, not the software. When revenue may and may not be recognised. When an effective interest rate overrides the contractual rate. Why an expected credit loss is a different animal from an aged-debtors report. That second layer is the differentiator, and it's the one BC can't give you.

IAS 2 - Costing inventory, and the LIFO trap

IAS 2 carries inventory at the lower of cost and net realisable value, permits only FIFO or weighted average for interchangeable goods, and requires write-downs to be reversed when conditions recover (capped at original cost). FRS 102 Section 13 - the most common UK SME framework - asks for the same treatment.

BC's costing methods map onto this cleanly, with one exception. FIFO, Average, Standard (where it approximates actual) and Specific are all fine. LIFO is not. IAS 2 banned it in 2005, and yet BC still offers it as a costing method. Inheriting a client who "has always used LIFO" means inheriting a non-compliant system. BC will post precisely what it's told here, so the standard has to be applied at configuration.

The subtler IAS 2 point is cost completeness. Cost is the purchase price plus all the costs of bringing the item to its present location and condition - freight, duty, insurance, handling. BC has no separate landed-cost engine; you post these through Item Charges assigned back onto the original receipt. Miss them and inventory is understated and margin overstated. For manufacturers, the same completeness principle lives in Production Order WIP, with capacity and variance posting as the order runs. Run Adjust Cost – Item Entries before you close the inventory period, and reconcile open production orders before any stock valuation sign-off.

IAS 21 Currency

IAS 21 turns on three currency concepts, and each has a home in BC. The functional currency is the entity's primary economic environment, set once as LCY at G/L setup. The transaction currency is the code on the document, converted to LCY at the posting-date rate. The presentation currency - what the statements are shown in - is handled by BC's Additional Reporting Currency, which auto-translates posted amounts. FRS 102 Section 30 follows the same model, so the BC configuration is identical for UK GAAP preparers.

Here's the gotcha I most wanted people to leave with. BC's Adjust Exchange Rates batch revalues customer, vendor and bank entries - the subledgers. A foreign-currency loan posted directly to a G/L account, with no subledger behind it, is invisible to that batch. That balance used to sit at its historic rate with no native fix - until BC 2023 Release Wave 2 resolved exactly this.

The fix is genuinely newer functionality: Source Currency on the G/L Account Card, introduced in BC 2023 Release Wave 2. You allow-list the currencies per account, then run Revalue General Ledger Account Balances. Before that release there was simply no native fix. If a client has a foreign-currency loan sitting straight in the G/L, check this before the period-end close - and note that the same fix serves FRS 102 preparers under Section 30.

IFRS 16 - Leases onto the balance sheet, by hand

IFRS 16 brought an estimated $3.3 trillion of lease obligations onto balance sheets worldwide. The model is three steps: identify the lease, measure at commencement, then measure subsequently. In BC, all three lean on judgement - with an extension available to carry the repeatable math.

At commencement, the lease liability is the present value of future payments discounted at the incremental borrowing rate, and the right-of-use asset is that liability plus initial direct costs and prepayments. Subsequently, the liability unwinds using the effective interest method while the ROU asset depreciates straight-line over the shorter of lease term or useful life.

BC has no native lease-liability engine. You set up the ROU asset in the Fixed Assets module (asset class Right-of-Use, straight-line over the lease term, residual usually £0), then post manual journals each period for the interest unwinds. Short-term (under 12 months) and low-value (under ~$5k) exemptions aren't enforced by the system - they're a policy decision you apply at setup. Lease modifications compound the manual effort: a substantial change is accounted for as a brand-new lease (close the old FA card, open a new one); a non-substantial change is a remeasurement journal against the liability and ROU asset.

And this matters for UK GAAP too now: FRS 102 Section 20, effective 1 January 2026, brings the same on-balance-sheet model with a simplified incremental borrowing rate. The same BC configuration approach carries straight over.

IFRS 9 - Two calculations BC won't do natively (but a small AL extension can)

Two IFRS 9 mechanics have no home in native BC.

The first is the effective interest rate. Where fees are material, the EIR differs from the contractual rate, and posting a finance lease or an originated loan at the contractual rate is non-compliant. Building the EIR schedule needs an AL extension plus a Power Automate recalculation each period. (Operating leases, by contrast, recognise income on a straight-line basis and need none of this.) Transaction costs - legal fees, broker commission, credit assessment - are capitalised into the opening carrying amount, not expensed.

The second is expected credit loss. IFRS 9 provisions for credit losses from day one, forward-looking, staged: Stage 1 (12-month ECL), Stage 2 on a significant increase in credit risk, Stage 3 once the asset is credit-impaired, both lifetimes. BC's aged-debtors report is backward-looking - it tells you what's overdue, not what's expected to default. They are not interchangeable. The practical approach is to compute ECL outside BC (an Excel matrix or Power BI model over the ageing, with probability-of-default and loss-given-default assumptions: ECL = PD × LGD × EAD), then post a periodic IFRS adjustment journal (Dr ECL Expense / Cr Provision) tagged with an IFRS9 dimension, reversing and updating each period.

Worth noting for UK SMEs: FRS 102 keeps the incurred-loss model - no ECL required.

IFRS 15 - The flagship: one deal, three BC modules

This was the heart of the session. IFRS 15's five-step model is where multi-element deals most often get complex - and where thoughtful BC configuration makes the difference between a plausible result and a compliant one.

I ran all five steps through a single worked contract. TechCo signs RetailCo on 1 January 2026 for £150,000, and that one deal contains three distinct performance obligations, each recognised through a different BC module:

• a £60,000 software licence - point in time, on delivery, via a Sales Order;

• a £42,000 implementation - over time by percentage of completion, via a Project / Job;

• a £48,000 two-year support contract - over time, via Subscription Billing.

All three are bound together by a single CONTRACT dimension so they report as one arrangement.

The steps that trip people up are the middle three. In Step 1, all five contract criteria must hold before revenue exists - and collection being probable is one of them. BC will happily post to a doubtful payer; IFRS 15 says stop. The system won't enforce it, so your process must.

In Step 4, you allocate the transaction price by relative standalone selling price. TechCo's SSPs sum to £160,000, so the £150,000 price carries a £10,000 bundle discount spread pro-rata. Recognition then diverges from invoicing: the licence recognises £63,750 against £60,000 invoiced, implementation £37,500 against £42,000, support £48,750 against £48,000. The critical discipline - never edit the sales order unit price to the allocated amount. The customer agreed to £60k / £42k / £48k, and that's what you invoice. The allocation delta lives in a contract-balance control account and nets to nil once the last obligation is satisfied. A contract asset is not a receivable; keep it off the aged-debtors report.

BC doesn't ship with an SSP allocation engine - and it doesn't need to, because the wider Microsoft ecosystem answers this elegantly. The allocation runs as a Power Automate flow: triggered when the contract is booked, reading SSP percentages from an audit-source workbook or Dataverse table, splitting the discount, and posting the recognition journal to the contract-balance account - while the invoice itself is never touched, and the journal references the SSP workbook by number for the auditor.

Step 5 then recognises revenue as control transfers, independent of invoicing: the licence at a point in time on delivery, the implementation via Project WIP (cost-to-cost % completion - 40% at 28 February in the example), the support released monthly from deferred revenue. Invoice equals cash; control transfer equals P&L; the gap between them is the contract balance.

The same BC config under FRS 102 (2024)

The thread running under all of this: from 1 January 2026, the revised FRS 102 pulls thousands of UK SMEs into the same configuration challenges. Section 23 adopts the IFRS 15 five-step model. Section 20 brings IFRS 16's on-balance-sheet lease model. The BC setup is, in both cases, identical to the IFRS approach - same Sales Order / Projects / Subscription Billing for revenue, same FA-card-plus-manual-journals for leases.

The differences are in the edges: small companies under Section 1A get disclosure relief, not recognition relief; micro-entities on FRS 105 are exempt from the revenue model entirely; FRS 102 keeps the incurred-loss model (no ECL); and IFRS 18's new presentation categories don't apply to UK SMEs. One BC setup, two frameworks - with a handful of deliberate divergences to know.

Where BC stops and Power Platform starts

Setting out the native gaps honestly is also how you find the build opportunities. BC handles multi-currency and IAS 21 revaluation, FIFO/Average/Standard costing, Fixed Assets with multiple depreciation books, dimensions for framework tagging, Project % completion and Subscription Billing natively. What it doesn't have is an EIR engine, an ECL engine, an SSP revenue-allocation engine, an impairment/CGU workflow, or a deferred-tax note - and, of course, it still offers prohibited LIFO.

Every one of those gaps is a Power Platform opportunity: an AL extension plus Power Automate flow to recalculate the EIR schedule; Power BI to compute staged ECL; Power Automate to allocate SSP and release deferred revenue on schedule; a Power App lease register with remeasurement and approvals. The gap between the ERP and the standard is exactly where a solution architect earns their keep.

The recap

In every example in the session, BC ran without an error. No warning, no flag, no audit exception. The system did exactly what it was told.

Business Central does not build compliant processes. Something has to. You do.

The question is never "did BC post it?" It is "should it have?"

This session is one part of an ongoing effort to close the IFRS-in-BC gap for the community - practical, ERP-specific content written for practitioners. More is coming: further blog posts in this series, additional D365PPUG sessions, YouTube walkthroughs, and GitHub AL snippets for IFRS extensions. If this was useful, follow the series at bcforfinance.com and connect with me on LinkedIn - let's keep the conversation going.

Shailesh Apte - ACA (ICAEW), FCA (ICAI), PMP · Director Solution Architect, Business Central