Intercompany Matching Methods: Balance, Invoice & Rule-Based

Intercompany matching methods comparedThere are three practical intercompany matching methods. Balance-level matching compares totals per counterparty pair and account category: cheap, fast, and it tells you a difference exists but not where. Invoice-level matching compares individual documents on a matching key: slower, but it locates the difference. Rule-based or automated matching applies tolerance and fuzzy-matching rules to clear the routine population so people only handle exceptions. Most groups should run balance-level monthly and invoice-level only on pairs that fail.The choice of matching method is usually made implicitly, by whatever the previous controller set up. It deserves a deliberate decision, because the method determines both the cost of the close and the kind of error that survives it.The useful framing is not 'which is best' but 'which population goes through which method'. A tiered approach costs far less than invoice-matching everything, and catches far more than balance-matching everything.Balance-level matchingBoth sides report their balance per counterparty pair and account category; the difference is calculated centrally.

Catches: existence of a difference, its size, and its trend over periods

Misses: which transactions cause it, and offsetting errors that cancel out

Cost: low — a submission template and a comparison, feasible for any group

Best for: monthly routine across all pairs, and for pairs with low volume and stable balances

Requirement: consistent account categories and counterparty entity codes across all local ledgers

Invoice-level matchingIndividual documents are matched between the two ledgers on a defined key.

Catches: the specific items causing a difference, duplicates, and offsetting errors

Misses: little, but generates false differences when the matching key is weak

Cost: high in effort unless the key is reliable — this is where teams lose days

Best for: pairs that fail balance-level matching, high-volume trading pairs, and year-end confirmation

Requirement: a stable matching key. Invoice number plus counterparty code works; description-based matching does not

Rule-based and automated matchingA rules engine — in the ERP, the consolidation tool or a dedicated matching product — clears the routine population automatically and routes exceptions to people.

Catches: the same as invoice-level, with far less manual effort once configured

Misses: whatever the rules are not written for; poorly tuned tolerances hide real differences

Cost: configuration and ongoing rule maintenance, plus licence where a tool is used

Best for: groups above roughly fifteen active trading pairs, or where the close is genuinely constrained by intercompany

Requirement: clean master data first. Automation on inconsistent counterparty codes produces confident nonsense

Designing tolerance properly

Set tolerance per pair as an absolute amount and a percentage, whichever is lower — a single group-wide figure is either too loose or too tight

Tolerance clears the item from the working list; it does not delete it. Write-offs above the threshold need approval and a record

Track cumulative tolerance write-offs per pair per year; individually immaterial, collectively they can matter

Never apply tolerance to loan, interest or dividend balances — these must match exactly

Review tolerance annually against group materiality, not against how tired the team is

Choosing the tier per pair

Volume and value: high on either means invoice-level or automated matching

Difference history: a pair that failed twice in the last six periods moves up a tier

Transaction type: financing and royalty flows justify exact matching regardless of volume

Jurisdiction risk: pairs spanning jurisdictions with active transfer pricing scrutiny deserve the detail

System distance: pairs on different ERPs break more often than pairs on one instance

Matching method selection checklist

Counterparty pair inventory with volume, value and difference history

Tier assigned per pair: balance, invoice or automated

Account categories consistent across all local charts of accounts

Counterparty entity codes mandatory on intercompany postings

Matching key defined and tested before any automation

Tolerance per pair as absolute and percentage, with the lower applying

Exact-match rule for loans, interest and dividends

Approval route for write-offs above tolerance

Cumulative write-off tracking per pair per year

Escalation rule for pairs moving up a tier

Master data cleaned before configuring an automated engine

Annual review of tiers and tolerances against group materiality

How we would approach this

We tier the pairs before recommending any tooling — most groups need better rules, not a matching engine.

We fix counterparty codes and account categories first, because every matching method depends on them.

We design tolerance as a documented policy with approval, so cleared differences remain visible.

What methods are used to match intercompany transactions?Reference-based matching on a shared document or transaction ID, amount-and-date matching within a tolerance, and counterparty-pair netting at balance level. Reference-based matching is the only one that scales without generating false matches.How should FX differences be treated in matching?Match in the transaction currency and translate afterwards. Matching on translated amounts creates differences that are purely a rate artefact and consumes review time that should go to real breaks.Primary sources

IFRS 10 — Consolidated Financial Statements — https://www.ifrs.org/issued-standards/list-of-standards/ifrs-10-consolidated-financial-statements/

IAS 21 — The Effects of Changes in Foreign Exchange Rates — https://www.ifrs.org/issued-standards/list-of-standards/ias-21-the-effects-of-changes-in-foreign-exchange-rates/