Ask any group finance team what slows down the consolidation close most, and the answer is almost always the same: intercompany reconciliations. Not the elimination entries — those are mechanical once the balances are agreed. The problem is getting to agreement. Each entity records its intercompany transactions independently. By month-end, the numbers often don’t match. What follows is a cycle of emails, spreadsheet comparisons, and correction requests that can stretch the close by days.
This post covers the specific reasons intercompany reconciliations fail, the process steps that prevent them from becoming bottlenecks, and the practices that let finance teams catch mismatches before close rather than during it.
The Scale Problem
Before addressing the causes, it’s worth quantifying why reconciliation gets harder as the group grows. In a group with n entities, the number of entity pairs that may have intercompany balances is n(n-1)/2. A five-entity group has 10 pairs. A ten-entity group has 45 pairs. Each pair may have multiple transaction types — a loan, a management fee, intercompany sales, shared services. The reconciliation matrix grows faster than the entity count.
For each intercompany transaction that involves both a P&L element and a balance sheet element — intercompany sales are the clearest example — there are four positions that must agree before elimination can proceed cleanly:
- Revenue in the selling entity (P&L)
- Cost of sales or inventory in the buying entity (P&L / Balance Sheet)
- Receivable in the selling entity (Balance Sheet)
- Payable in the buying entity (Balance Sheet)
All four must match. A mismatch in any one of them produces either an unexplained residual in the consolidated balance sheet or an incomplete elimination in the P&L. The reconciliation process must confirm all four positions agree before elimination entries are posted.
Why Intercompany Balances Don’t Agree
Timing differences
The most common cause. One entity records a transaction in one period; the counterparty records it in the next. The result is a balance on one side with no matching balance on the other at period end.
Example Entity A (manufacturing) invoices Entity B (distribution) $100,000 for goods shipped on 28 March. Entity A records revenue and a receivable in March. Entity B, which has a 5-day payment terms policy and received the goods on 31 March, records the payable and inventory in April when the invoice is processed.
At 31 March consolidation: Entity A shows a $100,000 intercompany receivable. Entity B shows nothing. The elimination has no counterpart to cancel on Entity B’s side.
The resolution requires a group policy on recognition cut-off — typically, intercompany transactions are recorded on the transaction date (shipment, invoice, or service delivery) rather than when cash moves or the invoice is processed. Entities that do not follow this policy must accrue the missing balance at period end.
Currency mismatches
When an intercompany transaction is denominated in a foreign currency and each entity translates it using its own rate — pulled from its accounting software’s feed on different days — the translated amounts differ even though the underlying transaction is identical.
Example Entity A (SGD functional currency) invoices Entity B (GBP functional currency) SGD 50,000 for a management fee. Entity A records the invoice on 1 March using its bank’s GBP/SGD rate of 1.71: GBP 29,240. Entity B records the receipt on 3 March using its bank’s rate of 1.69: GBP 29,586.
The SGD amount is the same (SGD 50,000); the GBP amounts disagree by GBP 346. This is an FX difference, not a recording error. It should be recognised as an FX gain or loss in Entity B’s P&L — not forced into the elimination entry or left as an unexplained residual.
The fix: agree a single group exchange rate for each currency pair at each period end, published before entities record intercompany transactions. If rates have already been applied inconsistently, the FX difference must be separately identified and disclosed.
Inconsistent GL coding
Different entities use different accounts for the same intercompany transaction type. Entity A books management fee income to account 6000; Entity B books management fee expense to account 8210. Without a consistent group chart of accounts or counterparty tagging, the system cannot automatically match the two sides. Manual cross-referencing is required — which is slow and error-prone at scale.
Transfer pricing adjustments
Where intercompany transactions involve a markup (management fees, IP royalties, goods sold at intercompany transfer prices), adjustments made at period end to comply with transfer pricing policy can create mismatches if only one entity applies the adjustment. Entity A increases its management fee charge retroactively from $30,000 to $35,000 following a transfer pricing review. Entity B hasn’t yet updated its books. The receivable and payable are now $5,000 apart.
How to Streamline the Process
1 Standardise policies before the period starts Define group-wide rules on cut-off dates, which exchange rates apply to intercompany transactions, how markups are calculated, and what GL accounts are used for each transaction type. Publish these at the start of each period — not after mismatches have already been recorded. A policy that arrives during the close is too late to prevent the mismatch.
2 Require counterparty identification on every intercompany posting Both sides of an intercompany transaction must reference the same counterparty identifier before they can be matched. If Entity A charges management fees to Entity B under reference “MF-2024-03-SG-UK”, Entity B must record its payment under the same reference. Without a shared reference, matching is manual — matching by amount and approximate date, which fails the moment two transactions have similar amounts.
Counterparty code example Group policy: intercompany transactions use format [Transaction Type]-[Year-Month]-[Charging Entity]-[Recipient Entity].
Management fee for March 2024, SG entity charging UK entity: MF-2024-03-SG-UK
Entity A books: Dr Intercompany Receivable / Cr Management Fee Income — Reference: MF-2024-03-SG-UK
Entity B books: Dr Management Fee Expense / Cr Intercompany Payable — Reference: MF-2024-03-SG-UK
Matching is exact and automatic on the reference code.
3 Reconcile during the period, not only at period end Reconciling intercompany balances once a month — at close, when the pressure is highest — means every mismatch becomes a close-day fire drill. Mid-month reconciliation checks, or automated continuous monitoring, surface mismatches while there is still time to resolve them without delaying the close. The goal is to arrive at period end with intercompany balances that are already substantially agreed, not to begin the agreement process on day one of close.
4 Define tolerance thresholds for immaterial differences In large groups with many small intercompany transactions, a strict zero-tolerance policy on mismatches creates disproportionate work. Documented tolerance thresholds — for example, differences below 0.5% of the transaction value or $500, whichever is smaller — allow the team to waive minor differences with a note rather than investigating each one. Differences above the threshold require a root cause and resolution before the close proceeds.
5 Require formal balance confirmation for material positions For large intercompany balances — loans, significant trade receivables, material management fee accumulations — require written confirmation from the counterparty entity before the close. This is the equivalent of a bank confirmation in an external audit: both sides formally agree the balance exists, is correctly recorded, and has been reviewed and approved. Any discrepancy surfaces at confirmation, not after elimination entries have been posted.
6 Assign ownership to every intercompany balance Every intercompany balance should have a named owner on each side — the person in each entity responsible for ensuring the balance is correct and matched before submission. Without accountability, reconciliation queries go unanswered or are deprioritised in favour of local close work. Governance is the process step that makes the technical steps work.
What Automation Changes
Manual intercompany reconciliation in a spreadsheet environment requires the group finance team to pull data from each entity’s accounting system, format it consistently, run comparisons, and chase resolution by email. At five entities with multiple transaction types per pair, this is a day’s work. At ten entities, it’s several days — every month.
Automated matching identifies transaction pairs based on counterparty code, amount, currency, and period — and flags exceptions automatically. The finance team reviews the exception list rather than the full transaction set. Matching coverage improves (every transaction is checked, not just the ones the reviewer remembers to look at), and the time cost drops from days to hours.
What automation doesn’t do: resolve mismatches that require judgment. An FX difference, a timing difference, or a transfer pricing adjustment all require human assessment of the cause and a documented resolution. The automation surfaces them faster and more completely; the resolution still requires the finance team.
BrizoConsol’s intercompany matching identifies transaction pairs across all connected entities, flags unmatched balances with counterparty and amount detail, and surfaces exceptions before the consolidation run — so eliminations are posted against confirmed, agreed balances rather than against positions that are still in dispute. Learn more or see it in action →