Skills / Reconciliation and close

Intercompany Reconciliation

Two entities record the same economic event independently, usually in two different currencies, and their books are expected to disagree slightly for reasons a reviewer can name, then agree exactly once those reasons are accounted for. That's the entire discipline behind intercompany reconciliation: not proving the numbers match, but proving you know why they don't yet, and clearing each reason until they do.

What it does

Intercompany reconciliation here matches each entity's leg of every intercompany transaction against its counterparty's mirror leg, across entities and across currencies, then classifies whatever doesn't match with a likely cause: timing, FX difference, a missing entry, or a data error. Only once a pair's discrepancies are confirmed, not just guessed at, does it propose an elimination entry, and only for the portion of the balance that's actually been proven to tie.

The output isn't a single number that says "reconciled" or not. It's a pair-by-pair accounting: both entities' positions shown in the same frame, every unmatched or inexact item named individually, and a proposed elimination built from the adjusted position rather than the raw one.

The one rule intercompany reconciliation can't skip

Never plug, and never let FX tolerance quietly stand in for proof. Matching across currencies has to be forgiving, since two entities translating the same invoice through different rate dates will never agree to the exact cent, but a pair that nets to zero with unclassified items still sitting underneath it is coincidence, not a reconciled intercompany balance. Every amount left over after matching, and every pair that only tied within tolerance rather than exactly, gets carried forward until it earns a confirmed classification.

How the matching cascade actually runs

For every pair of entities with recorded activity between them, intercompany reconciliation mirrors one side's legs so a genuine match lines up as equal amounts, then works through passes in order of strength, strongest evidence first, so a weaker rule can never claim a leg a stronger one should have matched:

PassWhat it matches on
1Document ID, regardless of amount, a doc-ID match with a differing amount is itself a finding
2Amount within FX tolerance plus an exact date
3Amount within tolerance plus date within a default five-day window
4Amount within tolerance plus overlapping description text
5 / 6Many-to-one or one-to-many, for batched intercompany settlements and shared-services recharges

Once a leg matches, it leaves the pool, so the cascade can't double-count it against a weaker rule further down the list.

Classifying what intercompany reconciliation can't match on its own

What a mismatch means is judgment, not something the match itself decides. Every unmatched leg or inexact pair gets one of five classifications before it can clear:

  • Timing. Recorded by one entity, not yet by the other, expected to true up next period without intervention.
  • FX difference. Both entities recorded the transaction; the translated amounts differ because each side used a different rate. Legitimate, but it needs a destination, usually a correcting entry or the cumulative translation adjustment, not the elimination entry itself.
  • Missing entry. The counterparty never recorded it. Needs a journal entry at whichever entity is deficient.
  • Data error. Wrong amount, wrong period, wrong account, or a duplicate. Needs a correcting entry, not a reconciling item that rolls forward untouched.
  • Unidentified. The one that never clears the gate. It's escalated regardless of size, because the absence of an explanation is the finding, not something materiality excuses.

What a reconciled pair actually requires

A pair in this intercompany reconciliation isn't marked reconciled, and the full pack isn't complete, unless every discrepancy carries a confirmed classification, unidentified items are escalated rather than buried, only rounding of a cent or less is auto-excused, and the proposed elimination reflects the adjusted position rather than the raw one. If an expected pair submits no activity from either side, it's flagged as not received instead of silently skipped.

What it won't do

It won't decide whether an unmatched item is really timing versus a missing entry versus a genuine error; it proposes a hypothesis, the preparer confirms the real classification. It won't judge whether an FX rate is correct or current; you supply the rate, and it surfaces exactly the gap a single period rate creates against each entity's own transaction-date rate. It won't book journal entries; missing-entry and data-error items get a suggested entity and a flag, posting is the preparer's job. And it won't replace reconciling one entity's own balance sheet to its subledgers; this skill proves two or more entities agree with each other, which is an input to consolidation, not consolidation itself.

Inputs and output

InputsEntity list with functional currencies, FX rates per currency, intercompany subledger detail or trial-balance-level IC balances (or both), and classifications fed back after review
OutputA workbook with a signable Pair Summary, a Mismatch Queue for review, Matched Detail showing every match and its variance, Proposed Eliminations for the proven portion of each pair, and an Exceptions tab for completeness gaps
Who it's forControllers at multi-entity companies reconciling intercompany balances before consolidation, and whoever reviews the proposed eliminations before they post

Related

Glossary: Intercompany Reconciliation · Account Reconciliation · Balance Sheet Reconciliation · Bank Reconciliation · Elimination Entries (glossary entry planned)

Related skill: Bank reconciliation → GL, the single-entity, single-ledger version of the same matching discipline this skill generalizes across entities.

Go deeper: Account Reconciliation: The Complete Guide

Adopt's agents run this same intercompany reconciliation across the actual systems each entity uses, not a static export, pulling both entities' subledgers, matching the population transaction by transaction regardless of which ERP each side runs, and handing back only the balances that still disagree with a likely cause already attached. Nothing posts, and no elimination moves into consolidation, without a reviewer's sign-off. Sign up free, or book a pilot to run it against the intercompany pair that's hardest to close.