Why Your Intercompany Balances Never Match (Even When Both Companies Agree)
Sarah is the group financial controller of a UK distribution holding company with four trading subsidiaries. It is 9:47 pm on the last working day of month-end close. She has spent the past three hours chasing intercompany confirmations, and she finally has them: Entity A has confirmed it posted the £180,000 management fee as a receivable. Entity B has confirmed it posted the same amount as a payable. She runs the consolidation. The intercompany difference line reads: £2,340.
She emails both entities. Both reply. Both confirm the posting is in there. Both agree the management fee existed. Nobody is confused about the transaction. And yet there is a £2,340 hole in the consolidated balance sheet, and Sarah has no idea where it came from.
This is one of the most demoralising moments in group reporting — not because it is rare, but because it is so common. The problem is almost never that a transaction hasn’t been recorded. It is that the same transaction has been recorded slightly differently: at a different time, at a different rate, for a slightly different amount, or into a different account. Both entities can be entirely correct from their own perspective while the consolidation still shows a difference.
Automate NCI calculations across all your entities.
BrizoConsol handles non-controlling interest automatically — no manual adjustments required.
This post walks through the seven most common causes of intercompany balance mismatches — including the ones that survive even after both entities confirm they’ve posted — and what to do about each one. If you want the broader reconciliation process first, the intercompany reconciliation guide for multi-entity groups covers the full workflow. This post focuses specifically on diagnosing the gap once both sides say they’ve done their part.
1. The Invoice Falls in Different Accounting Periods

Entity A raises and posts an invoice on 30 June. Entity B receives the invoice in the post — or by email that bounces to a junk folder — and posts it on 3 July. Both entities have recorded the transaction correctly within their own period. The problem is that the group’s period-end cut-off is 30 June, so at that date Entity A shows a receivable and Entity B shows nothing. The intercompany difference is the full invoice value.
| Entity | 30 June Balance | Account |
|---|---|---|
| Entity A (seller) | £180,000 Dr | Intercompany Receivable |
| Entity B (buyer) | £0 | Intercompany Payable — not yet posted |
| Consolidated difference | £180,000 |
This is easy to spot — the difference is the full invoice amount, not a fraction of it. The fix depends on your group’s cut-off policy. Most groups require the buyer entity to accrue the liability at period end if the invoice relates to services or goods received in that period, even if the invoice itself hasn’t arrived. The seller entity should hold off recognising the receivable until both sides can agree the timing, or the group should adopt a strict rule: the invoice date governs, not the receipt date.
Entity B — Accrual to match Entity A’s period-end posting
Dr Management Fee Expense £180,000
Cr Intercompany Payable — Entity A £180,000
Accrue liability at 30 June to match Entity A’s receivable. Reverse in July when invoice is received.
Common mistake: Finance teams often tell Entity B to “sort it out in July” without realising this creates a permanent intercompany difference in the June consolidated accounts, which then carries forward and complicates the July reconciliation too.
2. Both Sides Used Different Exchange Rates

This is the mismatch that most often survives an “both sides agree” check — because it isn’t about whether the transaction was posted; it is about the rate used to translate it.
Consider an intercompany loan between a US subsidiary (Entity A) and a UK parent (Entity B). The loan is denominated in USD. Entity A records the principal at the spot rate on the drawdown date. Entity B translates the same principal at a slightly different rate — perhaps the average rate for the month, or the rate their accounting system pulled the following morning when the transaction was posted.
Entity A records: USD 500,000 at 1.2750 = GBP 392,157
Entity B records: USD 500,000 at 1.2961 = GBP 385,775
Difference: GBP 6,382
Both entities agree: there is a USD 500,000 intercompany loan. Neither has made an error in recognising the loan. But the GBP equivalent differs by £6,382 because they used different rates. The consolidation sees two different GBP amounts with no match.
The correct treatment depends on your group’s accounting standard. Under IAS 21 and FRS 102, monetary intercompany balances must be retranslated at the closing rate at each period end, with exchange differences going to the income statement. If both entities retranslate correctly using the same closing rate, the GBP balance will agree at period end — even if they used different rates at inception. The problem arises when one or both entities fail to retranslate at close. For a detailed walkthrough of the translation mechanics, the guide to calculating the cumulative translation adjustment covers the period-end retranslation process.
A simple group policy that prevents this: nominate one entity as the “source of truth” for the exchange rate on each intercompany transaction. The other entity must use that same rate when posting. Document it in the intercompany agreement.
3. Bank Charges Were Absorbed Into the Transfer
This one is small but persistent, and it catches groups who settle intercompany balances by bank transfer rather than journal. Entity A sends £250,000 to Entity B via international wire. Entity A’s bank debits £250,000 from Entity A’s account and records the intercompany receivable at £250,000. But by the time the payment clears through the correspondent banking chain, SWIFT charges of £388 have been deducted. Entity B receives £249,612 and posts their payable at £249,612.
| Entity | Amount Posted | Account |
|---|---|---|
| Entity A (payer) | £250,000 | Intercompany Receivable (or cleared) |
| Entity B (receiver) | £249,612 | Intercompany Payable |
| Difference | £388 | Bank charges absorbed in transit |
Both entities are right. The difference is real cash that left the group via bank charges. The correct treatment is for Entity B to post the bank charge separately — either as a direct expense or recharged back to Entity A — so that the intercompany payable matches Entity A’s receivable. Many groups miss this because the bookkeeper simply posts the amount that hits the bank statement, which is correct from an entity perspective but creates a permanent intercompany difference.
Entity B — Correct posting to clear the intercompany difference
Dr Bank £249,612
Dr Bank Charges Expense £388
Cr Intercompany Payable — Entity A £250,000
Entity B’s bank charge of £388 is expensed separately. The intercompany payable now matches Entity A’s receivable.
4. One Entity Accrued; the Other Waited for the Invoice
This is a subtler version of the timing problem. Entity A knows it owes Entity B a monthly IT services charge of roughly £15,000 per month. At 31 March, Entity A accrues the charge because month-end has arrived before the invoice. Entity B’s accounting system, however, is set up to recognise revenue only when an invoice is raised — and the invoice isn’t raised until 5 April.
At 31 March: Entity A has a payable of £15,000. Entity B has no receivable. Both will tell you, if you ask, that the monthly charge exists and is valid. The mismatch is simply a different trigger for recognition: Entity A is on an accruals basis for this transaction; Entity B is effectively on an invoicing basis.
The fix is a group-wide intercompany services calendar. Each recurring intercompany charge should have an agreed invoice date — ideally before period end — and both entities should post on the same date. Where that isn’t possible, the receiving entity should accrue and the supplying entity should issue a draft invoice or accrual request at period end. This is one of the most common problems that automated intercompany journals solve: when the journal is system-generated on a fixed date, both sides post simultaneously and the mismatch can’t occur.
5. The Balance Is in the Right Amount — But in the Wrong Account
This is the most insidious mismatch because it doesn’t show up as a difference in the total balance — it shows up as a difference in the account being reconciled. Entity A posts the intercompany management charge to “Intercompany Receivables — Entity B.” Entity B posts it to “Sundry Creditors” rather than “Intercompany Payables — Entity A,” because their bookkeeper wasn’t sure of the correct account.
When the consolidation software tries to match Entity A’s intercompany receivable against Entity B’s intercompany payable, it finds nothing. The £180,000 is sitting in sundry creditors, invisible to the intercompany reconciliation. Both entities will confirm the transaction is there. It is there — it’s just not where the system is looking for it.
This problem compounds over time. Each month the misposted balance grows, and the sundry creditors balance at Entity B looks mysteriously high. It only comes to light during an audit or a detailed account analysis, by which point there may be twelve months of accumulated mispostings to untangle.
Prevention requires clear account mapping for intercompany transactions across all entities, enforced at the time of posting rather than discovered at consolidation. A common chart of accounts with dedicated intercompany account codes — separate for each counterparty entity — is the most reliable solution. If your group doesn’t have one, at minimum maintain a posting guide that every entity bookkeeper has read and signed off.
6. In-Transit Payments at Period End
Entity A transfers £320,000 to Entity B on 28 June to settle an intercompany balance. Entity A’s bank account is debited on 28 June, so Entity A removes the intercompany payable from its books. Entity B’s bank account doesn’t show the credit until 1 July — so at 30 June, Entity B still shows a receivable of £320,000 while Entity A shows nothing.
| Entity | 30 June Balance | Position |
|---|---|---|
| Entity A (payer) | £0 | Payable cleared — payment left bank 28 June |
| Entity B (receiver) | £320,000 Dr | Receivable still open — cash arrives 1 July |
| Consolidated difference | £320,000 | In-transit item |
In-transit items are legitimate and expected. The correct group policy is to suspend period-end intercompany transfers — no transfers in the final three working days of the period — or to create an “intercompany in-transit” clearing account that both entities post to when a payment is made but not yet received. This way the group balance is always zero (both sides have an entry) even if the cash is still moving through the banking system.
Entity A — Post to clearing account instead of closing the payable
Dr Intercompany Payable — Entity B £320,000
Cr Intercompany In-Transit — Entity B £320,000
Entity B mirrors this by posting a Dr to Intercompany In-Transit — Entity A. When the cash hits, both clear the in-transit account to bank. The intercompany payable/receivable is eliminated at period end.
7. Cumulative Rounding in Multi-Currency Groups
Each month, when a foreign-currency intercompany balance is retranslated at the closing rate, the system rounds to two decimal places. The rounding difference — perhaps £0.43 in month one — goes somewhere, often to a rounding account or silently into the P&L. By month twelve, those twelve rounding entries have accumulated. The intercompany balances agree in the functional currency of each entity but disagree by a small accumulated amount in the consolidation currency.
Monthly rounding difference (average): £0.43
Accumulated over 12 months: £5.16
Accumulated over 5 years (60 months): £25.80
With 12 intercompany pairs × 5 years: £309.60 — and growing
Individually these are immaterial. Collectively, across a group with many intercompany relationships over many years, they can create unexplained differences that nobody can trace back to a specific transaction. The solution is a dedicated rounding/translation variance account at group level that absorbs these differences, reviewed annually and written off as immaterial if they are. For a detailed treatment of how exchange differences accumulate in multi-entity groups, the guide to getting CTA right at consolidation covers the mechanics.
Stop Hunting Intercompany Differences Manually
BrizoConsol matches intercompany balances automatically across all entities at close — flagging differences by type, amount, and entity pair so you can fix them in minutes, not hours. See It In Action
Building an Intercompany Reconciliation Process That Catches These Early
The seven causes above share a common thread: they are all detectable before the consolidated trial balance is run, if the reconciliation process is structured to look for them. The standard “confirm the balance” approach — where each entity just confirms a total — is not enough. A proper intercompany reconciliation matches at the transaction level, not just the account total.
The most effective approach is a bilateral transaction-level match: each entity exports a list of every intercompany posting for the period (date, amount in functional currency, counterparty, account), and those lists are compared transaction by transaction. A difference in a total can hide multiple offsetting errors; a difference in a transaction-level match cannot. The full intercompany reconciliation guide walks through how to structure this process.
The second structural fix is timing. Intercompany reconciliations should happen before period end, not after. If both entities close their intercompany sub-ledgers on day −3 of close, differences surface while there is still time to correct them. Finance teams that reconcile intercompany balances on the last day of close — or worse, after the consolidation is run — are always chasing the wrong problem. The multi-entity month-end close checklist sets out a sequencing framework that puts intercompany reconciliation in the right place in the close timeline.
Third: automate where you can. Recurring intercompany charges — management fees, IT recharges, shared services — should be posted by the system on a fixed date, not manually by a bookkeeper who might use the wrong account, the wrong rate, or post it a day late. When the journal is automated, causes 1, 2, and 4 above essentially disappear. For groups still posting these manually, automated intercompany journals are the single highest-return investment in close efficiency.
The Eight-Step Diagnostic Checklist
When you’re staring at an unexplained intercompany difference and both entities have confirmed they posted, work through this sequence before escalating:
- Check the period of each posting. Pull the date of Entity A’s posting and Entity B’s posting. If they’re in different months, you have a timing difference — apply or accrue accordingly.
- Check the functional currency amounts, not just the reporting currency. If both entities record the transaction in their own currency, compare the functional currency amounts first. Any difference here is a rate issue, not a posting issue.
- Confirm the closing rate was applied at period end. Even if the inception rates differ, both entities must retranslate monetary balances at the same closing rate. Pull both entities’ closing rate and compare.
- Check the account codes, not just the account names. A balance in “Intercompany Payable” and a balance in “Sundry Creditors” will not match. Run a full account-by-account listing for both entities and look for unexpected intercompany balances in non-intercompany accounts.
- Look for in-transit payments. Check whether Entity A processed a payment in the final three days of the period. If so, confirm whether Entity B received the cash before or after period end.
- Strip out bank charges. If the difference is small relative to a payment value, request Entity B’s bank statement entry for the period. Check whether SWIFT or correspondent bank charges reduced the received amount.
- Run a cumulative rounding check. If the difference is less than £50 and the accounts have been open for more than a year, check whether the variance matches accumulated monthly rounding differences. These can be confirmed by summing all prior-period reconciling items.
- Escalate with evidence, not summaries. If you cannot trace the difference after the above steps, share transaction-level exports from both entities — not just balance totals — with the entity accountants. Ask them to mark each transaction on their list against its counterpart on the other entity’s list. The unmatched item will be visible within minutes.
Most intercompany differences are not errors — they are timing or translation effects. The question to answer is not “who is wrong” but “at what point in the transaction lifecycle did the two entities diverge?” Once you know that, the fix is almost always straightforward.
Understanding the root cause also matters for how you eliminate the difference in the consolidation. Not all intercompany differences are eliminated the same way — some require a consolidation journal, others require a correction at the entity level, and some (like in-transit items or rounding) are treated as consolidation adjustments that don’t touch entity books at all. The guide to journal entries in group consolidation covers which type of adjustment to use in each situation, and the intercompany eliminations practical guide explains the elimination logic that sits underneath all of it.
For groups that have moved beyond the diagnostic stage and want to prevent these mismatches from occurring in the first place, the combination of transaction-level reconciliation, automated journals, and a common chart of accounts eliminates the majority of intercompany differences before the consolidated trial balance is ever run. The goal is to make “both companies agree and the consolidation agrees too” the normal state — not the exception that requires three hours of investigation at 10 pm.
Ready to Close Intercompany Faster?
BrizoConsol automates intercompany matching, flags discrepancies by type, and lets you drill from the consolidated difference straight to the source transaction — across every entity in your group. Start Free Trial