The balance nobody can explain
Ask a group accountant about intercompany and you will usually get a slightly tired answer. There is a balance. It has been there a while. It used to be bigger. Nobody is worried about it exactly, but nobody can explain it either, and each period it is carried forward with a small adjustment that makes the accounts work.
This is so common that it is worth treating as a structural property rather than a failing. Intercompany reconciliation is the only reconciliation where both sides are produced inside the organisation, which sounds like it should make agreement easier and in fact makes it harder. When you reconcile to a bank, there is a right answer and it belongs to someone else. When two subsidiaries disagree, both sides are internally consistent, both are defended by someone reasonable, and there is no external record to appeal to — unless you go back to what the bank actually did.
What follows is the six structural causes, in rough order of how often they account for a difference, and then the conventions that remove most of them permanently.
One event, two records
Start with the mechanism, because everything else follows from it. A single economic event — money moving from Company A to Company B — produces two independent records. A's ledger records a payment out. B's ledger records a receipt in. Neither team sees the other's entry at the time of making its own.
Every one of the assumptions embedded in those two entries is a place where they can diverge. When did it happen. How much was it. What was it for. Which account does it belong in. What is it called. Two people answering those five questions separately, from two sides of a transaction, will agree completely more rarely than you would expect.
This is also why the fix is never simply "be more careful". Care improves accuracy within each entry; it does nothing about the fact that there are two entries. The durable solutions all work by removing the independence — a shared reference, an agreed convention, or a third-party record both sides defer to.
1 · Timing — the biggest single cause
A transfer initiated on the last working day of the month leaves one company that day and arrives at the other the next. Both records are correct. At the period end, one company shows the money gone and the other has not yet shown it arrived, so the group is briefly missing cash that is sitting in the banking system.
This accounts for the majority of month-end intercompany differences, and it needs explaining rather than fixing. The item is genuinely in transit. The correct treatment is to identify it, quantify it, and expect it to reverse — which is straightforward when the transfer is recognisable and painful when it is one of forty movements nobody has itemised.
Timing differences become a real problem only in one situation: when they are never actually checked to have reversed. An in-transit item assumed to reverse next month, in a group where nobody looks, is indistinguishable from a genuine error that has been quietly accepted. The discipline that matters is not identifying it — it is confirming it cleared.
2 · Fees deducted in transit
One company sends 50,000. The other receives 49,982. Nobody has made a mistake: a payment charge, a correspondent bank fee or an FX spread was taken between the two accounts. The eighteen units are a real cost that has to land somewhere, and which company bears it is a decision that is frequently never made.
These are among the easiest differences to identify — small, odd amounts on otherwise round transfers — and among the most tedious, because they are individually immaterial and collectively persistent. A group making twenty intercompany transfers a month accumulates twenty small unexplained residuals, and after a year that is a balance with no story.
The efficient answer is a standing convention rather than a monthly decision: the receiving entity bears transfer costs, or the sending entity does, decided once and written down. Either is defensible. Not having decided is what costs time, because it turns a trivial posting into a small negotiation every single month.
3 · Netting — one payment, many balances
Netting is what sensible treasury functions do: instead of six payments between four companies, settle the net position with two. It reduces fees and transfers, and it makes reconciliation considerably harder, because the one-to-one relationship between a payment and an underlying item is gone.
A single bank movement now has to be split back across several balances before either side reconciles. If the split is documented, this is mechanical. If it is not — and it often is not, because the person who calculated the net figure knew what it comprised — then a later reviewer sees one payment and several balances that partially moved, with no way to connect them.
The rule that saves the most time here is simple: never settle a net amount without recording its components alongside it. A netting schedule takes minutes to produce at the moment of payment and hours to reconstruct three months later, and reconstruction is exactly what gets asked for during an audit.
4 · Currency — agreeing in substance, differing in figures
When two group companies report in different currencies, their intercompany balances will differ even when they agree perfectly about what happened. Each translates at its own rate on its own date, and the difference is exchange movement rather than error.
The mistake that costs the most time is reconciling the translated figures. Doing so means chasing differences that are not differences at all — and worse, it can make a genuine error invisible, because it is smaller than the translation noise around it.
Reconcile in the transaction currency first. Establish that both sides agree on what moved, in the currency it moved in. Only then translate, and treat any remaining difference as an exchange item with a name rather than as an unexplained balance. Groups that adopt this ordering usually find that their long-standing intercompany mystery was mostly FX all along.
5 · Cut-off — when the periods are not the same period
Cut-off differences are timing differences with an organisational cause. One entity closes on the last calendar day, another on the last Friday. A subsidiary in a different jurisdiction has a different year end. An acquisition kept its old reporting calendar because changing it was never a priority.
The result is that transactions in the overlap belong to different periods in the two sets of books, and no amount of matching will reconcile them, because they are correctly recorded in periods that do not correspond. This is one of the few intercompany problems that cannot be solved by better process at the accountant's desk — it has to be solved by agreeing the calendar.
Where the calendar genuinely cannot be aligned, the workable compromise is a documented bridge: a standing schedule of the overlap period's intercompany movements, prepared once and applied consistently. What does not work is treating it as a fresh puzzle every quarter.
6 · Description drift
The subtlest cause and the most avoidable. One side books a movement as "management charge Q3", the other as "HO recharge", and a third as a bank reference containing an invoice number that appears in neither ledger. All three describe the same event; none of them match.
Amount matching still finds these, which is why description drift is often dismissed as harmless. It stops being harmless when several movements share an amount — regular monthly recharges of the same value are common — and matching by amount alone produces plausible pairs that are actually mismatched. That failure is far worse than no match, because it looks resolved.
A shared reference format removes this entirely and costs one conversation. Entity code, period, sequence — anything stable, agreed once, applied by both sides and put in the bank payment reference so the third-party record carries it too.
Reading a difference
Most differences announce their own cause if you know what to look at. The shape of the number is usually enough to classify it before any investigation starts.
| What you see | Most likely cause | First thing to check |
|---|---|---|
| A whole round transaction | Timing — in transit at period end | Whether it cleared in the first days of the next period |
| A small odd residual | Fee deducted in transit | The bank charge on the sending side |
| Several balances part-moved | Netting without a schedule | The components of the net settlement |
| Difference roughly proportional | Currency translation | Whether both sides agree in transaction currency |
| Persistent, unchanged for months | Cut-off or an old unresolved item | Which period each side recorded it in |
| Matched pair, wrong items | Amount matching without references | Whether two movements share the amount |
| Difference growing each period | A systematic posting error | The recurring entry, not the individual movements |
The last row is the one that deserves attention. A difference that grows steadily is almost never timing and almost always a repeating entry that one side makes and the other does not — a monthly accrual, an interest charge, an automatic recharge. Those are worth finding early, because the cost of leaving them is linear in months.
A worked difference
A group finds that its parent shows 84,600 receivable from a subsidiary, while the subsidiary shows 61,800 payable to the parent. A difference of 22,800 that has been carried for two quarters with a note saying "to investigate".
| Component | Amount | Cause | Action |
|---|---|---|---|
| Transfer sent 31st, received 2nd | 18,000 | Timing | Confirm it cleared; expect reversal |
| Two monthly recharges | 4,800 | Parent posts, subsidiary never did | Real error — post on the subsidiary |
| International payment charges | 62 | Fee in transit | Agree who bears it; post |
| Rounding on FX translation | −62 | Currency | Exchange difference, name it |
| Unexplained remainder | 0 | — | None |
Only one line in that table is an actual error, and it is not the largest. The 18,000 needed confirming, not correcting; the fees and FX needed naming, not chasing. The 4,800 was the real problem — two recharges the subsidiary never posted — and it was the item most likely to be overlooked, because at a fifth of the total difference it looked like noise next to the transfer.
That is the general pattern. The big number is usually explainable and the small one is usually the mistake, which is exactly backwards from where attention naturally goes.
Intercompany loans deserve their own treatment
Trading balances turn over; loan balances persist, which means an error in a loan account can survive for years without anything forcing it to the surface. They also attract entries that trading balances do not — interest, capitalisation, waivers, currency revaluation — each of which one side may post and the other may not.
Reconcile them by movement rather than by balance. Agree the opening position once, properly, and then reconcile every drawdown, repayment and interest charge as an individual movement. A loan checked only at balance level can hide two offsetting errors indefinitely, and offsetting errors in a long-lived account are how a group ends up with a number nobody alive can explain.
Interest is the recurring culprit. It is calculated by one side, often accrued monthly, frequently not mirrored at all, and it compounds — so a difference that starts at a few hundred grows quietly for years. If a group has exactly one intercompany control worth introducing, it is a standing check that both sides post the same interest in the same period.
The conventions that actually fix it
Five agreements, each made once, remove most of what this article describes. None of them require software and all of them require somebody to decide.
| Convention | Removes | Cost to adopt |
|---|---|---|
| Shared reference format | Description drift; false amount matches | One conversation, then habit |
| Standing rule on transfer fees | Small unexplained residuals | One decision, written down |
| Netting schedule with every settlement | Unallocatable net payments | Minutes at payment time |
| Reconcile in transaction currency | Chasing FX that is not a difference | Ordering, not extra work |
| One owner who sees both sides | Differences that persist by default | An assignment, not a hire |
A shared reference format. Entity code, period, sequence — in both ledgers and in the bank payment reference. This is the highest-return convention available and it eliminates description drift completely.
A standing rule for who bears transfer costs. Either answer works. Not having one turns a trivial posting into a monthly negotiation.
A netting schedule with every net settlement. Components recorded at the moment of payment, never reconstructed afterwards.
Reconcile in transaction currency, translate after. Ordering, not effort. It separates genuine differences from exchange movement.
One person who can see both sides. Differences owned by two people who each see half of them persist. Differences owned by one person who sees both get resolved.
Recharges and allocations are a different problem
Worth separating, because they get lumped together and should not be. An intercompany transfer moves money that already belongs to the group; eliminating it on consolidation is correct. A cost paid centrally on behalf of several companies is a real external cost sitting in one entity and belonging partly to others; it must not be eliminated, it must be allocated.
Confusing the two produces two opposite errors. Eliminating an allocation removes a genuine group cost. Treating a transfer as an allocation inflates costs across the group. Both are easy to make, because in bank data a central insurance payment and an intercompany transfer look similar: money leaving one company that ultimately concerns several.
The distinguishing question is simple and worth asking explicitly every time: did the money leave the group? If it went to a third party, it is a cost to allocate. If it went to another group company, it is a transfer to eliminate. Everything else follows from that one answer.
Why an old difference is so much harder than a new one
The cost of resolving an intercompany difference does not rise gently with age. It rises in steps, and each step is a piece of context disappearing.
In the first month, the difference is usually solved by asking someone. They remember the transfer, they know it was for the equipment purchase, and the whole thing takes a phone call. Nothing about the data has changed — the advantage is entirely that a person still holds the explanation.
By six months, that memory is gone and the work becomes documentary: find the bank movement, find the invoice behind it, establish what both sides recorded. Still perfectly possible, now an hour or two instead of a call, and it requires having kept documents in a way that supports searching by amount and date.
Past a year, two further things have typically happened. The difference has been carried forward across a period end, which gives it a quiet legitimacy — it appeared in signed accounts, so questioning it now raises a question about those accounts too. And it has often merged with other differences, so what is visible is a net figure comprising several unrelated items, none individually identifiable.
That last stage is where groups give up and start describing the balance as historical. It is also why the only reliable strategy is monthly resolution regardless of reporting frequency. Not because monthly differences are more important, but because they are the only ones that can still be solved by asking somebody a question.
If you have inherited an aged balance, resist working forward from the oldest entry. Work backwards from the current difference, stripping out the components you can identify — recent timing items, known fees, a translation effect — until what remains is small enough to attack directly. The residual usually turns out to be one or two specific transactions rather than the accumulated mystery it appears to be.
There is one shortcut worth knowing for a balance that has resisted everything else. Instead of reconciling the balance, reconcile the movement: take the difference at the start of a period and the difference at the end, and look only at what changed between them. A balance that has been wrong for years but has not moved is a single historic item, and the period in which it appeared can be found by bisection in a handful of steps. A difference that changes every period is a live process problem and needs fixing at the source, not in the balance.
That distinction matters because the two demand opposite responses. A static historic item can reasonably be investigated once, documented and — if genuinely immaterial and understood — written off with a note explaining what it was. A moving difference cannot be written off at all, because next period it will be back, slightly larger, and the write-off will have removed the only evidence of where it came from.
What an auditor will actually ask
Intercompany is a standard area of focus, because it is where a group's internal consistency is most testable. The questions are predictable: show the intercompany matrix; explain each difference; show that eliminations agree in both directions; demonstrate that the residual is understood rather than merely small.
That last point matters more than groups expect. A small unexplained residual is not reassuring to a reviewer — it is evidence that the process does not resolve differences, only tolerates them. A larger difference with a complete explanation is treated far better than a small one with none.
The practical implication is to document as you resolve, not afterwards. A difference explained in the month it arose costs a sentence; the same difference explained nine months later costs an investigation, and by then the person who knew has usually moved on.
Making the pairs findable in the first place
Everything above assumes you can see both sides. In many groups that assumption fails at the first step, because each entity's data lives in its own file and the second half of every pair is somewhere else.
Getting every company's transactions into one dataset, with the entity recorded on each row, converts pair-finding from a manual search into a sort. Equal amounts, opposite signs, different entities, close dates — that is a mechanical test, and it is the only part of intercompany work that should be automated. Our multi-entity reconciliation page covers how the tagging works, and entity tagging the mechanics of the columns themselves.
What should not be automated is the decision that follows. A tool can put a candidate pair in front of you; only you know whether it is a transfer to eliminate or a genuine charge to keep. Groups that let software decide that end up with clean-looking eliminations and consolidated figures nobody can defend.
Put both sides in one table
Convert statements from two entities free — no registration — and see the pairs line up.