AI IFRS 18 Reporting Automation: 2026 Practitioner Walkthrough

IFRS 18 is, at its core, a data-classification and disclosure-generation problem. That makes it unusually well-suited to automation, but only if the classification rules are correctly specified by humans first. This walkthrough is for group controllers, CFOs, and financial reporting managers who need to understand exactly what AI and automation can do across the five IFRS 18 workstreams, where human judgment remains non-negotiable, and how to sequence the work before the 1 January 2027 mandatory date closes the window.

For a grounding in the hardest implementation challenges and the overall timeline, see our IFRS 18 implementation challenges guide. This article goes one level deeper: the automation architecture, the judgment boundaries, and the controls your auditors will scrutinise.

Key takeaway: A connected reporting platform cannot generate compliant IFRS 18 output if the underlying GL data has not been reclassified first. Automation helps enormously, but it starts at the ledger, not the disclosure layer.

Why IFRS 18 Is an Automation Problem (Not Just a Disclosure Problem)

IFRS 18, issued by the IASB on 9 April 2024, replaces IAS 1 and is mandatory for annual periods beginning on or after 1 January 2027. Full retrospective restatement of 2026 comparatives is required, no modified retrospective option exists, per Deloitte's IAS Plus analysis. That means IFRS 18-compliant data must be captured throughout 2026, making 1 January 2026 the operational deadline, not 2027.

The structural changes the standard introduces are not cosmetic:

• Three defined income and expense categories on the face of the income statement: operating, investing, and financing.
• Two new mandatory subtotals: operating profit and profit before financing and income taxes (PBFIT).
• Management-defined Performance Measure (MPM) disclosures: any non-GAAP subtotal used in public communications must appear in the audited notes with a line-by-line reconciliation to the nearest IFRS-defined subtotal, including tax and NCI adjustments.
• Five natural expense categories that must be disclosed when expenses are presented by function: depreciation, amortisation, employee benefits, impairment losses, and inventory write-downs.

Every one of these requirements touches the GL. As EY's IFRS 18 implementation guidance notes, many entities will need to capture data at a more granular level than their current chart of accounts supports, making chart-of-accounts redesign a prerequisite for automation, not an alternative to it.

The scale of change is comparable to IFRS 9 or IFRS 16 in systems impact, per the IASB's April 2024 press release. Yet as of Q1 2025, approximately 80% of IFRS preparers surveyed had not started an implementation project. The runway is short.

The Five IFRS 18 Automation Use Cases

Best-practice IFRS 18 automation tools address five distinct workstreams. Each maps to a specific standard requirement.

Step 1: GL Classification Engine

The classification engine is the foundation. Everything downstream depends on getting this right.

The engine extracts GL data from your ERP (SAP, Oracle, Workday, or equivalent) and maps every income and expense line to one of the five IFRS 18 categories: operating, investing, financing, income taxes, or discontinued operations. Classification runs by nature crossed with activity, not just account code.

The critical architectural point is what practitioners call rules-as-data: classification logic lives in editable tables controlled by the policy team, not hard-coded in software. As ContractHive's Hive18 documentation describes it: "Classification is rules-as-data: every GL line is mapped to one of the five IFRS 18 categories by rules your policy team owns and can edit without a code release."

Why does this matter? Because the IASB continues to issue guidance on edge cases, and your auditors will push back on specific classification decisions. If the rules are locked in code, every update requires an engineering release and a change-management cycle. If they sit in policy tables, your technical accounting team can update them directly, document the rationale, and the change is immediately auditable.

The GL classification engine does not replace chart-of-accounts redesign. It complements it. If your current chart of accounts cannot distinguish depreciation from amortisation at the line level, the engine has nothing to classify. ERP configuration or a supplementary data layer must bridge that gap first.

Step 2: Mandatory Subtotal Construction

Once every GL line carries an IFRS 18 category tag, the mandatory subtotals build automatically: Operating profit, then PBFIT, then profit before tax, then net profit. This is the most straightforward automation step, it is arithmetic on a correctly classified dataset.

The risk is not in the calculation. It is in the classification feeding it. A misclassified FX gain that inflates operating profit will flow through every subtotal and into the comparative period. Garbage in, garbage out, and the auditor will find it.

Step 3: MPM Reconciliation

MPM reconciliation is the most unfamiliar requirement for most finance teams, and it is where automation adds the most time-saving value.

Any non-GAAP subtotal used in public communications, adjusted EBITDA, core operating profit, underlying earnings, must now appear in the audited financial statements as an MPM, reconciled line by line to the nearest IFRS-defined subtotal, with tax and NCI adjustments shown separately. PwC's IFRS 18 In Brief notes that this goes further than the ESMA Alternative Performance Measures guidelines, because the reconciliation must appear in the audited statements rather than just in management commentary.

Automation tools can generate these reconciliation tables directly from the classified dataset, the same data that produces the primary statements. Because it is one dataset with maker-checker sign-off, every disclosed figure ties back line by line. That is the audit trail your external auditors need.

What automation cannot do: decide which management measures are caught by the MPM definition. A measure used only in internal board packs may not be an MPM. A measure cited in an earnings release almost certainly is. That scoping judgment requires documented human decisions, not an algorithm.

Step 4: Natural Expense Disaggregation

When expenses are presented by function (cost of sales, selling, G&A), IFRS 18 requires separate disclosure of five natural expense categories across all functional lines. Automation handles this cleanly, provided the GL captures the data at sufficient granularity.

For many mid-size entities, this is where the ERP gap becomes visible. If employee benefits are booked to a single cost-centre code that spans multiple functions, the disaggregation cannot be automated without either reconfiguring the ERP or building a supplementary allocation layer. Grant Thornton's IFRS 18 analysis flags this as a common gap for mid-size entities not on standardised platforms.

Step 5: Financial Statement, Notes, and MPM Generation

With a single classified dataset, automation tools generate the income statement, the required notes, and the MPM reconciliation tables in one pass. The key phrase is single dataset: financial statements, notes, and MPMs all draw from the same classified source, so figures are consistent by construction.

This is where the contrast with a connected reporting platform becomes important. A platform like Workiva is excellent at assembling and publishing disclosure documents, but it cannot generate compliant IFRS 18 output if the data feeding it has not been classified at the GL level. The reporting layer and the classification layer are different problems, and conflating them is one of the most common implementation mistakes.

Where AI Cannot Substitute for Human Judgment

Being honest about this boundary is what separates a useful implementation guide from a vendor brochure.

The IASB's September 2025 World Standard Setters Conference explicitly flagged the following as classification flashpoints where documented human judgment is required:

• FX gains and losses on external loans, leases, and intercompany loans, the category depends on the nature of the underlying instrument and the entity's main business activity.
• Fair value gains and losses, allocation across operating, investing, and financing requires analysis of what the asset or liability is doing in the business.
• Interest expense on pension liabilities and provisions, operating or financing depends on the nature of the obligation.
• Insurance service costs, entity-specific facts drive the classification.

The hardest judgment of all is main business activity determination. The investing category covers income and expenses from assets that generate a return individually and largely independently of other resources, per the IASB's March 2025 academic workshop. For a single-product manufacturer, this is clear. For a conglomerate with financial services subsidiaries, or a group where the same GL line classifies differently by entity, it is not.

Interest income is operating for a bank, investing for a manufacturer. Automation tools must handle per-entity classification profiles, but the policy decision about which profile applies to which entity must be made and documented by humans.

Key takeaway: Classification rules must be specified by your technical accounting team before the engine runs. The engine enforces the rules at scale. It does not write them.

The IASB also provides relief from some classification requirements where they would result in undue cost or effort, and accounting policy choices exist for specific income and expense types. These elections must be documented and applied consistently, another area where automation needs human-defined policy inputs, not algorithmic defaults.

The Audit Trail Requirement: Not Optional

Auditors signing off on the new mandatory subtotals will need to trace every classified line back to source GL data. This is not a best-practice recommendation, it is a functional requirement of any compliant automation solution.

A robust audit trail for IFRS 18 automation includes:

1. Full lineage from source GL entry to classified category to subtotal to disclosed figure.
2. Maker-checker controls, the person who sets the classification rule is not the same person who approves it.
3. Version history of classification rules, with timestamps and rationale for changes.
4. Exception logs for lines that could not be auto-classified and required manual override.
5. Reconciliation between ERP source data and classified dataset at period close.

Panelists at the December 2025 KPMG preparer forum cautioned explicitly against planning for manual IFRS 18 workarounds, particularly for organisations that already rely on automated reporting systems. For groups with quarterly or semi-annual reporting, manual adjustments are not sustainable at scale.

The Multi-Entity Group Problem

For groups with diverse operations, the classification problem multiplies by entity count. The same GL account code can fall into different IFRS 18 categories depending on the entity's main business activity. A group treasury entity's interest income is operating. The same interest income in a manufacturing subsidiary is investing.

Automation tools must therefore support per-entity classification profiles, not a single group-wide ruleset. The policy team needs to define and approve each entity profile, and the system needs to enforce the correct profile at consolidation. This is one of the clearest differentiators between a genuine IFRS 18 automation platform and a rebranded spreadsheet tool.

For groups already running AI intercompany elimination automation, the entity-level data structure required for IFRS 18 classification overlaps significantly with the intercompany matching layer, worth scoping together rather than as separate projects.

Vendor Evaluation Checklist for IFRS 18 Automation Tools

The vendor landscape is noisy. Here is a non-promotional, criteria-based framework for evaluating tools:

Must-have capabilities:

• Rules-as-data architecture (policy team controls classification tables without engineering releases)
• Per-entity classification profiles for multi-entity, multi-industry groups
• ERP connectivity to your actual system (SAP, Oracle, Workday, confirm the specific integration, not just a generic API claim)
• Mandatory subtotal construction (Operating, PBFIT, PBT, Net Profit) enforced automatically
• MPM reconciliation generation from the same classified dataset as the primary statements
• Full audit trail with maker-checker controls and GL-to-disclosure lineage
• Natural expense disaggregation at the five IFRS 18 categories

Questions to ask in the RFP:

• Can we see a live demo with our actual chart of accounts, not a sample dataset?
• How does the tool handle classification rule changes mid-year, what is the version control and approval workflow?
• What does the exception log look like for lines that cannot be auto-classified?
• How does the tool connect to our consolidation system, and does it handle the IFRS 18 classification before or after consolidation?
• What is the audit trail format, and has it been reviewed by a Big Four firm?
• How does the tool handle the IASB's accounting policy elections and cost-or-effort reliefs?

Red flags:

• The vendor describes IFRS 18 primarily as a disclosure challenge and leads with a reporting platform rather than a GL classification engine.
• Classification rules are hard-coded and require a vendor release to update.
• The demo uses a generic chart of accounts that does not reflect your industry or entity structure.
• The audit trail is a PDF export rather than a live, queryable lineage.

For a broader framework on evaluating AI financial reporting tools, see our AI financial reporting software comparison.

Sequencing the Implementation: What to Do Now

With the 2026 parallel run already underway for well-prepared teams, here is the practical sequencing for those still building their approach:

1. Complete the impact assessment, identify every GL line that changes category under IFRS 18, every MPM used in public communications, and every entity with a non-obvious main business activity determination.
2. Redesign the chart of accounts, ensure the GL can capture the five natural expense categories and the data granularity the classification engine needs. This is a prerequisite, not a parallel track.
3. Define classification rules and entity profiles, your technical accounting team specifies the rules; the automation tool enforces them. Document every judgment call, especially the flashpoints flagged by the IASB.
4. Configure ERP connectivity, extract, transform, and load GL data into the classification engine. Confirm the integration handles your specific ERP version and consolidation structure.
5. Run the parallel system throughout 2026, capture IFRS 18-compliant data alongside your current IAS 1 reporting. This is the comparative period data you need for the 2027 annual report.
6. Generate and review MPM reconciliations, scope which management measures are caught, build the reconciliation templates, and get auditor pre-engagement on the output format.
7. Pre-engage auditors on judgment areas, particularly main business activity determinations, FX classification, and any accounting policy elections. Do not wait until the year-end audit.
8. Review debt covenants and remuneration frameworks, the new mandatory subtotals may differ from the EBITDA or operating profit definitions in existing agreements. Model the differences before go-live.

The IASB's educational materials and illustrative examples, published in late 2024 and 2025, include worked MPM reconciliation tables and category classification decisions. These are the primary reference documents for specifying your classification rules, use them, and make sure your automation vendor has built against them.

FAQ

Does IFRS 18 automation replace our chart-of-accounts redesign? No. The classification engine needs granular GL data to work with. If your chart of accounts cannot distinguish depreciation from amortisation, or employee benefits by function, the engine cannot classify correctly. Chart-of-accounts redesign is a prerequisite.

Will auditors accept AI-generated MPM reconciliation disclosures? Yes, provided the output is traceable to source GL data through a documented audit trail with maker-checker controls. Auditors need to verify the figures, not the method. The audit trail is the critical requirement.

What is the difference between rules-as-data and hard-coded classification? Rules-as-data means your policy team edits classification logic in tables they control directly, without a software release. Hard-coded classification requires a vendor engineering change for every rule update. For IFRS 18, where the IASB continues to issue guidance and entity-specific judgments evolve, rules-as-data is the only viable architecture.

How does IFRS 18 automation interact with our existing ERP? Best-practice tools extract GL data directly from your ERP via API or scheduled feed, apply classification rules, and return a classified dataset that feeds both the financial statements and the consolidation system. Confirm the specific integration with your ERP version before selecting a vendor.

What if we missed the 1 January 2026 data-capture window? The 2026 parallel run is the last viable path to clean comparatives. If your systems are not live by mid-2026, you face a retrospective restatement of 2026 data under time pressure in early 2027. That is a significant audit and operational risk for any organisation with quarterly reporting.

Does IFRS 18 apply to our group, and does EFRAG endorsement affect EU entities? IFRS 18 applies to all entities reporting under IFRS Standards across more than 140 jurisdictions. EFRAG has preliminarily endorsed it as conducive to the European public good, and EU adoption is on track, so EU IFRS reporters should plan on the same 2027 mandatory date.