This system map is part of the intercompany reconciliation guide. It shows where each record sits in a typical mid-size group, which identifier carries the case from one system to the next, and what one fully joined case looks like. A worked hard case is on the exception examples page.
The six places one intercompany case lives
A single intercompany charge touches more systems than either entity's ledger. In a group that runs separate ledgers per entity, or a shared ERP with workbooks beside it, the usual layout is:
- Seller entity ledger. The invoice or journal that creates the intercompany receivable.
- Buyer entity ledger. The bill or journal that creates the matching payable or expense.
- Entity and account mapping. A configuration table or spreadsheet that says which accounts pair across entities and which counterparty code means which entity.
- Matching tool or spreadsheet. The monthly match, its open items, reason codes and notes.
- Approval log. A workflow tool, ERP approval history or, often, email.
- Consolidation tool or module. The entries that remove intragroup amounts each period.
The system of record explainer helps when a client cannot say which of these holds the authoritative copy of a field, and who owns data in a shared group system covers the ownership side when entities share one instance.
System, record, linking key and owner
The table is the map. Read across a row to see what a system holds and which key carries the case onward; read down the key column to see the chain.
| System | Record | Linking key it carries | Joins to | Usual owner |
|---|---|---|---|---|
| Seller entity ledger | Intercompany invoice or journal line | Document number and counterparty entity code | Buyer's matching entry | Seller entity's finance lead |
| Buyer entity ledger | Bill, journal or expense line | Same document number, seller's entity code | Seller's entry | Buyer entity's finance lead |
| Mapping table or spreadsheet | Account pairs and entity codes, by version | Mapping version and effective date | Every entry pair in that period | Group controller |
| Matching tool or spreadsheet | Item showing the difference, reason code, note | Match item ID | Both source postings and the fix | Group accountant |
| Approval log or email | Sign-off on the fix | Approval ID or message reference | The adjusting journal | Controller |
| Consolidation module | Period entry removing intragroup amounts | Journal reference and period | Cleared item and both postings | Group accountant or consolidation lead |
Two rows decide most outcomes. If the mapping has no version history, an old entry cannot be paired reliably. If the adjusting journal's memo omits the item ID, the reason code and the fix stop pointing at each other.
One fully joined case (Illustrative)
Illustrative and invented for this page. A fictional 520-person engineering services group charges its subsidiary for shared IT services each quarter. For the second quarter, the parent books a $42,000 charge under document SVC-118 with counterparty code E20. The subsidiary books the same invoice to an ordinary software expense account, coded as a third-party vendor, so the monthly match finds no payable.
Here is the case followed key by key:
- Document number. SVC-118 appears in both ledgers, so the reconciliation workbook can show that the subsidiary did record the invoice, just not as intercompany.
- Entity code and mapping version. Mapping version 7, effective that January, pairs the parent's service revenue account with the subsidiary's intercompany expense account. The subsidiary's entry used neither the account nor the code.
- Reconciliation item ID. Item R-0612 records the $42,000 difference and the reason code "mapping: counterparty not tagged".
- Journal reference. Correcting journal JE-4471 reclassifies the expense to the intercompany account, and its memo cites R-0612.
- Approval ID. The controller's approval references JE-4471 in the approval log.
- Elimination. The quarter's elimination picks up both sides by journal reference, and R-0612 closes as cleared.
Every step can be reached from the one before it without asking anyone. That is the test of a joined case. The same case with a free-text memo saying "fixed IC" at step 4 would still balance, but a reviewer could no longer prove which item the fix closed.
Where the keys break across ERP generations
Most groups did not keep one method for a decade, and each change can weaken a different key.
Journal method. Oracle NetSuite documents that adding an intercompany account to an advanced intercompany journal line sets its Eliminate flag automatically, while regular journal entries used for intercompany activity do not balance lines to be eliminated. A group that moved from regular to advanced journals will have earlier periods where the elimination link depended on someone's spreadsheet.
Oracle
NetSuiteOne-way switches. According to NetSuite's setup guide, a dedicated elimination subsidiary has to exist before its automated intercompany feature is turned on, and the feature stays on permanently afterwards. So the history has a hard seam: one way of pairing before the switch date and another after it, sometimes booked to an entity that did not exist earlier.
Entity structure. Acquisitions add entities with their own codes, and an ERP consolidation may renumber them. If old codes are not kept beside new ones, older entries point at entities that no longer exist in the current system. Consolidating multiple QuickBooks companies shows the same problem in smaller groups.
QuickBooksQuestions that test each join
These can be answered from a configuration screen or from memory; none needs a record to change hands.
| Join | Question for the controller | A good answer sounds like |
|---|---|---|
| Document number | "Do both entities' entries carry the same intercompany document number?" | "Yes, the bill is created from the invoice." |
| Entity code and mapping | "Where is the mapping kept, and are older versions saved?" | "In a controlled spreadsheet, one tab per year." |
| Item ID | "Does a correcting entry cite the reconciliation item it closes?" | "Yes, the memo field requires it." |
| Approval | "Where do approvals for correcting entries live?" | "In the ERP approval history since 2021; email before that." |
| Elimination | "Can you tell which entries a period's elimination cleared?" | "Yes, by journal reference." |
A run of "yes" answers suggests a deep, joinable history. "Email" and "free text" answers mark the periods where joins may need work. MCP for general ledger reconciliation covers how ledger tools expose some of these fields.
What a partner records, and what stays unknown
Write down the systems, the years each one covers, which keys exist in which period and who owns each system. Never ask for exports, mapping files, workbooks or logins.
The introduced company needs 50+ full-time employees at peak (contractors excluded), a documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Partners sign the Channel Partner Agreement before submitting introductions, and the referral brief template has a field for each system.
What stays unknown until SourceX reviews it: which entity holds rights to each record class, whether the joined history meets a buyer's needs, the de-identification required and any terms.
Next step
Refer a company. Earn up to $100,000. Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If the controller can confirm most of the five keys for several years of intercompany history, register as a partner, check the group against who qualifies and read the program terms before you introduce the group CFO.