How to prepare intercompany reconciliations with an AI agent

Reconcile by entity pair, at transaction level, before consolidation. The agent pulls both sides of each intercompany relationship, converts them at the group's agreed rate, matches transactions, classifies every difference and drafts correcting entries and queries for each entity. The two entity controllers agree the differences, approve their own entries and sign. Group finance clears any residual at consolidation.

What is intercompany reconciliation, and who owns it?

When entities in a group trade with each other, lend to each other or recharge costs, each records its side. Entity A's receivable from B should equal B's payable to A. At consolidation those balances are eliminated. If they do not agree, the difference lands somewhere it should not, and someone has to explain it under deadline pressure.

The basics are covered in what is an intercompany reconciliation. Ownership is split, which is why it goes wrong: each entity controller owns their own books, and neither owns the difference. Group finance or a central close team owns the process and the consolidation. Clear rules on who corrects what are the first control.

What are the steps, and who acts at each one?

1. Person, group finance: sets the rules. Which entity books first, the rate used for conversion, the cut-off date, and who corrects which kind of difference.
2. Agent, depth 1: pulls both sides by pair. All intercompany accounts for each pair of entities, at transaction level.
3. Agent, depth 1: converts and matches. Converts to a common currency at the agreed rate and matches transactions by reference, amount and date. Many-to-one matches are proposed, not confirmed.
4. Agent, depth 2: classifies differences. Timing (invoice in one ledger, not yet in the other), FX (different rates applied), mis-coding (booked against the wrong counterparty or a third-party account), disputes (one side disagrees with the charge) and unknowns.
5. Agent, depth 2: drafts entries and messages. For each entity, the correcting entries its side needs under the rules, parked. For each disagreement, a message to the other entity's controller with the transactions attached.
6. Person, entity controllers: agree and approve. Each approves entries in its own ledger; disputes are resolved between them or escalated to group finance.
7. Agent, depth 1: re-runs after corrections. Confirms the pair now agrees, or lists what remains.
8. Person, group finance: signs off pairs and clears residuals at consolidation.

What does a classified difference look like?

Take an illustrative pair: a parent recharges a subsidiary 50,000 for shared IT costs at month end. The parent books the receivable on the last day; the subsidiary has not yet booked the payable. The agent matches the parent's entry to nothing on the other side, finds the recharge invoice in the subsidiary's payables inbox, classifies the difference as timing and drafts the payable for the subsidiary's controller to approve. A second difference of 1,300 on the same pair turns out to be FX: the subsidiary converted an earlier recharge at the invoice date rate, not the agreed month-end rate. Under the group's rules, the subsidiary posts the FX difference.

Which controls matter, and what evidence do they leave?

One rule set. Evidence: the rules version on every pair's reconciliation.

Each entity approves its own entries. The agent never posts to an entity's ledger on another's say-so. Evidence: approver identity per entity.

Agreed rate. Both sides converted at the same rate source and time. Evidence: rate reference on the match record.

Counterparty coding check. Intercompany transactions booked to third-party accounts, or with the wrong counterparty code, are found by searching both ledgers for the other entity's name and references. Evidence: mis-coding list.

Ageing. Differences carry the date they first appeared. Evidence: origin date per item.

What should you measure?

• Unmatched value by pair, at each close.
• Age of open differences. Old ones are disputes nobody is resolving.
• Residual eliminated at consolidation without explanation. Should trend to zero.
• Days from cut-off to agreed pairs.
• Mis-coded transactions found, by entity.

Where does it usually go wrong?

Both sides correct the same difference. Entity A books the missing invoice and entity B reverses its side, and the difference reappears the other way. The rules must say who corrects each type.

Netting across pairs. A difference between A and B is offset by one between A and C in a group-wide total. Reconcile by pair, never in aggregate.

Recharges disputed silently. A management recharge is booked by the parent and never accepted by the subsidiary. Send disputes to a named person in group finance with a deadline.

FX treated as an error. Different rates applied on different days produce small differences each month. Agree the rate rule, and post FX differences under it rather than chasing them as errors.

Unrelated reconciliation logic reused. Bank reconciliations and client money reconciliations look similar but have one authoritative side. Intercompany has two equal sides, so agreement, not matching, is the goal. Pairs that are agreed feed the entity's balance sheet reconciliations for those accounts.

Where Pryme fits

In Pryme, matching, classifying and drafting entries are separate capabilities certified on your own past closes, and each entity's ledger is a separate scope, so an entry for one entity is held for that entity's controller. Whether an agent can do intercompany reconciliations more broadly, and the finance bounds behind it, are in AI agents for finance.