Intercompany balances do not become reliable merely because two entities totals happen to net to zero. The close owner needs a repeatable way to prove that each pair is complete, matched at the right level, corrected in the source ledger, and ready for consolidation.
Quick answer
Run intercompany reconciliation as a controlled close workflow: define the entity pair and cutoff, collect both sides evidence, match transactions before totals, classify each difference, assign a correcting owner and due date, reperform the match, then hand only signed-off balances to consolidation. Keep timing items visible rather than forcing them away with an unsupported elimination.
What this process covers
This guide is for a group finance team reconciling balances and activity between entities it consolidates. It is not tax or transfer-pricing advice, and it does not replace entity-specific accounting policies. The outcome is a pair-level reconciliation record that shows whether the balance is matched, why it differs, who owns the resolution, and what can move to consolidation.
That boundary matters. A payment reconciliation process proves that a payment cleared as expected. Intercompany reconciliation proves that counterparties recorded the same internal economic event consistently before group reporting. The workflows may share evidence, but they have different owners and close outputs.
Use a defined close state
Give every entity pair a visible state: Not started → Evidence collected → Matched → Difference assigned → Corrected → Re-matched → Approved for consolidation → Closed. Do not let matched mean the net total looks reasonable. A matched pair has an identifiable counterparty, supporting transaction references, an agreed cutoff, and a documented treatment for every remaining difference.
Intercompany reconciliation control matrix
| Stage | Owner | Required evidence | Control and completion condition | Exception path |
|---|---|---|---|---|
| Scope the pair | Group close lead | Entity-pair list, account map, period calendar | Every in-scope pair has a preparer and reviewer. | New entity or unmapped counterparty is added before matching. |
| Collect extracts | Entity accountants | Ledger extract, currencies, reference, extract timestamp | Both extracts use the same cutoff and preserve their source time. | Late extract is marked incomplete; never treated as zero. |
| Match activity | Pair preparer | Invoice, journal, settlement, or agreement reference | Match at document level first, then compare totals. | Unlinked item receives a mismatch code and owner. |
| Resolve differences | Correcting entity | Difference log, source documents, proposed journal or dispute record | Each item has a classification, amount, owner, due date, and treatment. | Unresolved material item escalates before consolidation lock. |
| Approve handoff | Reviewers and group controller | Reperformed match, approvals, adjustment references | Only approved balances and explicit residuals move to consolidation. | Reopened pair returns to Difference assigned and requires reapproval. |
1. Set the population and cutoff before extracting data
Start with an entity-pair register, not a trial-balance total. For each pair, specify transaction types in scope, counterparty identifier, source accounts, currency, cutoff, preparer, and reviewer. A dedicated counterparty dimension or mapped account prevents an amount from becoming an orphan that cannot be paired.
Set one close calendar: last day to create the internal charge, last day to post each side, extract time, difference deadline, and consolidation lock. A charge booked after one entity extract but before the other is a timing difference, not proof that either ledger is wrong.
2. Match documents before you accept a balance
Compare each side in transaction currency first, using a shared reference where available. Then compare reporting-currency amounts and exchange-rate inputs. Net agreement can conceal offsetting errors, such as a duplicate charge and a missing charge of the same amount.
Oracle documentation describes unmatched pairs, amount and currency mismatches, and standalone transactions as records to identify before elimination. Treat those as useful exception types, not as a mandate for any particular accounting system or policy.
3. Classify every difference and make recovery explicit
Use a small, stable difference taxonomy: timing, missing or one-sided entry, wrong counterparty, amount, currency or rate, duplicate, commercial dispute, or unknown. Unknown is a temporary investigation state, not a final close treatment.
For each item, record the next state: Matched → Difference assigned → Correction proposed → Reviewer approved → Posted → Re-matched. If a correction changes a counterparty code, re-run both affected pairs. If the pair was already approved, reopen it and require a new approval; do not overwrite the original evidence trail.
Illustrative example: a late recharge
Entity A records a $12,000 services recharge on September 30. Entity B receives the invoice on October 2 and books it in October. The pair does not match at the September cutoff. The preparer classifies it as timing, attaches the invoice and both ledger extracts, names Entity B as owner, and records the expected October posting. The group controller decides whether policy requires an accrual or a documented residual for September. The preparer does not manually force the pair to zero. After Entity B posts and the pair is re-matched, the reconciliation moves to approval.
4. Separate source-ledger corrections from consolidation entries
Correct a one-sided entry, wrong counterparty, or duplicate in the originating entity records when policy and period rules permit. A consolidation adjustment may be necessary for reporting, but it should not substitute for fixing recurring source-data defects. The close record should distinguish source correction reference, consolidation treatment, and remaining operational follow-up.
For teams that need to coordinate the broader close, this complements an accounts payable month-end close checklist: AP close tracks supplier obligations; the intercompany register tracks agreement between internal counterparties.
5. Hand off only a reviewable package
Before the group controller releases the pair, require the pair ID, cutoff, both extracts, matched and unmatched populations, difference log, correction references, policy-based treatment for residuals, preparer attestation, reviewer approval, and consolidation handoff status. Keep links to underlying documents instead of copying sensitive records into multiple files.
Where Workhint fits
A connected work system can route entity-pair tasks, collect ledger extracts and supporting documents, require reviewer approvals, keep an exception log with owners and due dates, and preserve the handoff trail from match through close. Teams designing that flow can explore Workhint’s AI work-system builder or book a demo to map their close workflow.
Sources and implementation notes
- Oracle NetSuite: Intercompany Reconciliation Report — examples of unmatched and mismatched intercompany transactions and reconciling before elimination.
- Oracle Financials: Examples of Elimination Entries — illustrative consolidation context for intercompany balances.
- Deloitte DART on ASC 810-10 — U.S. GAAP consolidation context. Apply organization policy and professional advice to actual entries.
Leave a Reply