# Intercompany Reconciliation Software for Multi-Entity Close

- Author: PreciseBankFlow (https://precisebankflow.com)
- Published: 2026-10-17
- Category: Choosing reconciliation software
- Canonical: https://precisebankflow.com/blog/intercompany-reconciliation-software

> What intercompany reconciliation software should do: match due-to and due-from across entities, handle currency, and route disputes to their owners.
Intercompany reconciliation software pulls the related-party balances from every entity in a group, pairs each receivable with the payable it should mirror, converts currencies on a stated rate, and sends each break to the person who can fix it. The test of a good tool is simple: at consolidation, every pair nets to zero or carries an explained, owned difference.

## What intercompany reconciliation software matches across entities

Intercompany reconciliation software matches at two levels. First it compares account balances for each pair of entities, such as the receivable in a parent against the payable in a subsidiary. Then, when the balances disagree, it drops down to the transactions underneath and pairs them on a shared key.

### Balance level

The balance check is cheap and catches most months that are already clean. For each entity pair the tool reads one closing figure from each ledger, flips the sign of the payable, and adds. A result of zero means the pair is ready to eliminate. Anything else opens a break, which is simply a recorded difference waiting for a cause.

### Transaction level

Transaction matching is where tools differ. A useful one pairs lines on a reference both entities carry: an intercompany invoice number, a journal batch ID or a settlement reference. Where no shared reference exists, it falls back to amount and date, which is weaker. Ask a vendor which key it uses first and what it does when two candidate lines share an amount. The general logic of rules, windows and tolerances is covered in [how transaction matching software pairs lines](/blog/transaction-matching-software#one-to-one-one-to-many-and-many-to-many-transaction-matching), and it applies here with one twist: both ledgers belong to your own group, so a missing line is always somebody's posting to make.

### A worked month for a three-entity group

The table below is an example. The group, entities and figures are invented for illustration. Parent (P) is a US company, Sub A is also US, and Sub B keeps its books in euros.

| Pair | Lead entity balance | Counterparty balance (in lead currency) | Break | Cause found | Routed to | Evidence attached |
| --- | --- | --- | --- | --- | --- | --- |
| P and Sub A | 62,400.00 receivable | 62,400.00 payable | 0.00 | None | Nobody | Both closing balances |
| P and Sub B | 118,250.00 receivable | 115,830.00 payable | 2,420.00 | Management fee invoiced by P on the 30th, not yet booked by Sub B | Sub B accounts payable lead | P's invoice, P's journal line |
| Sub A and Sub B | 9,900.00 payable | 10,140.00 receivable | 240.00 | Rate difference: Sub B used its month-end rate, Sub A the transaction-date rate | Group reporting | Both rates, source of each rate |

Two of the three breaks have a cause the tool could name from the data alone. The fee timing showed up because P's invoice had no partner line in Sub B. The rate gap showed up because the transaction-currency amounts agreed while the converted ones did not. A tool that can tell those two cases apart saves the close team the first hour of every investigation.

## Currency handling in an intercompany reconciliation tool

An intercompany reconciliation tool has to keep three amounts per line: the transaction currency amount, the amount in each entity's ledger currency, and the rate used to get there. Matching should happen on the transaction currency first, because that is the figure both sides agreed to. Converted amounts differ for reasons that are not errors.

### Why converted amounts drift

Each entity may translate at a different moment. One books at the spot rate on the invoice date, the other at the rate on the day it posts. At month end, open balances are often revalued. None of this is wrong, but it means the converted figures rarely tie to the cent across a currency border.

### What to ask the tool to show

- **The rate source and date for each side.** If the tool cannot say where a rate came from, a reviewer cannot test it.
- **A split between a matching difference and a rate difference.** A line that agrees in euros but not in dollars is a translation question, not a missing posting.
- **A threshold you set for rate noise.** Small differences below that threshold can be grouped and booked as one adjustment, with the list kept.
- **No silent revaluation.** The tool should report a rate difference, then let a person decide the entry.

A rate difference that is truly small is fine to clear in bulk. A large one usually hides something else, such as a line booked in the wrong currency entirely, so the threshold should be low enough that those surface.

## How should intercompany reconciliation software route disputes to their owners?

Intercompany reconciliation software should route each break to one named owner in the entity that has to act, with the evidence attached and a date by which it must be answered. A break assigned to "accounting" or to both entities at once tends to sit until the close deadline passes.

### Choosing the owner

The owner is usually the entity missing a posting. In the example above, Sub B never booked the fee, so the break goes to Sub B. When both sides have posted but disagree on amount, the entity that issued the original document, the invoicing side, is the better owner, because it holds the source. Tools that let you set these defaults per pair cut down on manual assignment each month.

### What travels with the break

- The two balances and the computed difference.
- The unmatched lines from both ledgers, with dates and references.
- Any document already on file, such as an invoice PDF or a loan schedule.
- A free-text cause field the owner must fill before closing the break.
- A history of who reassigned it and when.

### Escalation

Some breaks are disputes, not oversights. Sub B may reject the fee because it never agreed to it. A tool should let the owner mark a break as contested, which moves it to a different queue for group reporting or the controller. Contested breaks are a business question about the transfer pricing or service agreement, and they should not count against the entity's close score.

The general handling of open items, from triage to close, is the subject of [reconciliation exception management from flag to close](/blog/reconciliation-exception-management).

## Intercompany cash transfers and the bank statements behind them

Intercompany cash transfers are the one part of the cycle where a third party holds the record. When the parent funds a subsidiary or a subsidiary sweeps cash up, the money moves through bank accounts, and each bank's statement is independent evidence that the transfer happened, on what date, for what amount.

### Why the bank side matters

Two ledgers can agree with each other and still both be wrong. If Parent records a 50,000.00 funding and Sub A records the same receipt, the pair nets to zero. But if the wire was never sent, both bank reconciliations should show it: an outstanding item on one side and nothing received on the other. Intercompany tools that look only at ledgers will call that pair clean.

### What to check on the statements

1. Each entity's bank statement for the month foots: opening balance plus credits less debits equals the printed closing balance.
2. Each intercompany transfer in the ledger has a matching line on the sending account's statement.
3. The receiving account shows the credit, on the same day for a book transfer, or a day or two later for a wire.
4. Transfers in transit at month end appear as reconciling items on both bank reconciliations, not just on one.

PreciseBankFlow handles the statement half of this: it reads each entity's statements, proves they foot and matches the lines to that entity's ledger or register, listing what does not clear. It is not an intercompany matching engine, so the ledger-to-ledger pairing above still sits in your consolidation tool or workbook.

### When transfers become evidence in a dispute

Groups that wind down, split up or end up in litigation often need to show every related-party transfer over several years. At that point the bank statements, not the ledgers, are what lawyers and examiners will want indexed and numbered. [Organizing bank records for litigation and review](/blog/organizing-bank-records-for-litigation) explains how to build that index so the transfer trail can be trusted.

## Is an intercompany spreadsheet or macro enough before you buy software?

An intercompany spreadsheet is enough while the group has a handful of entity pairs, one currency and a single person who prepares every tab. It stops coping when pairs multiply, when several people edit the same workbook during close, or when no one can say which version the auditor saw.

### Counting pairs

The number of possible pairs rises faster than the number of entities. Four entities can trade in six pairs, six entities in fifteen, ten entities in forty-five. Not every pair trades every month, but each one that does needs a tab, a lead and a sign-off. Somewhere past a dozen active pairs, the time spent maintaining the workbook starts to rival the time spent reconciling.

### Macros and bots

A VBA routine can pull balances from exports and flag gaps, and many groups get several years out of one. The risks are familiar: the person who wrote it leaves, a column moves in an export, and the macro keeps running on the wrong field. [Bank reconciliation in Excel with automation macros](/blog/bank-reconciliation-in-excel-with-automation-macros) looks at how those routines break. Robotic process automation, where a bot logs in and copies figures between systems, has its own failure modes when a screen changes; [what RPA bank reconciliation automates and where bots fail](/blog/rpa-bank-reconciliation) covers them.

### Signs you have outgrown the workbook

- Breaks are found after the consolidation is drafted, not before.
- The same break appears month after month with no owner.
- Two entities each keep their own version of the reconciliation.
- Currency differences are booked as a single plug with no list behind it.
- The auditor asks who changed a cell, and nobody knows.

## When intercompany reconciliation software is the wrong purchase

Intercompany reconciliation software is the wrong purchase when the group's real problem is upstream: entities that post intercompany charges late, no agreed calendar for cut-off, or no policy on which rate to use. A tool will report those failures faster, but it will not make anyone post on time.

### Groups that gain little

- **Two entities, one currency, few transactions.** A short monthly schedule does the job, and the setup effort of a tool will not pay back.
- **Groups that settle every month.** If all intercompany balances are paid to zero in cash at month end, the bank reconciliations already prove most of the cycle.
- **Groups without a shared chart of accounts.** If each entity codes intercompany differently, the first project is mapping accounts, and that work comes before any software.

### Fix the process first

Agree a cut-off day for intercompany invoices, pick the rate source for each currency pair, and name a lead entity for every pair. Run two closes on that process using whatever you have now. If breaks still pile up after that, the problem is volume, and a tool will help. If they disappear, you may not need one.

When you do compare vendors, the questions in [what to ask before buying account reconciliation software](/blog/account-reconciliation-software-buying-questions) apply to intercompany modules too, especially the ones about evidence and trials on your own data. To see the bank-statement side of a multi-entity close tested line by line, [request early access to PreciseBankFlow](/get-started).