How to map different charts of accounts across Xero entities

You map each entity’s accounts onto a shared group chart of accounts, rather than forcing every entity to adopt an identical chart. The mapping lives above the ledgers, so each entity keeps the account structure its bookkeepers, tax agent and local requirements need, while the group reports on one consistent structure. The critical design decision is not how you build the mapping — it is what happens to accounts you have not mapped yet.

Why not just standardise every entity’s chart of accounts?

Standardising every ledger sounds cleaner and is usually the wrong call for a group that grew by acquisition. Every Xero organisation is a separate ledger with its own chart, and rewriting an acquired company’s accounts means recoding its history, breaking its comparatives, and asking a bookkeeper who has coded the same way for six years to change. Xero has no bulk merge function for accounts; you are looking at Find and Recode, which requires advisor-level access and does not cover bank transactions, journals or locked periods.

Mapping avoids all of that. One entity calls it Consulting Income, another calls it Professional Services Revenue, and both map to Revenue — Services at group level. Neither ledger changes.

There is a real argument for gradual convergence over time, particularly for entities you control directly and for new entities you set up. Starting a new subsidiary on the group’s account codes costs nothing. Retrofitting a fifteen-year-old acquired ledger costs weeks and gains you very little, because the mapping layer was already solving the problem.

What actually goes in the mapping?

The mapping is a table linking each entity’s account codes to a group account. It is a many-to-one relationship: several entity accounts can roll into one group account, which is what makes it useful for consolidating divergent charts.

Build the group chart first, before you map anything. Design it for the reporting you actually need — the P&L lines your board looks at, the balance sheet categories your lenders ask about — rather than as a superset of every account that exists across your entities. A group chart built by union will have six hundred lines and be useless for reporting.

For a group of three to thirty entities, a group chart of a few hundred accounts is generally the right order of magnitude. Fewer than that and the reporting is too coarse to see anything; substantially more and you are maintaining mapping complexity that buys you nothing, because no board reads at that granularity.

Map the balance sheet as carefully as the P&L. Mapping effort tends to concentrate on revenue and cost lines because that is what people report on monthly, and then the first consolidated balance sheet does not balance because half the equity accounts went unmapped.

What happens to accounts you have not mapped?

This is the question that decides whether your consolidation is trustworthy, and the answer should be that unmapped balances are excluded from the group totals and reported separately alongside them.

The alternative — quietly dropping unmapped accounts into the totals as zero, or lumping them into a catch-all — produces a consolidated report that looks complete and is not. Nothing errors. No cell turns red. The total is simply lower than it should be, by exactly the amount nobody mapped, and it will stay wrong until somebody reconciles the group figure back to the sum of the entity figures and finds the gap.

Excluding unmapped balances and showing them separately means a mapping gap understates visibly. A reader sees a group revenue figure and, next to it, forty thousand dollars sitting in three unmapped accounts. That is an obvious prompt to fix something. A silently understated total is not.

Test this in whatever you use. Add an account in one entity, post to it, do not map it, and run the consolidation. If the group total absorbs it without comment, or drops without comment, you have a silent failure mode.

Is chart of accounts mapping ever finished?

No, and treating it as a setup task you complete is the most common mistake. New accounts appear continuously — a bookkeeper adds a supplier-specific expense code, an acquisition brings two hundred accounts, someone splits a cost line for a new project. Every one of those is unmapped the moment it is created.

This is why the unmapped-account behaviour matters so much. A group’s mapping is permanently incomplete by a small margin, so the system has to be honest about the margin rather than assuming it away. The realistic goal is not a mapping with no gaps; it is a mapping whose gaps are visible within a month of appearing.

Practically, that means reviewing unmapped accounts as a standing item in the close rather than as a project. It takes a few minutes when the list is short, which it will be if you look every month, and it takes a day if you look once a year.

Who should own the mapping?

One named person at group level should own it, with entity bookkeepers able to flag new accounts but not to change group mappings themselves. Mapping is a reporting decision, not a bookkeeping one — where an entity’s account lands in the group chart determines what the board sees, and that should not be decided ad hoc by whoever created the account.

Keep a record of mapping changes with dates. When a group P&L line moves unexpectedly between periods, the first question is whether the underlying activity changed or the mapping did, and without a change log you cannot answer it. This is the same class of problem as not storing the FX rates you used: if the reporting layer can change silently under you, no comparison across periods is safe.

Does mapping handle intercompany transactions?

No. Mapping determines where an entity’s accounts land in the group structure. It does not remove intercompany sales, intercompany balances, or management fees charged between entities, all of which will be double-counted in a consolidation that maps but does not eliminate.

If your group has material intercompany activity, mapping gets you to a combined view, not a consolidated one. That distinction matters if the numbers are going to a lender or an auditor. Most groups handle eliminations either by tagging intercompany accounts consistently across entities and removing them at group level, or by maintaining a separate adjustments layer that sits between the entity actuals and the published group figures.

Keeping intercompany activity in dedicated accounts in every entity, rather than mixed into ordinary revenue and expense lines, makes this dramatically easier — and it is a decision you can make now regardless of what tooling you use later.

What does good mapping look like in practice?

A mapping is working when three things are true. The group totals reconcile exactly to the sum of the mapped entity balances, with any difference explained by an identified unmapped account rather than being unexplained. Any group figure can be expanded to show which entities contributed to it. And the number of unmapped accounts is small, known, and shrinking rather than accumulating quietly.

If you cannot expand a group figure to its entity contributors, you have a total you cannot defend when someone asks why it moved. That drill-down is also what makes variance analysis across entities meaningful, since a group-level movement is only actionable once you know which entity caused it.