Intercompany Reconciliation and Eliminations: Why Multi-Entity Groups Miss the Close and How Shared Services Fixes It

TL;DR: Intercompany reconciliation is the process of matching the balances and transactions that entities in the same group record against each other, so they can be eliminated in full on consolidation. Multi-entity groups usually miss the close because the two sides of an intercompany transaction are booked by different teams, on different dates and at different exchange rates, and nobody owns the difference. A shared services centre fixes this by putting both sides of every intercompany entry under one team, one calendar and one set of matching rules. Our research found no published benchmark that measures how many days intercompany breaks add to a close, in India or anywhere else, so this guide works from implementation experience rather than survey data. The practical takeaway is to settle ownership, cut-off and exchange-rate rules first and choose software second.

Why do intercompany breaks delay the group close?

Intercompany breaks delay the close because eliminations cannot run until both sides of every intercompany balance agree. A management fee invoiced by an Indian parent on the last day of the month and booked by its Singapore subsidiary three days later is a break caused purely by cut-off. Multiply that by forty entity pairs and several transaction types, and the consolidation team spends the close chasing differences instead of reviewing results.

Intercompany elimination

the consolidation entry that removes balances, transactions, income and expenses between entities in the same group, so the consolidated accounts show only dealings with outside parties.

In our experience, the same five causes account for most breaks in a multi-entity group:

• Cut-off and timing. One entity books the invoice in the current period and the counterparty books it in the next. The amounts match eventually, but not at the reporting date that matters.

• Exchange rates. Each entity translates the same foreign-currency balance at a rate of its own choosing, often on a different date. The difference is small per transaction and large in aggregate.

• Disputed or undocumented cross-charges. A cost allocation arrives without the basis of calculation, so the receiving entity refuses to book it or books a lower figure. The dispute then surfaces at month-end rather than when the charge was raised.

• One-sided entries. Accruals, provisions and reclassifications get posted by one side with no instruction to the other. Nothing in either ledger flags the missing mirror entry.

• Mapping errors. Counterparty codes, account mappings or trading-partner fields differ across ledgers. The matching routine then fails on records that are economically identical.

The evidence base here is thin, and we would rather say so than paper over it. We have not found a published figure that quantifies the delay intercompany breaks cause, and ASPL does not publish numbers it cannot attribute. What follows describes mechanism and practice.

Eliminations break in the entity ledgers, not in the consolidation tool

A consolidation system can only eliminate what the entity ledgers already agree on. When the receivable in one entity and the payable in another differ, the system either refuses the elimination or pushes the residue to an intercompany difference account. Someone at group level then writes a top-side adjustment to clear it.

Top-side adjustments are the symptom finance leaders notice, and they recur every month because the cause sits upstream. The group controller fixes the consolidated number while the two entity ledgers stay wrong. By the next close, the same pair breaks again, often for the same reason.

Unrealised profit on intra-group sales of inventory or assets adds a second layer. The selling entity knows its margin and the buying entity knows what it still holds, but usually neither knows both. Unless one team collects both facts on a fixed schedule, the elimination becomes an estimate, and the estimate becomes a recurring audit query.

Shared services moves both sides of the transaction to one desk

A shared services centre is a team that performs a common process, such as accounts payable or intercompany accounting, for several entities in a group under one set of rules. For intercompany work, the decisive change is ownership: the same team raises the charge, books the mirror entry and confirms the match. Breaks caused by two teams interpreting one transaction differently largely disappear.

The table below sets out how the two operating models handle the points where intercompany work usually fails.

Moving the work does not fix it on its own. A shared services centre that inherits each entity’s local habits reproduces the same breaks in a new location. The value comes from the rules the centre enforces. That is why ASPL describes its approach as model-agnostic by design: the same rules apply whether the centre is captive, built under a build-operate-transfer contract or run as a managed service.

A seven-step intercompany rhythm that holds through month-end

The sequence below is the operating rhythm we install when we stand up an intercompany process inside a shared services centre. The order matters, because each step depends on the one before it.

1. Publish an intercompany policy and counterparty matrix. The policy lists every permitted transaction type, the entity pairs that use it and the accounts each side books to. Without it, the shared services team is matching against assumptions.

2. Fix one intercompany calendar. Set a cut-off for raising intercompany charges a few working days before month-end, and a confirmation deadline after it. Every entity works to the same dates, including those whose local close runs later.

3. Set a single exchange-rate rule. Choose one rate source and one rate date for all intercompany balances. Rate differences then become a reconciling item with a known cause, not a mystery.

4. Raise both sides from one source document. The originating entity’s charge triggers the mirror entry in the counterparty ledger, booked by the same team. A charge is complete only when both sides are posted.

5. Match weekly, not monthly. Running the match during the month shrinks the month-end backlog to the last few days of activity. Breaks found early are cheaper to resolve because the people involved still remember the transaction.

6. Escalate disputes on a clock. Any break unresolved after a set number of days goes to a named group owner, usually the group financial controller, whose decision both entities book. Disputes stop rolling forward from one month to the next.

7. Settle net balances on a schedule. Regular cash settlement or netting keeps intercompany balances small and current. Old, large balances are where FX differences and forgotten disputes accumulate.

How should reconciliation exceptions be documented?

Every break that survives the close needs a note that lets a reviewer, an auditor or next month’s preparer understand it without asking anyone. The weakest exception notes we see say “timing difference” and nothing else. That phrase is true of most breaks and explains none of them.

A useful structure comes from an unexpected place. Writing about research papers in Perspectives on Medical Education, Ross and Bibler Zaidi (2019) recommend^[1] that authors describe each limitation, explain its implication, offer alternative approaches and state how it was mitigated. The same authors argue that limitations sections are often reduced to generic themes such as small sample size. Swap “limitation” for “exception” and the guidance transfers almost word for word.

Applied to an intercompany break, that gives a four-part note:

• What the break is. State the entity pair, the amount, the currency and the transaction it relates to. A reviewer should be able to find both ledger entries from the note alone.

• What it affects. Say whether the break changes consolidated profit, only the balance sheet, or neither once eliminated. This tells the controller how urgent it is.

• What the alternatives were. Record whether the team considered booking an accrual, reversing the charge or escalating. This stops the next preparer from relitigating the same choice.

• What has been done about it. Name the corrective entry, its owner and its date. A note without a resolution date tends to become a permanent fixture.

Tooling should follow the process, not lead it

Automated matching and AI-suggested matches speed up the work only once the rules in the seven steps exist. A matching engine fed inconsistent counterparty codes and mixed exchange rates produces confident-looking matches on bad data. Bernard Marr’s advice in Forbes in March 2023^[2], written about ChatGPT as it then stood, was to always verify what the tool generates. Any suggested intercompany match deserves the same treatment before it drives an elimination.

Platform selection is a fit question, not a ranking question. Even a vendor-published ranking concedes the point: SCIKIQ’s own guide states^[3] that there is no single best platform for every enterprise, only the best fit. The same vendor argues that the DPDP Act, data localisation expectations and AI-readiness are the forces shaping platform decisions in India. Treat that as one vendor’s view, but it is a fair prompt to ask where your group’s finance data will sit before a shared services centre in India starts processing it.

ASPL has run the finance, governance and people workstreams through complete builds, including the Hyderabad GCC it set up for a US-listed logistics company. Our experience suggests the intercompany policy, calendar and escalation owner should be agreed before any system is configured. Software configured first tends to encode whichever entity’s habits the implementation team saw first.

Questions finance leaders ask about intercompany reconciliation