Intercompany reconciliation: the mirror invariant nobody enforces

Intercompany reconciliation is the recon that group CFOs least want to discuss honestly. The reason is structural: intercompany is the only major reconciliation domain where both sides of the transaction are inside your own organisation, which means both sides are your own bookkeeping problem, which means there is nobody external to blame when the numbers do not tie. The shape of the failure is consistent across most groups. Entity A in Mumbai books a ₹3.2 crore service charge to Entity B in Singapore. Entity B is supposed to book the mirror — debit expense, credit Entity A payable — at the same amount in the consolidation currency at the agreed transfer-pricing rate, dated within an acceptable window. Often Entity B does not. The entry is delayed because the Singapore controller is on a different close calendar. Or it is booked under a different intercompany account because a new GL code was created in the Singapore chart of accounts that the Mumbai team does not know about. Or it is booked in INR when the Singapore entity reports in USD and nobody applied the right rate. Or it was simply forgotten. At quarter-end consolidation, the elimination journal cannot eliminate what does not exist on both sides, and the consolidation team is now writing emails at 11 PM trying to reconstruct what should have happened.

Most teams have never written down what they actually expect from their intercompany ledgers, which is part of why the failures persist. The expectation is best framed as an invariant. For every intercompany transaction T booked in entity A as a debit to expense and a credit to Intercompany_B, there must exist a transaction T-prime in entity B such that it is a debit to Intercompany_A and a credit to income, with the amounts equal in the consolidation currency at the agreed rate, dated within a window of (typically) seven to fourteen days, and tagged with a corresponding intercompany identifier. The invariant is symmetric: it must hold from both sides. The invariant is strict on amount and lenient on date — book it eventually, but book it. The invariant is rarely written down formally and almost never automatically enforced by the underlying ERPs, because most ERPs treat each entity's books as an independent ledger and have only weak hooks for cross-entity invariant checks.

Standard reconciliation tools reproduce the same blind spot. They match by identifier and amount within a single ledger pair: bank-to-GL is 'this bank statement against this cash GL'. Intercompany is fundamentally a cross-ledger problem with FX as a complicating dimension and bidirectional symmetry as the core constraint. Tools that do not model the bidirectional mirror produce two sets of MISSING exceptions when the invariant fails — entity A's view says 'B never recorded this', entity B's view says 'A's record does not exist' — without recognising that they are the same broken invariant. This produces double-counted exceptions, makes triage harder than it needs to be, and obscures the actual remediation, which is to fix the entity-side ledger that has the gap rather than to chase a counterparty.

ReconPe's recon engine has a dedicated ExceptionType.INVARIANT_VIOLATION for cases where matching fails not because data is missing but because a structural constraint has been violated. Intercompany asymmetry surfaces as a single INVARIANT_VIOLATION exception on the pair, not as two MISSING exceptions on each side. The exception classifier in the ACRE engine — the component responsible for deciding what kind of exception each match failure is — checks the configured invariant registry for the domain (intercompany has its own registry of mirror-pair invariants) before defaulting to MISSING_SOURCE or MISSING_TARGET. Surfacing the failure as INVARIANT_VIOLATION rather than as two MISSING entries changes what the controller does about it: instead of asking 'where is the counterparty record', they ask 'which entity's ledger is missing the mirror entry, and why', which is the actual operational question.

Mirror amounts almost never tie exactly when entities report in different currencies. Period-end revaluation, transaction-rate versus closing-rate differences, FX spread on settlement — each introduces a small residual that is real cash but not a true break. The Indian tax and accounting framework has specific rules for which rate to use when (the SBI reference rate for AS-11 revaluation, the customs rate for export valuation, the spot rate for transaction recording, the closing rate for monetary item revaluation), and the residual that emerges from applying these correctly is itself a meaningful number that auditors expect to see explained. ReconPe absorbs FX residuals into the WRITE_OFF_OR_ROUNDING and TIMING_DIFFERENCE residual classes — six of the eleven FinanceOpsResidualClass variants are explicitly not close-blockers, and the FX rate context lives in the residual reason field on the exception. The recon does not treat a ₹4,200 FX revaluation residual on a ₹3.2 crore intercompany pair as a break; it classifies it, captures the rate context, and lets the close move forward.

Intercompany cardinality is also rarely one-to-one in practice. A monthly intercompany invoice from a shared-services entity to an operating subsidiary often consolidates dozens of underlying transactions: transfer-pricing allocations across cost centres, shared-service charges by function, royalty allocations by product line, IT recharges by user count. The mirror entry on the receiving side is usually one consolidated journal entry, but the source side may have posted thirty individual cost allocations through the month. Subset-sum aggregation applies the same way as in AR-to-GL: one mirror journal entry, many underlying transactions, partitioned by counterparty (the intercompany entity code) and currency, bounded by date window, solved by the same depth-first search with branch-and-bound pruning. Twelve allocation lines summing to one mirror entry resolves in the same kind of time as the AR receipts case takes — under a second. The pruning constraints are tighter for intercompany because the counterparty match has to be exact (intercompany identifiers are deterministic, not fuzzy), but the underlying mechanics are the same engine.

The setup wizard for intercompany follows the same five-step pattern as Bank-to-GL, with the inputs renamed: upload Entity A's intercompany ledger, upload Entity B's intercompany ledger, AI Analysis (mapping suggestions and detection of which template to apply), Review, Run. The default rule template for intercompany is INTERCOMPANY_MIRROR, which encodes the bidirectional invariant: amount equality (with FX revaluation residual absorbed via tolerance), counterparty mirror (Entity A's reference to Entity B must reconcile with Entity B's reference to Entity A), date window (typically fourteen days, configurable), and intercompany account symmetry (the GL account on Entity A's side must be the configured pair of the GL account on Entity B's side). Most controllers using intercompany reconciliation accept the template defaults on the first run and tune the FX tolerance after seeing the first set of residuals on real data.

The close-blocker logic is what changes the operating profile of group consolidation. A consolidation can proceed when residuals are classified — FX revaluation, timing, allocation rounding — even if amounts do not tie exactly. The eleven-class enum plus the boolean close-blocker flag lets the controller mark FX residuals as accepted, timing residuals as deferred to next period, and allocation rounding as written off, and the elimination journal posts cleanly against what has been classified. The genuinely problematic small fraction of cases — where Entity B is missing the mirror entirely, where the amounts disagree by an order of magnitude, where an intercompany identifier on one side has no counterpart on the other — surface as INVARIANT_VIOLATION exceptions with the specific reason captured. The controller spends their time on those, not on the much larger population of FX and timing noise that previously dominated the queue.

Big-Four auditors specifically test intercompany during group audit. The standard test is to sample large intercompany balances, agree them to both entity ledgers, verify the elimination journal removed them correctly from the consolidated view, and check that any unreconciled balances are properly classified and disclosed. A reconciliation system that surfaces invariant violations as a distinct typed category — rather than burying them in a generic break list mixed with timing differences and FX noise — shortens the audit cycle measurably. Each aggregation group, each exception, and each classification decision logs the user, the timestamp, and the resolution note, which is exactly what the auditor wants to see in the audit trail. For groups subject to SOX-style controls, the determinism of the matching engine matters: the same input run twice produces identical groups and identical exceptions, which lets the auditor reproduce any specific match decision under their own controlled inputs without having to take the operator's word for it.

Most group CFOs have learned to treat intercompany as a quarter-end fire drill: a frantic three-day reconciliation effort with the consolidation team running on coffee and group-wide email threads. The shape of that work changes when the system carries memory across periods. The recurring patterns — Entity B always books the mirror in the next month, Entity C consistently uses the wrong cost-centre code, the Singapore subsidiary's allocations always arrive on the second working day after the Mumbai close — get tagged the first time they appear, get pre-annotated the second time, and get auto-suggested as resolutions the third time. The work shifts from chasing missing entries to confirming proposed links and reviewing classified residuals. The honest qualifier: this works when both entity ledgers are accessible and structured. Cross-jurisdiction subsidiaries with regional ERPs that do not export cleanly, or entities on legacy systems that produce intercompany extracts only as locked PDFs, are still hard. That is an upstream data-architecture problem, not something reconciliation tooling can solve. For groups with reasonably modern ERPs and exportable intercompany ledgers, automating the mirror invariant check is the single highest-leverage change you can make to your quarter-end close — the kind of change that turns a three-day fire drill into a four-hour confirmation pass.