When intercompany mismatches keep appearing month after month despite the finance team’s best efforts to resolve them, the problem is usually not the individual mismatches — it’s that the team is fixing symptoms rather than root causes. A timing mismatch that recurs every period isn’t a series of individual errors: it’s a structural problem with how two entities recognise the same transaction. Fixing it once, for that period, leaves the root cause in place and guarantees the same mismatch next month.
This post covers how to diagnose whether a mismatch is transactional (one-off) or systemic (structural), the specific root causes behind each type, and the fix that actually prevents recurrence.
The Core Distinction: Transactional vs Systemic Mismatches
The most useful first step in any mismatch investigation is classifying the mismatch type — because the correct fix is entirely different depending on which category it falls into.
| Mismatch type | Will it recur? | Root cause category | Fix required |
|---|---|---|---|
| Data entry error (typo, wrong amount) | Not predictably | Transactional | Correct the entry; add review step |
| Timing difference (different period recognition) | Yes — every period with similar transactions | Systemic | Align recognition policy across entities |
| FX rate inconsistency | Yes — every period without a common rate policy | Systemic | Publish a single group rate table |
| Account classification difference | Yes — until the COA mapping is corrected | Systemic | Update group COA mapping; document the correct classification |
| Missing counterparty reference | Yes — until reference coding is enforced | Systemic | Mandate counterparty codes on all intercompany transactions |
| One side recorded, other side missing | Depends — may be timing or may be a policy gap | Either | Investigate and categorise before fixing |
Transactional mismatches are corrected by fixing that transaction. Systemic mismatches are corrected by changing a policy, process, or system configuration — and the correction needs to happen at the source, not just for that month’s close.
Root Cause 1: Recognition Policy Differences
Two entities applying different revenue or expense recognition policies to the same transaction will produce a mismatch every single period in which that transaction type occurs. This is the most predictable and most persistent class of systemic mismatch.
Example — revenue recognition policy divergence Entity A (manufacturing) recognises intercompany revenue on date of shipment. Entity B (distribution) records the intercompany purchase on date of receipt, which is typically 5 days after shipment. At 31 March:
Entity A has recognised 3 shipments totalling $180,000 as March revenue.
Entity B has received and recorded 1 of those shipments ($60,000) in March; the other 2 arrive 1 April and are recorded in April.
Mismatch at consolidation: Entity A shows $180,000 intercompany receivable. Entity B shows $60,000 intercompany payable. $120,000 unmatched.
This mismatch will recur every month that contains shipments near period end. Fixing it by posting an accrual in Entity B in March deals with this period — but the policy divergence is still in place for April.
✅ Permanent fix: Define a single group-wide recognition policy for intercompany transactions — typically, recognition on the transaction date (shipment date for goods, service delivery date for services) — and require all entities to apply it consistently. Entities that receive invoices late accrue the liability as at the transaction date. The policy goes in the group accounting manual, not an email chain.
Root Cause 2: Account Classification Divergence
Classification mismatches are more dangerous than amount mismatches because they are harder to detect. The amounts may agree exactly — $50,000 on both sides — but one entity has coded the transaction to COGS and the other to intercompany expenses. At consolidation, the automated match finds the amounts but not the accounts, or finds the accounts but not the amounts, depending on how the matching logic is configured.
The consequence: even after the balance sheet elimination (intercompany receivable and payable cancel out), the P&L elimination is incomplete. Group COGS is understated and group intercompany expenses are overstated — or vice versa — producing wrong margins in the consolidated income statement.
Classification mismatch — impact on group margins Entity A charges Entity B $90,000 for manufactured components.
Entity A: Dr Intercompany Receivable / Cr Intercompany Sales Revenue
Entity B: Dr Raw Materials (COGS) / Cr Intercompany Payable — correctly records as raw material input
Elimination at consolidation: Dr Intercompany Sales Revenue $90,000 / Cr ??? (the elimination system can’t find a matching intercompany expense because Entity B coded to Raw Materials, not to an intercompany expense account)
Result: intercompany revenue is eliminated but COGS is not reduced. Group gross profit is understated by $90,000.
✅ Permanent fix: Define the group COA mapping for every intercompany transaction type — which account the provider uses, which account the recipient uses — and document it in the group accounting manual. The receiving entity’s coding must be consistent with what the elimination system expects, not whatever is most natural locally.
Root Cause 3: Batch vs Line-Item Recording
One entity records a single consolidated invoice covering multiple underlying transactions. The counterparty records each transaction individually. The totals match; the line items don’t. Automated matching by invoice number fails because there is no common reference — one side has one entry, the other has five.
Example — batch vs line-item divergence Entity A (shared services) issues a single monthly invoice to Entity B covering IT support ($12,000), HR services ($8,000), and finance services ($5,000) — total $25,000, Invoice IC-2024-03-001.
Entity B’s AP team processes each service category as a separate purchase order: IT $12,000, HR $8,000, Finance $5,000 — three separate entries with no reference to Invoice IC-2024-03-001.
Automated matching: Entity A has one $25,000 entry with reference IC-2024-03-001. Entity B has three entries with different references totalling $25,000. No automatic match. Manual investigation required every month.
✅ Permanent fix: Mandate a common transaction reference that appears on both sides — the invoice number that Entity A issues must be recorded by Entity B as the reference on each of its three lines. Or standardise to a single consolidated AP entry in Entity B that mirrors Entity A’s invoice structure. Either works; inconsistency between the two doesn’t.
Root Cause 4: Partial Settlement Without Notification
Entity B makes a partial payment against an intercompany balance — $30,000 of a $50,000 payable — without notifying Entity A’s accounts receivable team. Entity A’s books still show $50,000 outstanding. Entity B’s books show $20,000. The $30,000 difference appears as an unexplained mismatch at the next reconciliation.
This is a process gap, not a recording error. Both entities have recorded correctly in their own systems. The mismatch arises because settlement activity isn’t communicated across entity lines in real time.
✅ Permanent fix: Require settlement notifications — when an entity makes a partial or full settlement of an intercompany balance, it notifies the counterparty on the same day. For groups using a centralised treasury or intercompany netting centre, this notification is automatic. For groups without centralised treasury, it requires a procedural commitment from AP/AR teams in each entity.
Building the Mismatch Register
Groups that make genuine progress on intercompany mismatches maintain a mismatch register — a running log of every mismatch identified, its root cause category (transactional or systemic), the resolution, and whether a permanent policy or system fix has been applied. The register makes two things visible that are otherwise invisible:
- Recurrence patterns: the same root cause appearing in multiple periods is the signal that the fix has addressed the symptom but not the cause
- Entity-level accountability: which entities generate the most mismatches, and of what type — which focuses remediation on the entities or processes producing the most friction
💡 The most useful metric: The proportion of mismatches that are systemic (recurring structural causes) vs transactional (one-off errors). A high systemic proportion means the process is broken. A high transactional proportion means the process is sound but execution is inconsistent — a different problem with a different fix.
BrizoConsol identifies unmatched intercompany balances before the consolidation runs — flagging both amount differences and missing counterpart entries — with drill-down to the entity and account level so the root cause can be investigated and the permanent fix applied. Learn more or see it in action →