The board pack is due on the tenth working day. Three entities run on Dynamics 365. The business acquired last year still runs on QuickBooks Online, and the Indian subsidiary uses a local accounting package. Each month someone in group finance exports five trial balances, pastes them into a workbook and maps accounts with lookups that only they fully understand. When a local team opens a new account, the pack quietly misstates a line until someone notices.
That is what multi-entity reporting looks like in many mid-sized groups. The usual answers are a single ERP or a data warehouse, and both are multi-year projects. This guide covers the middle path: a mapping layer and a common chart that sit outside the ERPs, read from them without changing them, and produce a consolidated view you can trust each month.
Why multi-entity reporting breaks across different ERPs
The workbook is rarely the root problem. It is where four structural differences meet.
Different charts of accounts. Each entity built its chart for its own statutory and tax needs. One splits travel into six accounts, another has one. Revenue may be split by product in one system and by customer type in another.
Different dimensions. Cost centres, departments, projects and locations exist in one ERP and not in another, or carry different codes for the same thing.
Different currencies and calendars. Entities book in their own functional currency, and some close on a different date or on a different fiscal year for local reasons.
Different policies. Capitalisation thresholds, revenue recognition and accrual habits vary, especially after an acquisition. Mapping can line up the accounts. It cannot make two policies agree.
Manual consolidation also eats time. APQC's benchmark for completing monthly consolidated financial statements puts the cross-industry median at 6 days from trial balance to agreed consolidation, with top performers at 5 days and bottom performers at 10 (data from 2022, published May 2025). In a group on several ERPs, mapping, intercompany and eliminations take up a good part of those days.
A common chart and a mapping layer
The foundation is a group chart of accounts at the level the board, lenders and group management actually report on. It should be smaller than any local chart. Local accounts map to it many-to-one.
The mapping layer is the set of rules that turns each entity's trial balance into the group chart. It is held outside the ERPs, so no local system has to change.
| Layer | What it holds | Who owns it |
|---|---|---|
| Source trial balances | Each entity's balances by local account, period and currency, read from its ERP | Entity controller |
| Account mapping | Local account to group account, with effective dates | Group reporting |
| Dimension mapping | Local cost centres, departments and locations to group segments | Group reporting, with FP&A |
| Policy adjustments | Entries that align local policies to group policy | Group reporting, reviewed by the group controller |
| Group chart | The reporting lines used in the consolidated pack | Group CFO |
Three rules keep the layer reliable.
Unmapped means blocked. A local account with a balance and no mapping lands in an unmapped bucket that must be cleared before the pack is issued. It never falls silently into "other".
Map by effective date. When a mapping changes, the change has a start date. Prior periods still use the old mapping, so last year's pack can be reproduced exactly.
Control totals on every run. Each mapped trial balance must sum to the same total as the source, in local currency, before anything is translated. If it does not, something was dropped in the read.
Consolidation and eliminations
Once each entity's balances sit in the group chart, consolidation follows the same steps whatever ERPs are underneath.
Translation. Balance sheets are generally translated at the closing rate and income statements at average or transaction-date rates, with the difference going to a translation reserve. Use one rate table for the whole group, from one source, held in the mapping layer rather than in each ERP.
Eliminations. Remove what the group owes and sells to itself.
| Elimination | What it removes | Depends on |
|---|---|---|
| Intercompany balances | Receivables and payables, loans and accrued interest between entities | Both sides agreeing, by counterparty |
| Intercompany revenue and cost | Sales, recharges and management fees between entities | Consistent counterparty coding |
| Dividends | Dividends paid and received inside the group | Entity-level records of declarations |
| Investment and equity | The parent's investment against the subsidiary's share capital and pre-acquisition reserves | Acquisition accounting records |
| Unrealised profit | Margin on goods sold inside the group and still in inventory at period end | Inventory held by counterparty and intercompany margin |
Non-controlling interests. Where a subsidiary is not wholly owned, the outside share of its results and net assets is shown separately. Ownership changes in the year need their own entries.
Eliminations only work when intercompany balances agree first. If they do not, the consolidation shows a difference that someone books to a plug account, and that account grows. Last week's issue, Intercompany Reconciliation: Why It Breaks Across Entities and Systems, covers the matching rules and settlement routine that make eliminations clean.
Read-only connectors or a data warehouse project
There are two broad ways to get data out of several ERPs into one view. Both are legitimate. They solve different problems.
| Read-only connectors and a mapping layer | Data warehouse project | |
|---|---|---|
| What it reads | Trial balances and, where needed, transaction detail, through each ERP's API or standard exports | Most tables from each source, loaded on a schedule into a central store |
| What it changes in the ERPs | Nothing; access is read-only | Nothing in principle, but often requires extraction agents and IT involvement in each system |
| Who builds and runs it | Finance, with modest technical support | A data engineering team |
| Time to first useful pack | Shorter, because the scope is the trial balance and the mapping | Longer, because data models and pipelines come first |
| Drill-down | To transactions in the source ERP | To anything loaded, across finance and operations |
| Best suited to | Financial consolidation, management reporting, board packs | Large-scale operational analytics across many systems |
| Main risk | Mapping governance lapses | Project runs long and finance waits for it |
For financial consolidation, the connector route is usually the right first step. The trial balance is a small, well-defined dataset. Finance can own the mapping. And it does not depend on a project that competes for IT time with everything else.
A data warehouse earns its cost when the questions go beyond the ledger: margin by SKU across channels, unit economics from operational systems, or data science work. When that time comes, the governed mapping layer becomes an input to the warehouse rather than something to rebuild.
There is a timing argument too. Many groups on SAP ECC are planning a move anyway: under the strategy SAP announced in February 2020, mainstream maintenance for Business Suite 7 core applications, SAP ERP 6.0 among them, runs to the end of 2027. Waiting for one ERP before fixing reporting can mean waiting years. A mapping layer survives a migration: when an entity moves systems, you remap that one entity and keep the group view running.
Governance of the mapping
The mapping layer becomes part of how the group produces its numbers, so it needs the same discipline as a ledger.
One owner. Group reporting owns the mapping. Entity controllers propose changes; they do not make them.
Maker and checker. Every mapping change is made by one person and approved by another before it affects a pack.
A change log. Each change records the account, the old and new mapping, the effective date, the reason and who approved it. Auditors will ask for this.
A monthly unmapped review. New local accounts are mapped before close, not discovered in the pack.
Period lock. Once a pack is issued, the mapping for that period is locked. Restatements are deliberate, logged and explained.
Access. Connectors read only. Nobody changes source data through the reporting layer.
Where AI helps
AI is useful around the edges of this work, with a person approving every change.
Suggesting mappings. When a local team opens a new account, a model can propose a group mapping from the account name, its posting history and how similar accounts are mapped elsewhere. Group reporting accepts or corrects it.
Spotting mapping errors. An account whose balance behaves unlike the other accounts on its group line, such as a credit balance in an expense line, is worth a second look.
Drafting commentary. A first draft of the variance narrative by entity and line. The numbers are pulled from the consolidated ledger; the model's job is to describe them, not to produce them.
What can go wrong: a plausible but wrong mapping suggestion accepted at speed. That is why mapping changes go through the same maker and checker review whoever proposed them.
What a mapping layer will not fix
It will not align accounting policies. If two entities recognize revenue differently, the consolidated numbers will show both treatments until someone posts a policy adjustment or changes local practice.
It will not replace a statutory consolidation where one is needed, or the judgment behind acquisition accounting, impairment and non-controlling interests. It gives you clean, reproducible inputs to that work.
Frequently asked questions
How do you consolidate entities that use different ERPs?
Map each entity's local accounts to a single group chart in a mapping layer outside the ERPs, translate at group rates, then eliminate intercompany items. The ERPs stay as they are.
Do I need a data warehouse for multi-entity reporting?
Not for financial consolidation in most mid-sized groups. Read-only connectors to each ERP plus a governed mapping layer give a group view sooner, and a warehouse can follow when operational analytics need it.
What is a mapping layer in consolidation?
It is the set of rules that converts each entity's local trial balance into the group chart of accounts and segments, with effective dates and a change log, held outside the source systems.
Who should own the chart of accounts mapping?
Group reporting should own it, with entity controllers proposing changes and a second person approving each change before it affects a reporting pack.
What intercompany items need to be eliminated?
Intercompany balances, intercompany revenue and cost, dividends within the group, the parent's investment against subsidiary equity, and unrealised profit on goods still held inside the group.
Should we wait for an ERP migration before fixing group reporting?
No, a mapping layer can run on the current systems and survives a migration, because only the migrating entity needs to be remapped.
Where CFOLogic fits
We design and build read-only reporting layers across the systems a group already runs, whether SAP, Microsoft Dynamics, QuickBooks Online or a local package, with group finance owning the mapping and a person approving every change. A single view across entities and systems is an approach we work on with CFOs, usually starting with a proof of concept for a few entities. The Navigator live demo, which uses fictional data, is one example: read-only access to QuickBooks Online, Xero or CFOLogic's hosted ledger, consolidation across entities, and plain-English answers whose figures trace back to transactions. CFO Success Partners describes how we work with CFOs.