Blog
Written by
Naman Mathur
Published on
Key Takeaways
Intercompany accounting software sits in three layers: native modules in your enterprise resource planning (ERP) system, elimination engines and close platforms that match continuously. Most close days are lost in matching.
Test intercompany reconciliation software on your own last close, known breaks included, and judge it on the match rate it reaches without new rules being written.
When matching runs continuously, breaks get resolved while they are days old and consolidation starts from agreed balances.
The usual advice to standardise policy and then buy an eliminations module fixes the last step of the process and leaves the mismatches upstream.
Most groups that set out to automate intercompany accounting buy the wrong layer first. They buy an eliminations engine, when the days are actually lost upstream in matching: two entities agreeing what they owe each other before anyone consolidates.
In the groups Stacks works with, intercompany (IC) is not a side process. Recharges, management fees, loans and shared-service costs run through every entity every month, and each line needs a counterparty that agrees. That makes the matching layer, not the elimination engine, the thing that decides when you close.
So the decision is which layer to automate first, and what to demand from the vendor. This article covers why intercompany reconciliation breaks down at month-end, what software helps automate intercompany accounting, what to look for in intercompany reconciliation software, how continuous matching differs from a month-end cleanup, and why the standard advice fails.
Why Does Intercompany Reconciliation Break Down at Month-End?
Intercompany reconciliation breaks down because the process starts after the books are nearly closed. Each local controller exports a comma-separated values (CSV) file of IC balances, emails it to group, and waits. Someone at group pastes the exports into a spreadsheet matrix of entity pairs and starts chasing the differences.
The differences have familiar causes: a UK parent books a management recharge on 30 September and the Swedish subsidiary books it on 2 October. One entity translates at the transaction-date rate and the other at month-end. One side books the charge and the other never does, or codes it to the wrong counterparty.
The arithmetic gets worse as you grow. Ten entities give you 45 possible pairs, and 40 entities give you 780, so the matrix grows much faster than the team maintaining it. Every acquisition adds entity pairs faster than it adds people, and that is where intercompany breaks at scale.
Two offsetting errors in different entity pairs can leave the matrix total at zero while the balances in both pairs are wrong. Breaks like this usually surface at consolidation, under deadline, when the only fix is a top-side adjustment nobody wants to defend to the auditor.
What Software Helps Automate Intercompany Accounting?
Three categories of software automate intercompany accounting: ERP-native intercompany modules, consolidation and elimination engines, and close and reconciliation platforms that match IC transactions continuously. They work at different points in the process, and most groups need more than one of them.
The elimination step itself is non-negotiable. Paragraph B86(c) of International Financial Reporting Standard (IFRS) 10 requires intragroup balances and transactions to be eliminated in full on consolidation. An elimination engine can only eliminate what has already been agreed, though, so it depends on clean, matched balances from the layer upstream.
Layer | What it does well | Where it stops | Best fit |
|---|---|---|---|
ERP-native intercompany module | Creates both sides of a transaction inside one ERP instance | Struggles once entities sit on different ERPs or instances | Groups on a single ERP with few entity pairs |
Consolidation and elimination engine | Posts eliminations and handles translation and group reporting | Consumes balances and assumes they already agree | Groups needing translation, eliminations and group reporting in one tool |
Close and reconciliation platform | Matches IC transactions continuously across ERPs and drafts corrective entries | Feeds the consolidation tool and does not replace it | Groups with mixed ERPs, currencies or high IC volume |
Source: Stacks implementation practice, 2026.
If your consolidation tool sits idle until day five because balances still disagree, a better consolidation tool will not move the close date. Faster matching will.
What Intercompany Automation Software Needs to Do
Whichever layer you buy, the software has to match individual transactions across every entity pair. Total balances can agree while the transactions behind them do not. Finding a difference is half the job, so the software should also pre-fill the adjustment from that difference and post it back to the ERP.
What Should Finance Teams Look for in Intercompany Reconciliation Software?
Finance teams should look for four things in intercompany reconciliation software. You need matching that holds up on your own data and live connections to every ERP in the group. You also need exception handling that drafts the fix, plus an audit trail your auditor can test.
The way to check all four is to run a demo on your own last close, including the breaks you already know about. A vendor's sample data is clean by design, while yours has the miscoded recharges and the late Norwegian accrual.
Criterion | What to test in the demo | Question to ask the vendor |
|---|---|---|
Match rate on your data | Load last month's IC transactions and count the auto-matches | What match rate do you reach without writing new rules? |
ERP connections | Post a test IC entry in each of your ERPs and see when it appears | How does each of our ERPs connect, and how often does the data refresh? |
Foreign exchange (FX) tolerance per pair | Set different tolerances for GBP–EUR and EUR–SEK pairs | Can tolerances vary by entity pair and currency? |
Timing differences | Book one side on the last day and the other on day 1 | Are timing differences reported separately from breaks? |
Probable-cause classification | Review how your known breaks are labelled | How does the system decide the probable cause? |
Corrective entries | Have the system prepare the adjustment for a one-sided booking and post it back to the ERP | Can the preparer approve their own entry? |
Audit trail | Export the log for one match from source to approval | Does every action record preparer, reviewer and timestamp? |
Scaling to new entities | Add a dummy entity during the demo | Is a new entity configuration or a services project? |
Source: Stacks implementation practice, 2026.
Match rate deserves the most scrutiny. Ask for the rate on your data with no new rules written, then ask what it was three closes later, after a subsidiary changed its invoice reference format. Rules-based matching tends to look good in the demo and decay in production, and our piece on why rules-based matching breaks explains why.
ERP coverage is the next filter. European groups rarely run one ERP. Acquisitions usually bring a different system into each local entity, so ask how each connection works, and use our guide to planning your ERP integration to test the answers.
FX handling needs a precise answer too. International Accounting Standard (IAS) 21 governs the translation of foreign currency transactions and balances, so your tolerances need to reflect your group's rate policy. The software should apply that policy automatically and report what fell outside it.
Finally, check segregation of duties: the person who drafts a corrective journal should never approve it. For groups reporting under the 2024 UK Corporate Governance Code, this matters beyond the audit. For periods starting on or after 1 January 2026, Provision 29 asks boards to declare whether their material controls are effective, and the Financial Reporting Council (FRC) has confirmed the external auditor is not required to test those controls. If IC journals are among your material controls, the board owns that declaration, so an approval step your system cannot enforce is a gap you have to close yourselves.
How Does Continuous Intercompany Matching Differ From a Month-End Cleanup?
Continuous intercompany matching agrees transactions as they are posted, while a month-end cleanup agrees balances after the period ends. The difference is when a break is found: at two days old the person who booked it remembers why, and at 30 days nobody does. Downstream, consolidation starts from balances that already agree, and audit evidence builds up during the month instead of being assembled afterwards.
Stage | Month-end cleanup | Continuous matching |
|---|---|---|
Data refresh | Monthly CSV exports per entity | Live ERP sync |
Matching timing | After period end, in a spreadsheet matrix | As transactions post |
Exceptions | One undifferentiated list of differences | Suggested matches with reasoning; FX differences flagged as the likely cause |
Corrections | Rekeyed by local controllers after email chasing | Adjustment pre-filled from the difference and posted back to the ERP |
Audit trail | Spreadsheet versions and email threads | Every action logged with preparer, reviewer and timestamp |
Source: Stacks implementation practice, 2026.
The same logic applies to the rest of the balance sheet. Teams that already run account reconciliation automation will recognise the pattern: work done during the month leaves the close for review only.
Measure three numbers before and after any change. Track unmatched IC value at day 1, working days to agree balances, and the count of breaks aged over 30 days. If a tool does not move all three within two closes, it is automating the wrong step.
Why the Standard Advice Fails
The standard advice runs like this. Standardise your IC policy, agree cut-off and rate conventions, then buy an eliminations module to automate the consolidation entries.
Policy work is worth doing, and it reduces the breaks. But a policy cannot stop a local team booking a recharge two days late or coding it to the wrong counterparty. An eliminations module then receives the same disagreeing balances it always did, and the matrix comes back the following month.
The mistake we see most often is treating rules-based matching as the fix. Rules work on the day they are written, until a subsidiary changes its invoice reference format or a new entity joins. Within a few closes the match rate drifts back down, and someone ends up maintaining rules full-time.
There is a fair counterargument. A group on one ERP instance, with a handful of entity pairs and one currency, may be well served by native ERP tools. If both sides of every transaction are created together, there is little to match.
In the closes we work on, most European groups past a dozen entities do not look like that. They have acquisitions on legacy systems, multiple currencies and recharges flowing through separate tools such as payroll, Coupa or Pleo. For them, the work that matters is preventing and resolving mismatches as they happen, then handing consolidation a set of agreed balances.
Why Choose Stacks for Intercompany Automation
Stacks builds agentic artificial intelligence (AI) for the financial close, and its intercompany automation software covers the full matching layer. It connects to your ERPs and matches IC transactions, and your team resolves and posts the fix from the same place.
Stacks reports 95%+ match rates for its AI-based matching, against its own benchmark of 70–75% for rules-based tools. Stacks shows every intercompany balance in one entity matrix and matches the underlying transactions, suggesting other likely matches with an explanation your team can accept or reject. When a difference needs an adjustment, Stacks pre-fills the entry with the difference; your team chooses the accounts and posts it back to the ERP, so the correction lives in the books. Both entities' teams work the same item in Stacks, with the transactions and evidence in view.
IC tasks sit on the same close management workflow as the rest of your close. Stacks' security certifications include SOC 2 Type II and ISO 27001:2022. Bring your ERP mix to the walkthrough and we'll show you how Stacks connects to it.
In our intercompany masterclass, Sara Scott, Group Accounting Lead at Bloom & Wild, explains why her team rethought intercompany and what they expect to change, alongside a live demo of the matrix.
FAQs for Intercompany Accounting Software
What is the difference between intercompany matching and elimination?
Matching agrees both sides of each IC transaction between entities during the period. Elimination removes the agreed balances when the group prepares consolidated accounts under IFRS 10, so elimination is only as good as the matching before it.
Can Xero or QuickBooks handle intercompany transactions?
Groups on Xero or QuickBooks usually set up one organisation per entity, then handle both sides of IC transactions and eliminations manually or through add-ons. That holds up for a few entities and breaks down as pairs multiply.
How much time can intercompany automation save during the close?
It saves most of the working days you spend agreeing IC balances after period end, because continuous matching removes that phase rather than shortening it. Groups still matching in spreadsheets across several ERPs and currencies gain the most.
How does intercompany reconciliation software handle multiple ERPs and currencies?
Good software brings every ERP's IC data into one place and matches across them, applying FX tolerances per entity pair and currency. Ask vendors to demonstrate this on two of your own ERPs using live data.
See How Stacks Maps to Your Close Process
Book a 30-minute walkthrough. We'll discuss your close process, show you which tasks run automatically, and outline the next step from there.
