Agentic Intercompany Reconciliation: Catching Elimination Breaks Before Multi-Entity Consolidation
written by Cooter:Labs
published on August 20, 2026
Introduction
Any company running more than one legal entity generates intercompany transactions — Entity A sells inventory to Entity B, Entity C allocates a shared service cost to Entity A, a treasury entity charges interest on an intercompany loan. Each of these gets booked twice, once on each entity's own books, and at consolidation the two sides have to net to zero through an elimination entry, or the group's consolidated financials overstate revenue, cost, or balances that never actually left the company. In practice the two sides rarely agree cleanly: different posting dates, different FX rates, a reclass that happened on one side and not the other, an allocation that was calculated but never invoiced. Someone on the corporate accounting team spends days before close pulling intercompany schedules from each entity, matching them by hand, and chasing down whoever owns the entity that's out of balance. Agentic workflows can't decide what the right elimination entry is — that's still an accounting judgment — but they can do the continuous matching and flag exactly where and why two entities disagree, instead of that surfacing for the first time three days before the consolidated close deadline.
Reconciling a single entity's GL is fundamentally a one-sided problem: you're checking whether a set of accounts within one ledger is internally consistent. Intercompany reconciliation is two-sided by construction — the same economic event gets recorded independently by two entities that may run different ERP instances, different charts of accounts, different functional currencies, and sometimes different close calendars. A mismatch can be a real error, or it can be an artifact of the two entities simply not agreeing on when or how to record something that both sides technically got right. An agent working this problem has to pull from two separate subledgers, apply a consistent basis for comparison across both, and only then decide whether what's left over is a genuine break. That's a different, and harder, matching problem than the account-level variance detection inside a single entity's trial balance.
The starting point is pulling every intercompany transaction — IC sales and purchases, cost allocations, loan interest, management fees — from both entities' subledgers and matching them as pairs, keyed on shared references: PO or invoice number, transaction date range, counterparty entity code, and amount before any currency conversion. This is different from comparing account balances at period end, which can look reconciled by coincidence (two unrelated errors that happen to net out) or unreconciled when everything is actually fine (a timing difference that will clear next period). An agent matching at the transaction-pair level can point to the specific invoice that has an entry on Entity A's books with nothing mirrored on Entity B's side, instead of reporting a balance-level variance that someone then has to decompose by hand.
When the two entities transact in different functional currencies, an apparent mismatch is often just two legitimate rate choices — Entity A converted at the transaction-date spot rate, Entity B recorded its side at a period-average rate used for its local reporting. An agent needs to apply the group's stated intercompany FX policy consistently to both sides before comparing them, and separately flag cases where a transaction posted in one entity's current period hasn't yet posted in the other's (a real timing difference, expected to clear, not an error to chase down today). Only the variance that survives both normalization steps should get surfaced as an actual break — reporting raw, unnormalized differences just trains the team to ignore the report.
At consolidation, elimination entries are supposed to zero out intercompany balances so the group's external-facing numbers don't include revenue or expense that never left the company. Under close-deadline pressure, it's common for an elimination to get entered as a single balancing plug sized to make the consolidated trial balance tie out, rather than as the sum of specific matched IC transactions. An agent can require every elimination entry to trace to an underlying matched pair from the previous phase, and flag any elimination that doesn't — because a plug that ties out the consolidated numbers this period is usually a real unresolved break carried forward, not a break that's actually been fixed.
A break between the same two entities that shows up almost every period, even a small one, usually means there's a structural problem — a mapping table that routes a transaction type to the wrong account on one side, or two entities that never agreed on which one books a shared cost first. That's different from a one-off break caused by a single missed entry. An agent tracking break history by entity pair and transaction type can distinguish a recurring pattern worth escalating to fix the root cause from an isolated exception that just needs one correcting entry this period — and route each differently instead of routing every break to the same generic review queue.
Looking Ahead: Challenges and Innovations
Entities on different ERP instances need a mapping layer that itself drifts
Multi-entity companies, especially ones that grew through acquisition, often run subsidiaries on different ERP systems with different charts of accounts and different transaction data models. Matching intercompany transactions across that boundary requires a mapping layer translating each entity's account and transaction structure into a common comparison basis — and that mapping has to be maintained as either ERP's chart of accounts changes. An agent built on top of a stale mapping doesn't fail loudly; it just starts silently misclassifying transactions as breaks (or worse, silently matching things that shouldn't match), so the mapping itself needs its own periodic review, not a one-time setup.
FX rate policy is a judgment call baked into the numbers, not a fact the agent can verify
Which rate an entity should use to record an intercompany transaction — transaction-date spot, period-average, or a contracted intercompany rate — is a policy decision set by corporate accounting, and different entities sometimes apply it inconsistently in practice even when the policy itself is clear. An agent can enforce a normalization rule based on the stated policy, but it can't independently determine which entity applied the wrong rate when the policy itself is ambiguous or under-documented for a given transaction type. In those cases the agent's job is surfacing the inconsistency clearly enough that a human can resolve the underlying policy gap, not silently picking a rate and moving on.
Transfer pricing means the two sides are sometimes supposed to disagree
Intercompany service charges and cost allocations are frequently priced with a deliberate markup for tax and transfer-pricing purposes — Entity A doesn't invoice Entity B at cost, it invoices at cost plus a contractually set percentage. A naive reconciliation that expects the two sides to match dollar-for-dollar will flag every one of these as a break. The agent needs the expected variance — the actual transfer-pricing terms for each entity pair and transaction type — configured as ground truth, not inferred from the data, or it will spend the team's attention on discrepancies that are working exactly as designed and miss real errors buried in the noise of false positives.
The metaverse
As more of the close process shifts from a period-end sprint to continuous, agent-monitored matching, intercompany reconciliation is one of the clearer cases for moving that work earlier — because unlike a lot of GL-level variance detection, an unmatched intercompany transaction is often identifiable the same day it's booked, not just at month-end. The direction most mid-market multi-entity companies are heading isn't a single global ERP instance eliminating the problem outright — that consolidation is expensive and slow even when it's the right long-term move — it's an agent layer that can reconcile across whatever mix of ERP instances and entity structures a company actually has today, while that consolidation happens on its own timeline.
Conclusion
Intercompany reconciliation is hard not because the accounting concept is complicated, but because it depends on two independently maintained systems agreeing on facts neither one fully controls — the counterparty's posting date, the counterparty's FX rate choice, the counterparty's account mapping. What an agent adds is continuous, transaction-level matching across that boundary, normalized for the timing and currency differences that are expected, so what reaches a corporate accountant is the small set of breaks that are actually unexplained — not a balance-level variance report that still needs to be decomposed by hand three days before consolidated close. The elimination entries still need a person to approve them, and the transfer-pricing terms and FX policy still need to be right in the first place. The agent's job is making sure a real break gets caught in the period it happens, not discovered for the first time during closing week.
Share this post:
Curious what this means for your business?
Get a personalized ROI estimate, or book a free discovery workshop with our team.