Intercompany Eliminations in Xero: Why They're Deceptively Hard

Most consolidation models have a tab called "Elims". It's held together with SUMIFs and a prayer, it was built by someone who's since left, and once a quarter it produces a number that nobody can fully explain. Intercompany eliminations are the part of group reporting that looks like a calculation and behaves like a logic problem.

The mechanics sound simple: one group company transacts with another, so at the group level you remove both sides. In a two-entity, single-currency group with one kind of intercompany transaction, that's all it is. In any real group, "just net them off" quietly produces wrong numbers — and this post is about why, and what elimination logic has to actually do to get it right.

The five things "intercompany" actually means

The first problem is that "intercompany" isn't one thing. It's at least five, and each has its own elimination rule.

Intercompany sales and purchases. One entity sells goods or services to another — a cross-charge, a management fee, a recharge of shared costs. The revenue on the selling side and the cost on the buying side both have to come out of the group P&L, because the group didn't sell anything to itself.

Intercompany receivables and payables. The balance sheet mirror of the above. A has a receivable from B; B has a payable to A. These should net to zero at the group level — and they almost never do without help, because of the same timing and FX issues that hit the P&L.

Intercompany loans. Long-lived balances, often in a non-base currency, often with interest accruing on both sides. The loan principal eliminates. The interest income and expense eliminate. The FX revaluation on the loan eliminates against the FX revaluation on the other side — except both sides have probably revalued at slightly different rates or on different dates, so there's a residual that needs handling.

Intercompany dividends. When one group entity pays a dividend to another. Distribution from one side, dividend income on the other. Both need to come out, plus the corresponding retained earnings movement.

Investments in subsidiaries. The parent's balance sheet carries the investment cost in the subsidiary; the subsidiary's balance sheet has the corresponding share capital. At group level, both eliminate against each other, with any difference going to goodwill or a consolidation adjustment.

Five categories, five different elimination rules. A consolidation model that handles all of them through one generic "Elims" tab is doing the work of five — usually badly.

Why "just net them off" doesn't work

The naive approach to intercompany eliminations is: identify the accounts on each side, sum them, and post a journal that zeroes them out. This works exactly once, in a model with two entities, a single currency, and one type of intercompany transaction.

In any real group, it falls over for a few reasons.

The two sides don't carry the same number. Entity A booked SGD 50,000 of revenue. Entity B booked SGD 49,200 of expense, because the invoice was issued late in the month, the FX rate moved, and B's bookkeeper used a slightly different rate. The naive elimination zeros out one side and leaves SGD 800 hanging in the group P&L — a number that isn't real revenue, isn't real expense, and didn't exist before consolidation.

The accounts don't line up. Entity A coded the cross-charge to "Intercompany Management Fee". Entity B coded it to "Group Services" because their chart of accounts was set up by a different bookkeeper. The elimination logic can't pair them unless someone tells it they're the same thing.

There's no clear marker for what's intercompany. Half the intercompany transactions sit in accounts labelled clearly. The other half sit inside general accounts that contain both third-party and intercompany activity, distinguishable only by the counterparty on the transaction. The "find all intercompany" step requires looking at every transaction, not just every account.

Multiple intercompany types live in the same account. A single "Intercompany" account on one entity might carry a recharge, a loan drawdown, and an expense reimbursement in the same period. Eliminating it as one lump nets things that should be treated differently — the recharge against the P&L, the loan against the balance sheet — and the group numbers end up internally inconsistent.

Each of these is survivable on its own. Together, every month, across a growing group, they're why the Elims tab is the scariest part of the model.

What proper elimination logic actually looks like

The fix isn't a bigger spreadsheet. It's logic that knows what it's looking at. A setup that actually holds up has roughly six moving parts.

Counterparty checks against Xero contacts. Rather than guessing from the account, the logic confirms a transaction is intercompany by checking whether the counterparty is a related group entity — matched against the Xero contact records, consistently named across organisations. This catches the intercompany activity hiding inside general accounts that a pure account-level approach misses.

Account-name pattern matching. Accounts that follow a convention — anything containing "Interco", an [IC] tag, a defined code range — are flagged automatically, so a newly created intercompany account on one entity gets picked up without someone remembering to add it to the model by hand.

Custom pairing rules per group. Because A's "Intercompany Management Fee" and B's "Group Services" are the same economic thing, the logic needs an explicit mapping that says so. Those pairing rules are specific to each group's chart of accounts and conventions — there's no universal template — and they live in one place that gets reviewed when accounts change.

FX-aware netting. When the two sides sit in different currencies or were booked at different rates, the elimination translates both to the group currency on a defined basis before netting, rather than subtracting two numbers that were never going to match. The residual that remains is a real FX effect, not phantom revenue.

Residual handling. When two sides still don't fully reconcile — timing differences, rounding, a rate gap on a revalued loan — the logic routes the residual somewhere defined and visible, instead of leaving it to float in the group P&L where it silently distorts margin. A small, explained residual is fine. An unexplained one hiding in revenue is not.

An audit trail back to source transactions. Every elimination should trace back to the underlying transactions it removed — which invoices, which accounts, which entities. That's what lets you answer the auditor's "show me how this number was derived" without rebuilding the working from scratch.

The common thread: none of this is generic. The rules that make eliminations correct are the rules that match a particular group's structure, conventions, and history.

Where this lives in the tooling

In practice, groups handle eliminations in one of three places. In Excel, as the Elims tab described above — flexible, fragile, and re-trusted from scratch every cycle. In a third-party consolidation tool — which automates the standard cases well, and where most of the real difficulty is exactly the cases the tool wasn't built for. Or in a custom reporting layer that sits above Xero and runs the group's own rules every cycle.

Which one is right depends less on group size than on how standard the intercompany is. A standard ten-entity group whose intercompany activity looks like the textbook examples will be well-served by a tool like Joiin or Translucent. The groups that struggle are the ones whose intercompany doesn't look standard: regional shared services that bill on bespoke allocations, holding structures with complex loan flows, franchise networks with two-sided royalty arrangements, or any group where the intercompany mapping has been built up over years and doesn't fit a vendor template.

For separate Xero organisations — which is most real groups — there's a further constraint worth naming: Xero has no native consolidation or elimination feature at all, so the elimination layer has to sit above Xero regardless of which option you pick. If you want the hands-on month-end version of running that layer yourself, there's a separate step-by-step walkthrough.

Where Cheetah fits

Cheetah builds consolidation logic directly into custom reports on top of Xero — including intercompany eliminations that work with whatever conventions the group already uses. Counterparty checks against Xero contacts, account-name pattern matching, custom pairing rules per group, FX-aware netting, residual handling, and an audit trail back to source transactions.

It's worth a look if your current eliminations process is one of: a manual journal someone copy-pastes each month, a third-party tool that handles the easy intercompany and leaves the messy bits in Excel, or a quarterly cleanup where someone has to reconcile what should have been eliminated automatically.

We've helped firms like Book&Entries and CAP Advisory build elimination logic that runs every reporting cycle without anyone touching it — and produces a group P&L that survives the auditor's first question.

Intercompany isn't a calculation problem. It's a logic problem dressed up as a calculation problem. The reason it stays painful is that every group's intercompany looks slightly different, and standard tools have to pretend it doesn't. Once the logic actually matches the group, eliminations stop being the part of close that everyone dreads.