Below a certain number of legal entities, intercompany reconciliation is a manageable, if tedious, part of close. Somewhere around 10 entities, for most groups, it stops being manageable and starts being the thing that determines whether close finishes on time. The mechanics don't change — you're still matching intercompany receivables against intercompany payables across entity pairs — but the combinatorics do: 10 entities means up to 45 possible bilateral relationships to reconcile, and every one of them can carry timing differences, currency translation differences, and entity-specific posting quirks.
Why intercompany breaks at scale
Intercompany reconciliation has a structural problem most other reconciliation types don't: for it to balance, two different entities' books — usually with different local teams, different posting timing, and sometimes different systems or configurations — have to agree with each other, not just with a single external source of truth like a bank statement. A single entity posting a transaction a day later than its counterparty, in a different functional currency, at a different exchange rate, is enough to create a break that shows up as a real mismatch even though nothing is actually wrong.
The core problem: mismatched postings across entities
The most common source of intercompany breaks isn't fraud or error — it's timing and translation. Entity A posts an intercompany invoice on the 28th; Entity B doesn't post the corresponding entry until the 2nd of the following month, after the exchange rate has moved. At small scale, someone manually walks through the handful of mismatches and adjusts. At 10+ entities, the number of these timing-driven breaks scales with the number of entity pairs, and manual walk-throughs stop being feasible within a close timeline.
What best-in-class groups do differently
Groups that handle intercompany reconciliation well at scale tend to share a few practices:
- A standardized intercompany posting protocol. Every entity uses the same IC partner codes, the same document reference conventions, and posts intercompany transactions within the same tight window relative to period-end — removing the biggest source of timing breaks before reconciliation even starts.
- Matching by IC partner code and document reference, not just amount. Amount-only matching is unreliable across currencies. Matching on the combination of partner code, reference, and translated amount catches breaks that amount-only logic misses.
- A netting and settlement cadence separate from the elimination process. Settling intercompany balances more frequently — monthly rather than quarterly, for instance — keeps the population of open items small enough that a break is easy to isolate.
- A shared, real-time IC dashboard visible to every entity controller. When every controller can see the other side of their intercompany relationships without emailing a counterpart, mismatches get resolved during the month instead of surfacing for the first time at close.
- Clear escalation SLAs for unresolved breaks. An intercompany break that isn't resolved within a defined number of days should automatically escalate to both entity controllers' managers, not sit in a shared inbox.
Currency and timing complications
Multi-currency groups add a second layer: even a perfectly timed, perfectly matched intercompany transaction can show a variance purely from exchange rate movement between the posting dates of the two entities. Best-in-class groups separate genuine posting mismatches from FX-driven variances in their reporting, so a controller isn't chasing a "break" that's actually just currency translation working as designed.
Where automation changes the equation
Automated intercompany matching doesn't eliminate the underlying complexity of multi-entity groups, but it removes the manual walk-through bottleneck: matching runs continuously against every entity pair rather than in a single manual pass at close, genuine breaks get routed to the two relevant entity controllers automatically, and FX-driven variances get flagged separately from real mismatches instead of adding to the pile.
Getting started if you're not there yet
For groups still reconciling intercompany manually at scale, the highest-leverage first step is usually the posting protocol — standardizing IC partner codes and posting windows across entities — because it reduces the number of breaks generated in the first place, before any tooling gets involved. From there, automated matching and a shared dashboard address what's left.