How to Handle Intercompany Eliminations in Xero: The Complete Guide

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.

That tab exists because Xero doesn't have a button for this. Xero will happily give you each entity's P&L and balance sheet. It will not net out the sale that one of your companies made to another, or the loan sitting as a receivable on one ledger and a payable on the other. That's on you.

So "how to handle intercompany eliminations in Xero" isn't really a question about a Xero feature — because there isn't one. It's a question about a process you run every cycle with the tools you've got, and about logic that has to be right for your particular group. Intercompany eliminations look like a calculation and behave like a logic problem.

This guide covers both halves: why the netting is harder than it looks, then the actual month-end process, step by step, plus what it takes to stop doing it by hand.

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 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 Xero does and doesn't do here

Quick reality check before the process, so the steps make sense. If your entities all sit inside a single Xero organisation separated by tracking category, you have some options at the report layer. But most real groups run separate Xero organisations — different legal entities, often different countries — and for those, Xero has no native consolidation or elimination feature at all. No cross-org aggregation, no automatic netting, nothing. The elimination layer has to sit above Xero regardless of which tool you eventually pick.

That means handling eliminations comes down to four jobs you do outside Xero: get the data out, identify what's intercompany, match the two sides, and remove it from the group view. Everything below is just doing those four jobs well enough that next month is easier than this month.

Step 1: Set up so eliminations are findable in the first place

This is the step everyone skips and then pays for. You cannot eliminate what you can't reliably identify. Most of the month-end pain isn't the netting — it's hunting through ledgers trying to work out which transactions were internal.

Fix that at the source, once:

Use dedicated intercompany accounts. On each entity's chart of accounts, create separate accounts for intercompany activity rather than letting it blend into the normal ones. A current asset called Intercompany Receivable — [Other Entity], a current liability called Intercompany Payable — [Other Entity], and equivalent P&L accounts for intercompany sales and recharges. The moment internal balances live in their own accounts, identifying them stops being detective work.

Adopt a naming convention you never break. Whatever marker you choose — an Interco prefix, an [IC] tag, a consistent account-code range — apply it everywhere, in every entity. Consistency is what makes the elimination repeatable. A convention that's followed 90% of the time is a convention that breaks your group P&L 10% of the time.

Tag the counterparties in Xero contacts. When one entity invoices another, the customer/supplier record should clearly be the related entity, named consistently across all orgs. This is what lets you (or a tool) confirm a transaction is genuinely intercompany rather than guessing from the account alone.

Carry a consistent reference. Put the same reference on both sides of an intercompany transaction where you can. It's the cheapest way to match a receivable to its payable later without a forensic exercise.

None of this is glamorous. All of it turns the next eleven month-ends from a hunt into a checklist.

Step 2: Pull the data out the right way

When you export, take the underlying numbers, not the pretty report. Export each entity's trial balance (or the account-level P&L and balance sheet data), not the formatted PDF P&L with its subtotal rows and merged cells. Formatted reports are built for reading, not for being a data source — they break the moment you try to do arithmetic across them.

Get every entity onto the same footing: same period, same close status, same currency convention. If two entities aren't closed to the same point, your eliminations will chase a moving target.

Step 3: Identify what actually needs eliminating

If you did Step 1, this is now a filter rather than a search. You're looking for the five categories from earlier — sales and recharges, the receivables and payables behind them, loans and their interest, dividends, and investments in subsidiaries.

You don't need to hold the theory of each in your head to run the process. For month-end, the point is simply this: every internal flow has two sides sitting on two different ledgers, and your job is to find both. A single-sided elimination isn't a shortcut, it's an error.

Step 4: Match the two sides — and expect them not to agree

This is the actual hard part, and the one people underestimate. In theory, the intercompany receivable at Entity A equals the intercompany payable at Entity B. In practice it frequently doesn't, and the gap is where close time disappears.

These are the same forces from Why "just net them off" doesn't work, seen from the other end — not a modelling problem now, but a reconciliation queue:

• Timing. Entity A books the sale in March; Entity B books the purchase in April. For one period the two sides don't line up, even though everything is correct.
• FX. Different currencies, different rates, same economic event — the translated figures simply don't agree.
• Coding. Someone posted one side to the wrong account, or to a generic account instead of the intercompany one. Now it's hiding.

Match them anyway — by counterparty, amount, and reference — and investigate every gap before you eliminate. A clean elimination on top of an unreconciled mismatch just buries the error inside a group number that looks tidy. Reconcile first, eliminate second. Always that order.

Step 5: Post the elimination

Once both sides are identified and reconciled, remove them from the group view. Critically, you do this at consolidation — not by editing either entity's Xero books. Each entity's standalone accounts are correct and need to stay that way for local tax and audit; the elimination only lives in the group layer.

Mechanically, in a spreadsheet model that usually means an eliminations column or tab that sits between the entity columns and the group total:

• For an intercompany sale: a negative to group revenue and a negative to the matching group cost, equal in size. Net effect on group profit: nil, but both inflated lines come back to reality.
• For an intercompany balance: a negative to the group receivable and a negative to the group payable.
• For a loan: eliminate the receivable against the payable on the balance sheet, and the interest income against the interest expense on the P&L.

Keep each elimination as an explicit, labelled line — not a plug. "Eliminate IC sales A→B, March, ref INV-1042" is auditable. A single mystery adjustment that makes the totals tie is not, and it's the thing that falls over the moment someone asks a real question.

Step 6: Prove it with the reconciliation check

Don't trust the model just because it balances. Run the check that proves the elimination did what it should:

• Group revenue and group costs each dropped by exactly the intercompany amount.
• Net intercompany receivables across the group equal net intercompany payables — ideally both zero after elimination.
• Group profit is unchanged by any elimination that should be profit-neutral (sales, recharges, loans). If eliminating an intercompany sale moved group profit, something is mismatched and you've found a real error, not finished the job.

That last test is the single most useful one. A correct intercompany elimination almost never changes group profit. When it does, stop and find out why.

Where this quietly falls apart

The manual process works. It also degrades in predictable ways:

• Someone adds an account in one entity and forgets the group mapping, so transactions silently fall outside the elimination logic.
• A new intercompany relationship appears — a new entity, a new recharge type — and the model doesn't know about it.
• An FX rate goes stale, and the two sides of an FX-affected elimination stop netting cleanly.
• The person who built the model leaves, taking the undocumented logic with them.

Every one of these produces a group P&L that looks fine and is wrong. The fragility isn't the arithmetic — it's that the arithmetic depends on a human remembering a dozen conventions every single month.

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. If your group's intercompany is small and stable, the manual process above is entirely manageable — run it, document it, move on. A standard ten-entity group whose intercompany 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 billing on bespoke allocations, holding structures with layered loan flows, franchise networks with two-sided royalty arrangements, or any group whose mapping has grown over years into something no vendor template anticipates. That's usually the point where the monthly ritual stops being worth the risk.

Where Cheetah fits

Cheetah is consolidation software for Xero that builds this logic directly into custom reports on top of your Xero organisations — 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 every source transaction. It runs the whole group close — aggregation, eliminations, and FX translation — every cycle, without anyone reconstructing the spreadsheet.

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.