An ERP handles intercompany transactions well when it posts both sides of every sale, loan or recharge as a linked pair, tags each posting with its counterparty, matches the two sides before close, and removes the balances and unrealised profit in a visible elimination step. Weak setups rely on spreadsheets for matching and eliminations.
This guide is for CFOs, VPs of finance and controllers who run or are about to run several legal entities. It covers the mechanics inside the ERP and gives you a way to test any vendor, packaged or custom, against the same criteria. It is deliberately different from our wider multi-entity ERP governance guide, which covers shared master data, controls and sequencing. Here the subject is narrower: the transaction types, the matching problem, the failure modes and the evaluation questions. For a custom build, see enterprise ERP development.
This is general practice, not tax or accounting advice. Confirm the treatment of intercompany items with your auditor and tax adviser.
Key takeaways
- Every intercompany transaction creates two entries in two ledgers. The ERP's job is to make sure they always agree, or to flag the difference.
- Sales, loans and recharges behave differently. A goods sale can leave unrealised profit in stock, a loan carries interest and often a currency exposure, and a recharge needs an allocation basis.
- Matching before close, by entity pair and in each currency, removes most consolidation pain.
- Eliminations should be visible, reversible entries, not spreadsheet overrides.
- When you compare vendors, ask how each handles mirrored entries, unmatched items, currency differences and audit trails, and ask for a demonstration with your own entity structure.
What counts as an intercompany transaction?
An intercompany transaction is any sale, charge, loan, transfer or settlement between two legal entities in the same group. Each entity records its own side in its own books. The group removes both sides when it consolidates, because a group cannot earn revenue from itself or owe itself money.
| Type | Typical example | What makes it tricky |
|---|
| Goods sale | Manufacturing entity sells to a distribution entity | Margin stays in stock until the buyer sells externally |
| Service or recharge | Head office charges shared IT, finance or management services | Needs an allocation basis and often tax review |
| Loan or funding | Parent lends to a subsidiary, with interest | Interest, currency exposure and classification |
| Dividend or capital movement | Subsidiary pays a dividend to the parent | Subsidiary reduces equity; parent books dividend income; both removed on consolidation |
| Settlement | Cash or netting between entities | Matching to the original items |
Treat each type as its own posting pattern in the ERP. One generic "intercompany invoice" template is the usual reason the later steps fall apart.
How should an ERP post mirrored entries?
The ERP should create the counterparty entity's entry from the originating entity's document, or at least force the two to be linked and matched. The originating entity posts a receivable and revenue; the receiving entity posts an expense or asset and a payable. Both postings carry the counterparty tag and a shared reference.
There are three common designs, from weakest to strongest: independent entry, where each entity keys its own side and differences are chased by email at month-end; linked documents, where the receiving entity must accept the sender's document so both sides share a reference; and automatic mirror, where the ERP creates the receiving side at once and a person reviews exceptions. The third is fastest but needs good rules for accounts and tax codes, and a way for the receiving entity to reject a charge it does not recognise.
How are intercompany loans and recharges different from sales?
Loans and recharges need their own rules because they accrue over time and depend on agreements. A loan needs a principal schedule, an interest rate or basis, an accrual run each period, and a clear currency. A recharge needs a documented allocation key (headcount, revenue, usage) and an owner who approves the allocation before it posts.
- Loans. Interest should accrue automatically on both sides with the same counterparty tag, and a loan in a currency other than the borrower's functional currency is revalued at each close.
- Recharges. Store the allocation key and the period it covers, and show why it changed.
- Both. Pricing and withholding are tax matters for your adviser; the ERP applies the agreed terms consistently and keeps the evidence.
How do currency differences arise, and who carries them?
Currency differences arise when the two entities record in different currencies, or when an invoice is raised in a currency that is not the functional currency of one party. The invoice date rate and the closing rate differ, so the open balance in one entity's books moves while the other side, held in the invoiced currency, does not.
In general practice the entity whose functional currency differs from the invoice currency remeasures its monetary balance and records the difference in profit or loss. On consolidation, accounting standards such as IAS 21 and ASC 830 address how these differences are treated, including exceptions for balances that form part of a net investment in a foreign operation. Do not assume that the difference vanishes in consolidation. Ask your auditor which treatment applies to each balance type.
For the ERP, the requirement is practical: hold the transaction currency, the entity currency and the group currency on each posting, revalue open balances by rule, and keep revaluation entries separate from the original postings.
How does matching work before close?
Matching compares the receivable in one entity with the payable in the other, by entity pair and by currency, and lists every difference. Differences usually come from timing, wrong accounts, tax treatment, missing invoices or a different rate. A good ERP shows unmatched items as a worklist with ageing, not as a total that does not tie.
A practical matching routine:
- Run the intercompany balance report by entity pair in transaction currency.
- Compare the two sides and classify each difference: timing, error, dispute or currency.
- Correct at source in the entity that is wrong, not in the consolidation.
- Re-run until the unexplained difference is below the group tolerance.
- Lock intercompany postings for the period.
Worked example: a goods sale, a recharge and a timing difference
All figures are illustrative and are not tax or accounting advice.
Setup. Entity A is a US manufacturer keeping books in USD. Entity B is a German distributor keeping books in EUR. The group reports in USD. In the month, A sells goods to B for USD 88,000. A's cost of those goods is USD 66,000, so A's margin is USD 22,000. B is invoiced in USD. At invoice date 1 EUR = 1.10 USD, so B records EUR 80,000. By month-end B has sold 75 percent of the goods to external customers and holds 25 percent in stock.
Step 1: both sides post.
| Entity | Entry | Amount |
|---|
| A | Debit intercompany receivable from B; credit intercompany revenue | USD 88,000 |
| A | Debit cost of sales; credit inventory | USD 66,000 |
| B | Debit inventory; credit intercompany payable to A | EUR 80,000 |
Step 2: B remeasures the payable. At month-end 1 EUR = 1.12 USD. B owes USD 88,000, now EUR 78,571.43, so B records a currency gain of EUR 1,428.57. A has no currency effect.
Step 3: matching. In USD, A's receivable is 88,000. B's payable translated at the closing rate is EUR 78,571.43 multiplied by 1.12, which is USD 88,000. The sides agree.
Step 4: a recharge in transit. A also invoiced B for a shared service recharge of USD 12,000 on the last day of the month. B's accounts team keyed it on the third of the next month. At month-end A shows a USD 12,000 receivable that B does not show as a payable. The matching report flags it, and B posts an accrual so the period is complete. This is a timing difference, not an error, but only the matching step makes it visible.
Step 5: eliminations. B holds 25 percent of the goods, so the unrealised profit is 25 percent of USD 22,000, which is USD 5,500. The elimination entries are:
| Elimination | Amount |
|---|
| Debit intercompany revenue (A) | USD 88,000 |
| Credit cost of sales (consolidated) | USD 82,500 |
| Credit inventory (unrealised profit) | USD 5,500 |
| Debit intercompany payable (B) | USD 88,000 |
| Credit intercompany receivable (A) | USD 88,000 |
Check. The group bought goods at 66,000 and sold 75 percent externally, so group cost of sales should be 49,500 and group stock 16,500. Entity cost of sales is 66,000 in A plus 66,000 in B (75 percent of 88,000), a total of 132,000; removing 82,500 leaves 49,500. B's stock is 22,000 (25 percent of 88,000); removing 5,500 leaves 16,500. Both tie. The recharge is eliminated the same way once both sides are posted. These entries do not remove B's currency gain; how it is presented in the group accounts is a point to confirm with your auditor. Deferred tax on the eliminated profit is ignored here; confirm it with your tax adviser.
What are the common failure modes?
Six failure modes recur in intercompany processing, and each shows up as a recognisable symptom at month-end. The table below pairs every failure mode with what you see in the close and the standard fix, so you can use it as a review checklist for your current process or for any vendor demonstration.
| Failure mode | What you see | Fix |
|---|
| Different accounts used for the same item | Balances never tie by entity pair | Dedicated intercompany accounts with counterparty tag |
| Timing gaps | Receivable with no payable at close | Cut-off rule and in-transit accrual |
| Rate mismatch | Small residual differences every month | One rate table, one rate type per posting class |
| Manual spreadsheet eliminations | Unexplained overrides at group level | Eliminations posted as ledger entries with an owner |
| Unrealised profit ignored | Group profit overstated while stock is held | Stock-in-hand report by seller and margin |
| One user posts both sides | Weak segregation of duties | Approval by the receiving entity |
How do you evaluate how a vendor handles this?
Ask every vendor, packaged or custom, to demonstrate the same scenario with your entity structure. Do not accept a slide. The aim is a criteria-based comparison, not a ranking. The test is whether both sides, the matching and the elimination can be shown on your own entity pairs, in your currencies, with a reversible audit trail.
| Question | What a good answer shows |
|---|
| Is the counterparty entity required on every intercompany posting? | A mandatory field, with a validated list |
| Are both sides created automatically or linked? | Mirrored or linked documents, with a reject option |
| Can I see unmatched items by pair and currency? | A live worklist with ageing |
| How are currency differences stored and revalued? | Separate entries, three currencies on each line |
| How are eliminations produced? | Rule-driven journals, reversible, with an audit trail |
| Can eliminations be run for a trial consolidation mid-month? | Yes, without posting to the ledger |
| How is unrealised profit in stock found? | A report by seller, buyer and margin |
| Who can post and who approves? | Role rules per entity |
Check each vendor's current documentation; this guide does not describe any named product.
The time and effort depend on drivers, not on a standard figure, because any figure would describe someone else's scope. Any schedule has to be set from your own requirements. Scope the drivers below first, then ask each vendor or team to estimate from that list.
- Number of entity pairs with open balances, and the number of currencies per pair.
- Chart of accounts differences between the two source systems and the target.
- Open items versus balances only. Migrating only the net balance per pair is simpler; migrating open items allows matching to continue.
- Quality of the existing matching. If balances do not tie today, the work includes cleaning them first.
- Elimination logic. Rules held in spreadsheets must be documented and rebuilt.
- Period alignment. Migrating at a period end is simpler than mid-year.
- Number of trial loads and reconciliation rounds the auditors want to see.
Trial loads and reconciliation in general are covered on our ERP data migration services page, and the scope decision is in our guide on what to migrate into a new ERP.
When should a finance team upgrade its ERP for intercompany reasons?
Upgrade when intercompany matching and eliminations take days of spreadsheet work each close, differences are explained by email, or an auditor asks for evidence you cannot reproduce. If you have two entities, one currency and a handful of invoices a month, a dimension in your current ledger may be enough.
Our signs you need a new ERP guide covers the wider test.
When this is the wrong approach
A full intercompany engine is the wrong investment if the group has a single legal entity with branches, if intercompany volume is a few items a quarter, or if the real problem is poor master data. In those cases, branch dimensions and a disciplined month-end checklist cost less and fix the actual cause. If the main issue is an ageing system that cannot support new entities, start with the legacy software modernization assessment instead, then return to this design.
Glossary: intercompany, between two legal entities of the same group; elimination, the consolidation entry that removes intercompany balances and transactions; unrealised profit, margin on goods sold within the group that are still held in stock; functional currency, the main currency an entity operates in; counterparty tag, a field that records the other entity on a posting.
How Timeline Digital approaches this work
For a group with several legal entities, Timeline Digital starts by mapping your entity pairs, currencies and elimination rules in the Plan step, and the schedule is set from those requirements. Timeline Digital is a custom software development company founded in 2013 and headquartered in Islamabad, Pakistan, delivering remotely. A free pilot of 2 to 3 key modules lets your team test the result before the final agreement. Controls are designed to support your audit needs and confirmed per project, and code ownership passes on full payment.