Guide 03 · Multi-entity
Intercompany that actually nets to zero
Intercompany is the account nobody wants to open, and it gets worse every month it stays closed. The method is not complicated — it is a symmetrical matrix and a rule about who is allowed to post. Keeping it clean is a discipline problem, not an accounting problem.
Intercompany that nets to zero
Every intercompany balance appears twice — equal and opposite. The matrix proves the group nets to zero.
| Owed by ↓ / to → | Entity A | Entity B | Entity C | Payable |
|---|---|---|---|---|
| Entity A | — | 12,000 | 3,500 | 15,500 |
| Entity B | 12,000 | — | 8,000 | 20,000 |
| Entity C | 3,500 | 8,000 | — | 11,500 |
| Receivable | 15,500 | 20,000 | 11,500 | 0 |
Each entity's receivable equals its payable, so every row and column cancels — the group total is 0. If it isn't, a posting is missing its pair.
The one rule
Every intercompany transaction has exactly two postings, created at the same time, by the same person, for the same amount. If one side can exist without the other, your intercompany balance will drift, and the drift compounds because nobody can tell which month it started.
Due from B on A's books = Due to A on B's books
Across the whole group:
Σ all intercompany receivables − Σ all intercompany payables = 0
Not "close to zero." Zero.
If the group total is not zero, at least one transaction was recorded on one side only, or at a different amount on each side. Both are findable in minutes from a matrix and essentially unfindable by reading two general ledgers.
The matrix
Build it every month, entity by entity. Rows are the entity that is owed; columns are the entity that owes. Each cell is read from that entity's own ledger — not derived from the other side, because deriving it is what hides the break.
| Owed to ↓ / Owed by → | Entity A | Entity B | Entity C | Total due to |
|---|---|---|---|---|
| Entity A | — | 41,200.00 | 8,750.00 | 49,950.00 |
| Entity B | 12,000.00 | — | 0.00 | 12,000.00 |
| Entity C | 0.00 | 3,415.00 | — | 3,415.00 |
| Total due by | 12,000.00 | 44,615.00 | 8,750.00 | 65,365.00 |
| Due to less due by | 0.00 |
Two checks, both mechanical. Pairwise: A's "due from B" must equal B's "due to A", cell by cell. Group: the two totals must agree. The pairwise check tells you which relationship broke; the group check tells you whether anything broke at all. Run the group check first — most months it is zero and you are done in a minute.
This is the single highest-value thing to template in a multi-entity group. A matrix that refreshes from the trial balances turns a half-day investigation into a one-minute check, and it catches the break in the month it happened rather than three months later.
Where one-sided postings come from
One entity pays another's bill
The paying entity records cash out and an intercompany receivable. The benefiting entity records nothing, because nobody told them. This is the most common single cause, and it is a communication failure, not a bookkeeping one.
Shared payroll run from one account
A single payroll covering staff at several entities, funded from one bank account. The split has to be pushed out as intercompany on the same date as the run, every run — a monthly catch-up entry will not reconcile to a weekly cash movement.
A management fee booked gross one side, net the other
One entity records the fee, the other records the fee less something it netted off. Pairwise cells disagree by the netted amount, and the difference looks like a mystery until you read both invoices.
Reclassifications after the fact
Somebody corrects a coding error in one entity without the mirror entry. Correcting an intercompany posting is two entries, same as creating one.
Intercompany entries are created from a single template that posts both sides, and only a named handful of people may post to intercompany accounts at all. If anyone in the group can touch those accounts, somebody eventually will, and you will find out a quarter later.
Cleaning up a balance that is already broken
If the group total has not been zero for a while, do not try to explain the whole balance. Work backwards to the last month it was clean, then forward.
Find the last clean month
Build the matrix for each prior month-end until the group total is zero. Binary search works here — try six months back, then split. You usually find it in three or four attempts rather than twelve.
Isolate the months that broke
From that clean point, build the matrix forward one month at a time and note the change in the imbalance each month. Now you have specific months and specific amounts instead of one aggregate mystery.
Match the amount to a transaction
Search both entities' intercompany detail for the imbalance amount in the month it appeared. A one-sided posting matches the imbalance exactly; an amount mismatch matches the difference. Most breaks resolve to a single identifiable transaction.
Correct in the current period, document the history
Unless a prior period is genuinely material and still open, post the correction now with a memo that names the original transaction and month. Reopening closed periods to fix intercompany creates more problems than it solves, and it changes statements people have already relied on.
Decide what to do with a genuine residual
If part of the balance cannot be traced after a real effort, say so in writing, get it approved by an owner, and write it off deliberately. A documented write-off with a rationale is a defensible position. An unexplained balance carried forward forever is not, and it will be the first thing a buyer's diligence team asks about.
Allocations are not intercompany
These get conflated constantly, and the distinction matters. Intercompany is a real obligation between two legal entities: one owes the other money. Allocation is a management-accounting distribution of a shared cost across locations or departments for reporting purposes.
An allocation across cost centres within one entity creates no receivable and no payable, and should never touch an intercompany account. An allocation between entities is an intercompany transaction and needs both sides. Mixing them produces an intercompany balance that cannot be settled in cash, which means it cannot be reconciled either — there is nothing to reconcile it to.
An intercompany balance that grows every month and is never settled by a payment. That is usually allocations hiding in an intercompany account, and it will not clear until you separate them.
Elimination at consolidation
Eliminations belong in a separate elimination entity or ledger, never pushed back into the operating entities. The operating books stay standalone-true — which is what you need for an entity-level tax return, a lender covenant, or a sale of one location — and the consolidated view is built on top.
- Intercompany receivables against intercompany payables
- Intercompany revenue against intercompany expense (management fees, shared services, rent between related entities)
- Unrealised margin on anything transferred between entities and still on hand
- Investment in subsidiary against subsidiary equity, where that structure exists
Then prove it: consolidated intercompany balances are zero, consolidated revenue excludes internal billing, and the sum of standalone equity plus eliminations equals consolidated equity. If any of the three fails, the consolidation does not tie, whatever the software says.
Why this one earns its keep. Of everything on a multi-entity close, intercompany is where I most often find real problems — and it is also the most fixable. Three months of discipline and a templated matrix usually turns a chronic open item into a one-minute check.