Why Every Entity Needs Dedicated Intercompany Account Codes: The Group COA Design That Makes Eliminations Automatic

Tom is group financial controller at Nexum Group, a five-entity professional services group. Every month, after all five entities have closed their books, Tom’s team begins the consolidation process. The first step — before a single elimination journal can be posted — is a two-to-three day exercise in which the team goes through each entity’s trial balance, identifies every intercompany amount, and manually extracts it from the accounts where it is buried alongside external transactions.

Management fees: Nexum Holdings charges £15,000 per month to each of the four operating entities, coding the income to its “Revenue — Professional Services” account alongside genuine external client income. Each subsidiary codes the management fee expense to “Admin & Overheads” alongside rent, utilities, and office costs. To find the elimination amounts, Tom’s team must either rely on a separate intercompany schedule maintained outside the accounts, or manually trace the amounts from bank statements and approve lists. Either way, it takes time and introduces error risk.

Intercompany goods sales, IC loan interest, and recharges for shared services all have the same problem. The elimination amounts exist — they are real transactions, correctly recorded in each entity’s books — but they are invisible to the consolidation system because they share account codes with external transactions. The consolidation system cannot tell the difference between a £15,000 management fee from Nexum Holdings and a £15,000 fee from an external client. Both sit in the same account, coded the same way.

The solution is a specific group chart of accounts design decision: dedicated intercompany account codes in every entity, separate from the accounts used for external transactions. When IC transactions have their own account codes, the consolidation system can identify them automatically, and the monthly extraction exercise disappears.

Why the Problem Is Invisible Until Consolidation

Each of Nexum’s entities has internally correct accounts. Nexum Holdings records its management fee income accurately. Each subsidiary records its management fee expense accurately. The transactions are real, documented, and auditable. From each entity’s perspective, the accounting is fine.

The problem only materialises at the consolidation step — when the system needs to look across all five entities simultaneously and identify which revenues, costs, and balance sheet items are internal to the group (and must be eliminated) and which represent transactions with external third parties (and must be retained). Without dedicated IC account codes, the consolidation system has no automatic signal to distinguish internal from external. It sees “Revenue — Professional Services: £1,840,000 in Nexum Holdings” and cannot know that £720,000 of that is management fees from subsidiaries that will be eliminated and £1,120,000 is real external client income that will be retained.

A single-entity business never encounters this problem. It has no intercompany transactions and therefore no need for IC-specific accounts. The dedicated IC account requirement is a group-only design consideration — it only matters because there are multiple entities whose transactions must be disaggregated and selectively eliminated at consolidation.

What Happens Without Dedicated IC Accounts: Three Failure Modes

1. Missed Eliminations Inflate Consolidated Revenue

Nexum Holdings earns £720,000 per year in management fees from its four subsidiaries (£15,000 per month × 4 entities × 12 months). This is coded to “Revenue — Professional Services.” In the consolidated P&L, before elimination, the group’s external revenue appears to be £1,840,000. But £720,000 of that is internal — Nexum Holdings receiving fees from entities that are part of the same consolidated group. The consolidated revenue should be £1,120,000 (external only).

If Tom’s team misses the management fee elimination — a realistic risk when the identification process is manual and the amounts are buried — the consolidated P&L overstates revenue by £720,000. For Nexum Group, that is a 64% overstatement of what is genuinely external income. The board sees a £1.84m revenue group when the real external revenue figure is £1.12m.

Consolidated revenue	£
As reported (before elimination) — IC fees buried in external revenue	1,840,000
Less: intercompany management fee income — Nexum Holdings (eliminate)	(720,000)
Correctly consolidated external revenue	1,120,000

2. Manual Identification Creates Monthly Error Risk

To avoid this overstatement, Tom’s team must find and extract the £720,000 each month. The process typically involves: checking the IC recharge schedule, confirming the amounts were invoiced and received as expected, locating the specific transactions in each entity’s Xero account, and verifying that the amounts in the trial balance match the schedule. When the amounts are consistent month to month, this is tedious but manageable. When they vary — because the management fee was renegotiated, or a subsidiary was acquired mid-year, or an extra ad hoc recharge was made — the extraction process requires careful judgement about which amounts to include.

The risk is not theoretical. Consolidation errors in groups with manual IC identification processes typically fall into three patterns: amounts extracted at last month’s figure rather than this month’s actual; IC amounts that are not on the standard schedule (ad hoc recharges) that are not identified; and IC amounts that were extracted but the corresponding entry in the counterpart entity was not, resulting in a half-elimination that leaves a net balance in the consolidated P&L. Each of these is less likely when the IC amounts have their own account codes and can be extracted automatically by the system.

3. IC Balance Sheet Balances Don’t Reconcile

The same problem applies to the balance sheet. Intercompany receivables and payables must be eliminated — Nexum Holdings’ “Trade debtors” includes amounts owed by its subsidiaries for management fees not yet settled; each subsidiary’s “Trade creditors” includes the corresponding payable. Without dedicated IC balance sheet accounts, the system cannot automatically identify which debtors and creditors are internal.

When IC balance sheet balances are not eliminated — or are eliminated only partially — the consolidated balance sheet carries phantom debtors and creditors that inflate both assets and liabilities. This distorts working capital metrics, inflates the apparent size of the balance sheet, and, for groups with financial covenants based on net assets, can produce misleading covenant calculations.

The asymmetry risk. The most common balance sheet IC elimination error is asymmetric elimination: the IC receivable in one entity is eliminated but the IC payable in the other is not (or vice versa), because the amounts differ due to invoicing timing, foreign exchange movements, or a disputed charge. Without dedicated IC accounts that flag both sides for elimination, the consolidation preparer may not notice the asymmetry until the balance sheet fails to balance — at which point the investigation is significantly harder than it would have been with a dedicated account structure.

The Dedicated IC Account Structure: How It Works

The fix is straightforward to design, though it requires a coordinated change across every entity’s chart of accounts. Each entity needs a set of dedicated intercompany accounts — separate from their external revenue, cost, and balance sheet accounts — that are used exclusively for transactions with other group entities.

The accounts come in matched pairs: for every IC income account in the sending entity, there is a corresponding IC expense account in the receiving entity. The consolidation system maps each pair and eliminates them automatically.

With this structure, Nexum Holdings codes all management fee income to IC-4100, never to its external revenue account. Each subsidiary codes its management fee expense to IC-7100, never to “Admin & Overheads.” At consolidation, the system identifies IC-4100 and IC-7100 as a matched elimination pair and removes both automatically. Tom’s team does not need to search for the amounts — they are in a dedicated account that exists for no other purpose.

Matched Account Pairs in Practice

Management Fee Pair

Intercompany Goods Sale Pair

Intercompany Loan Interest Pair

The elimination pair approach means the consolidation system only needs to know one thing: any transaction coded to an IC-series account is intercompany and must be eliminated. It does not need to analyse transaction descriptions, trace bank references, or compare schedules. The account code is the signal. This is why dedicated IC accounts reduce consolidation time so significantly — the identification step, which is the expensive part, becomes instantaneous.

Before and After: The Consolidated P&L Comparison

Nexum Group — consolidated P&L (annual)	Without IC accounts (£)	With IC accounts (£)
Revenue
External revenue	1,840,000 (includes IC fees)	1,120,000
IC Revenue — Management Fees (eliminated)	—	(720,000) elim.
Net revenue	1,840,000	1,120,000
Operating Expenses
Admin & Overheads	980,000 (includes IC fees)	260,000
IC Expense — Management Fees (eliminated)	—	(720,000) elim.
IC Interest Income (eliminated)	—	(24,000) elim.
IC Interest Expense (eliminated)	—	(24,000) elim.

When the IC accounts are dedicated and matched, the elimination is symmetric by design: every IC income account has a corresponding IC expense account for the same amount in the counterpart entity. The consolidation system applies the elimination and the net effect on consolidated P&L is zero — as it should be, since the management fee is simply a transfer within the group with no external economic substance. The remaining revenue and expenses reflect only external transactions.

Handling the Timing Difference: When IC Invoices Aren’t Settled in the Same Period

One complication arises when the IC invoice is raised in one period and settled in the next — a common situation for management fee invoices, which are often raised at month-end and paid early the following month. This creates a timing difference: at month-end, the sending entity has an IC receivable and the receiving entity has an IC payable. If both entities are using dedicated IC balance sheet accounts (IC-1100 and IC-2100), these amounts are automatically identified for elimination. If they are using general “Trade debtors” and “Trade creditors” accounts, the balance sheet elimination requires the same manual extraction problem as the P&L elimination.

The dedicated balance sheet IC accounts — one account per counterpart entity — also solve the asymmetry problem. When IC-1100 “IC Receivable — Nexum Digital” in Nexum Holdings is matched against IC-2100 “IC Payable — Nexum Holdings” in Nexum Digital, any difference between the two balances at month-end is immediately visible as an IC reconciling item. The consolidation system flags it; Tom’s team investigates it — is the difference a timing item (invoice raised, not yet received)? A disputed charge? A foreign exchange movement? The investigation is targeted and specific rather than a general search through mixed accounts.

The Entity-Specific Balance Sheet Account Design

For groups with more than two entities, the balance sheet IC accounts should be entity-specific: “IC Receivable — Nexum Digital,” “IC Receivable — Nexum Manufacturing,” and so on, rather than a single pooled “IC Receivable” account. Entity-specific accounts make it possible to reconcile each bilateral relationship independently — the balance in “IC Receivable — Nexum Digital” must equal the balance in “IC Payable — Nexum Holdings” in Nexum Digital’s accounts. If they don’t match, the reconciling item is isolated to that specific relationship, not buried in a pool of all intercompany positions.

The practical limit for most groups is when the number of counterpart entities becomes large. A 10-entity group where every entity trades with every other would require 90 bilateral accounts per entity — unwieldy in most accounting systems. For groups at that scale, a single pooled IC account at entity level, supported by an entity-level reconciliation schedule, is a reasonable compromise. For groups of 2–6 entities — the most common size for SME groups — entity-specific IC accounts are practical and strongly recommended.

Implementing Dedicated IC Accounts in Xero (and Other Systems)

Adding dedicated IC accounts in Xero is straightforward: create a new account in the chart of accounts, assign it to the appropriate account type (revenue, expense, current asset, current liability), and assign the IC account code. The key discipline is ensuring that all users in the entity — whether the finance team, bookkeeper, or accounts payable staff — know that IC transactions must be coded to the IC accounts and not to the standard external accounts. This is as much a training and process change as a system change.

For groups where entities are set up in different accounting systems, or where entity bookkeeping is outsourced, the IC account coding discipline requires explicit instruction to the bookkeeper and a regular review of whether IC amounts are appearing in unexpected accounts. A monthly check — “does the entity’s IC account balance match the counterpart entity’s IC account balance?” — catches miscoding before it compounds.

For the broader design principles behind a group COA that supports both entity-level management reporting and group consolidation, see How to Design a Common Chart of Accounts for Multi-Entity Groups: A Step-by-Step Strategy Guide. For how AI-assisted mapping can accelerate the initial mapping of entity account codes to group account codes — including IC accounts — see AI Auto-Map Explained: How BrizoConsol Automatically Maps Entity Accounts to Your Group Chart of Accounts.

Eliminations that run automatically — not manually

BrizoConsol identifies intercompany amounts by account code, matches them across entities, and posts eliminations without manual extraction — so month-end consolidation takes hours, not days. See It in Action