Reconciling a trial balance for a single company is a fairly mechanical exercise. Pull the ledger, check that debits equal credits, move on. It's a different exercise entirely once you're running ten, thirty, or a hundred subsidiaries across SAP, Oracle, and Dynamics 365, each closing on its own schedule with its own version of the chart of accounts.
That's the version of this problem most enterprise finance teams actually deal with, and it's rarely about arithmetic. It's about getting entity-level data that's consistent enough to consolidate in the first place. This guide covers why that's harder than it looks, the usual causes of a break, and a practical process for tracking one down before it delays your close.
One note before we go further: this article is about reconciling entity-level trial balances so they can be consolidated. If you're looking for how to match individual intercompany transactions like loans, cost allocations, or invoices between two affiliated companies, our piece on intercompany account reconciliation covers that side of the process in more depth.
A trial balance for a single entity is a closed system. Every transaction lives in one general ledger, on one chart of accounts, and if the debits and credits don't match, the cause is somewhere in that one ledger.
Once you're consolidating multiple entities, you're no longer just checking that one system adds up correctly. You're checking that several systems, often on different platforms, are speaking the same financial language before you can combine them into a group number. A subsidiary's trial balance can be perfectly balanced on its own terms and still be unusable at group level, because the account mapping doesn't line up with the parent company's structure, or because it was extracted on a different date than everyone else's.
This is the part that catches finance teams out. The trial balance itself isn't the hard part. Getting to a trial balance you can actually trust across entities is.
A handful of causes show up again and again when a consolidated trial balance won't reconcile cleanly.
Inconsistent charts of accounts. A subsidiary acquired five years ago may still be running its own numbering convention, so "Accrued Wages" in one entity maps to a different account number, or a completely different account entirely, than the equivalent line in the parent's structure. Without a solid mapping table, this shows up as balances that seem to vanish or double up at consolidation.
Foreign exchange timing. Two entities converting the same intercompany balance at slightly different exchange rates, or on different dates, will produce a gap that has nothing to do with an actual accounting error. It looks like a break. It's really a translation mismatch.
Different close calendars. Not every subsidiary closes on the same day, especially where local statutory requirements differ from group reporting deadlines. A trial balance pulled a few days apart from another entity's can include transactions one side hasn't recorded yet.
Unmatched intercompany balances. One entity's intercompany receivable should equal another entity's intercompany payable for the same transaction. When they don't, it's usually because one side posted a journal entry the other side hasn't recorded, or because an intercompany invoice was raised in one system without a corresponding entry on the other end.
Local GAAP adjustments. An entity's statutory books might include adjustments required by local regulation that haven't yet been reflected, or need to be reversed, for group reporting purposes.
Late manual entries. Someone posts a correcting journal in one entity's ERP after the trial balance has already been extracted elsewhere, and now the two versions are out of step without anyone noticing until consolidation.
None of these are exotic. They're the predictable cost of running finance across more than one system, and the fix isn't cleverness, it's a process that catches them early.
| Step | Typical owner | Most common failure point |
|---|---|---|
| Mapping table | Group controller | Table not updated after new accounts are added locally |
| Common cut-off extract | Local finance teams | Entities pull data on different dates |
| Currency translation | Group reporting team | Inconsistent rate source across entities |
| Intercompany matching | Local + group finance | One side posts a correction the other side misses |
| Eliminations | Group controller | Applied before intercompany balances actually tie out |
| Final reconciliation | Group controller | Skipped under time pressure, errors carried forward |
Say a UK parent company has two subsidiaries: a German entity running SAP and a US entity running Dynamics 365. Both report an intercompany loan between them.
| German entity (EUR) | US entity (USD) | Consolidated (GBP) | |
|---|---|---|---|
| Intercompany receivable / payable | €50,000 payable | $54,000 receivable | Should net to zero after translation |
| Rate applied | Month-end spot rate | Rate as of invoice date | Mismatch |
At month-end spot rate, €50,000 converts to roughly £43,000. But the US entity translated its $54,000 receivable using the rate from the original invoice date, several weeks earlier, converting to a slightly different sterling figure. Neither entity's own trial balance is wrong on its own terms. The group-level reconciliation still shows a break, because the two sides of the same transaction were translated inconsistently.
The fix here isn't a journal entry. It's agreeing, before the close even starts, which rate source and date both entities will use for intercompany balances, and holding both to it.
The process above works fine on a whiteboard. In practice, three things tend to erode it as a group grows:
This is usually where teams start looking at account monitoring and variance monitoring tools that flag entity-level movements as they happen, rather than waiting for the trial balance to expose them at the worst possible moment. It's also where a structured closing task manager earns its keep, by making sure every entity actually extracts its trial balance on the agreed cut-off date instead of "whenever local finance gets to it."
Aico connects live to SAP, Oracle, and Dynamics 365, so entity-level data comes from the same source systems your local teams already work in, rather than a separate extract that's already a few days stale by the time anyone looks at it. That matters most in exactly the scenario described above: getting a consistent, same-day view across entities before translation and elimination even begin.
From there:
Book a demo to see how live ERP integration changes the way a multi-entity close actually runs.
Trial balance reconciliation confirms that entity-level ledger data is consistent and consolidation-ready across the group. Intercompany reconciliation is the more granular process of matching individual transactions, like loans, invoices, or cost allocations, between two affiliated entities. You need both, and intercompany matching is usually a prerequisite step before trial balances will tie out cleanly at group level.
Start with a documented account mapping table so each local account has a clear group-level equivalent, extract all entity trial balances on the same cut-off date, and apply a consistent currency translation rate across every entity before comparing balances. Live ERP integration removes a lot of the manual extract work, since entity data is pulled directly from source systems rather than staged exports.
The most common causes are inconsistent account mappings between entities, intercompany balances that don't match on both sides, currency translations applied using different rates or dates, and manual journal entries posted after the trial balance was already extracted in another entity's system.
At minimum, every reporting period before consolidation, whether that's monthly, quarterly, or annually. Groups running a tighter close cycle often reconcile continuously, catching entity-level breaks as they occur rather than waiting for a single reconciliation event at period-end.
The account mapping table itself needs to be maintained as accounts change, but the extraction, translation, and matching steps around it can be automated through live ERP integration and reconciliation software, which removes most of the manual spreadsheet work and gives finance teams visibility into breaks well before month-end.