Intercompany reconciliation: when A's payable doesn't match B's receivable

Subsidiary A's books say it owes subsidiary B twenty dollars. B's books show no receivable at all. An accountant put exactly that to r/Accounting — "A owes B net of $20, but there's no intercompany receivable on B's balance sheet" — and the top answer was one line: "It means one subsidiary didn’t book an entry properly most likely". True. Also not a method. Here's the thing that makes intercompany feel cursed: there is no bank statement. Every other reconciliation checks your books against an outside referee — the bank, the platform, the processor. In intercompany, the "statement" is just another ledger you also own, kept by another team, in another currency, on another calendar. Every balance is a mirror pair: A's payable to B has to equal B's receivable from A, exactly, or consolidation breaks. The method below makes the mirrors match — pair by pair, in the transaction currency, before the close starts, so elimination becomes arithmetic instead of archaeology.

Why does intercompany have to tie out at all?

Because consolidation assumes it does. When a group reports, everything the subsidiaries did with each other has to disappear: in consolidated financial statements, one company's intragroup payable is cancelled against the other's receivable, so the group only shows business done with the outside world. That cancellation — elimination — is pure arithmetic, and it only works if both sides carry the same number. A owes B 20; B shows 0; eliminate both and the consolidated balance sheet is off by 20, hiding somewhere it doesn't belong. The mismatch that was invisible inside each entity becomes a real error in the group numbers.

And the one-line Reddit answer is where the work starts, not where it ends. A second commenter on that thread got closer to the real job — investigate side B: "Maybe there was a mistake and instead of booking $1230 someone booked $1210 giving you $20 left" — a booking error, a write-off one side never heard about, an entry that never happened. All plausible. Which one it is decides who books the fix and in which period. So the question isn't "why doesn't it net to zero" — it's "which of my mirrors disagree, and by what, and why." That needs structure.

The unit of work is the pair, not the account

Stop thinking in accounts and start thinking in relationships. With three entities you have three pairs; with six entities, fifteen. Each pair has two directions — what A shows against B, and what B shows against A — and reconciling the pair means both directions mirror. Lay it out as a counterparty matrix: one row per pair and direction, one column per side, and a difference column that should read zero. This is the intercompany version of reconciling any two systems: pick the two datasets, diff them, explain the residual — except here you repeat it for every cell.

The matrix does two things a plain trial balance can't. It tells you where to dig — only the pairs with a difference — and it makes one-sided bookings jump out, because a zero staring at a 3,120 is unmissable in a matrix and invisible in an account listing. The UK → AU row is the twenty-dollar Reddit question at real scale: somebody billed, and somebody never heard about it.

What is an intercompany difference, actually?

Nearly every intercompany mismatch is one of five things. Knowing the list turns a scary unexplained number into a sorting exercise — the same move that works in AR and AP reconciliation, where an aging-to-GL gap always decomposes into a short list of known causes.

The FX row deserves a beat, because it generates the most false alarms. When each entity keeps books in its own currency, the same invoice sits on both ledgers at different translated values — a translation difference, not an error, and chasing it as if a transaction were missing wastes hours. The way out is the same one that works for multi-currency reconciliation generally: compare the two sides in the currency the transaction actually happened in, where they should tie to the cent, and let the base-currency gap fall out as FX. If the pair ties in EUR and differs in USD, nothing is missing.

How do you reconcile one pair?

Here is the procedure for a single cell of the matrix. It's deliberately boring. Run it per pair, and the scary consolidated mess decomposes into a stack of small two-file matches — each one no harder than comparing two exports in Excel.

1. Fix the scope: one counterparty pair, one date range, both directions. Do not reconcile "the intercompany account" — reconcile US↔UK, then US↔AU, then UK↔AU.
2. Export both sides at transaction level, in the transaction currency, for the same period. Balances alone cannot tell you which transactions disagree.
3. Match on a shared reference — the intercompany invoice or charge number that exists on both ledgers. This is the primary ID of the match; if no shared reference exists, start stamping one on every intercompany document going forward, because matching on amount alone will happily pair the wrong items.
4. List what each side has that the other doesn't — a COUNTIF or MATCH set-difference does this in minutes — then classify every unmatched or unequal item into one of the five causes above.
5. Book corrections in the ledger that is wrong, dated in the open period. Never fix it at consolidation: a consolidation-level plug leaves the subsidiary's books still wrong, so the same difference comes back next month with interest.
6. Certify the pair: both entities sign off on the same closing balance, in writing. One person reconciling both sides beats two teams reconciling at each other.
7. Then run elimination. Matched pairs cancel to zero; anything left is a named, explained exception — not noise you hope the auditors don't ask about.

A worked cell, in the transaction currency so FX is out of the picture:

US entity — payable to UK (GBP)              118,400.00
UK entity — receivable from US (GBP)         121,900.00
Difference to explain                           3,500.00

UK invoice 2214, never booked by US            2,800.00   → US books it now
Bank fee deducted in transit on May wire         120.00   → US grosses up as fee expense
UK applied a payment to the wrong invoice        580.00   → UK reapplies it
Explained                                      3,500.00

After corrections: both sides show 121,180.00 → eliminate to zero

Why won't my intercompany clearing account go to zero?

There's a specific version of this that torments multi-currency groups: the flow-through account that should always empty, and doesn't. A NetSuite user described it exactly — an Other Asset Clearing account used for intercompany between subsidiaries in different currencies, where "Every transaction coming into this account is debited and then credited - so the balance should always be $0" — except the balance kept moving on its own, revaluing every period.

The mechanics: entries hit the clearing account in multiple currencies, and any that are still open at period end are foreign-currency balances, which the system revalues at the period-end rate — posting real adjustment entries to an account that was supposed to be empty. A commenter on the thread pointed at the setting: with Revalue Balances checked, "it's not actually the consolidated exchange rates it's that hard Curr Reval which actually posts a hard DB/CR like a JE". The account isn't haunted. It's holding open FX balances, and open FX balances get revalued.

The fix is upstream of the setting: match and clear the debit-credit pairs in their transaction currency and settle them promptly, so nothing is open when revaluation runs. A clearing account that empties every cycle has nothing to revalue. If pairs must straddle a period end, expect the revaluation entries and reconcile the account net of them — the same discipline as any in-and-out clearing account, just with a currency dimension. Note the close-sequence trap too: in NetSuite's period close checklist, intercompany elimination runs after open foreign-currency balances are revalued, so an unsettled clearing balance gets revalued first and then eliminated against a number that just moved. NetSuite's own model for the output side is elimination subsidiaries — as another commenter explained, "NetSuite has "elimination" subsidiaries that are children to a parent subsidiary" that absorb the cancelling entries so consolidated books balance without touching any entity's own ledger — the system's way of enforcing the rule above: corrections belong in the entity, eliminations belong at the group. The feature's docs cover the setup.

Reconcile continuously — not in the last two days of close

The volume version of this problem is brutal. A poster in r/Accounting put it flatly: "I work in a F500 that has high, high volume Intercompany transactions. And some accounts are an absolute mess." For the worst entities, "I am spending 4+ hours per day to reconcile a single account". One reply pointed them at a university research lab. Another commenter — one who had just moved to a reconciliation tool, so weigh the enthusiasm accordingly — named the actual mechanism: "waiting until the last 2 days of close to reconcile intercompany is what makes it spiral".

That mechanism is worth taking seriously, because it's structural. A difference found during close has to be investigated by two teams who are both slammed, corrected in a period that's about to lock, and re-eliminated — all in 48 hours. The same difference found mid-month is one email. And the cost of leaving it late lands on the whole business, not just finance: an operator running eighteen locations on separate QuickBooks files put it as "Month-end close takes forever because of intercompany reconciliation and nobody has a clean picture of the business until like two weeks after close". Two weeks of flying blind, every month, because the mirrors only get checked at the deadline.

• Match active pairs weekly: pull both sides, run the set-difference, chase one-sided items while the person who booked them still remembers. High-volume pairs may warrant daily.
• Set an intercompany cutoff: no new intercompany invoices in the last N business days of the period. Late items wait for next month — a small delay that buys a clean elimination.
• Set a dispute deadline: differences raised by day minus-three get resolved in-period; anything later is carried as a named open item, never a plug.
• Keep the certification: each pair's closing balance confirmed by both entities, filed with the close checklist. At close, elimination should confirm what you already know.

On tooling: the threads name Flow, Rillet, and Datarails, and NetSuite sells automated intercompany management — and a reconciliation-heavy group can genuinely be helped by any of them, or by pointing an AI agent at the two exports. But notice what every tool automates: the matching and the chasing. The matrix, the shared reference, the cutoff, the write-off threshold, and who-books-the-correction are policy decisions, and they cost nothing but agreement. Get those right in a spreadsheet first; automate them when the volume says so. If a cross-charge system exposes too few fields to trace a charge back to its documents — one NetSuite user's exact complaint, that "each cross charge can be linked to several PO's but it's very hard to report on that" — that's your shared-reference problem again, and no amount of matching automation fixes a reference that doesn't exist.

← All writing