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.
Why Multi-Entity Trial Balance Reconciliation Is a Different Problem
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.
The Usual Suspects: Why Entity-Level Trial Balances Don't Tie Out
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-by-Step: Reconciling Trial Balances Across Entities
- Build and maintain a group chart of accounts mapping table. Every local account, in every ERP, needs a documented mapping to its group-level equivalent. This is the single most important control in the whole process, and it's usually the one teams let go stale first.
- Extract entity-level trial balances on a common cut-off date. All entities need to pull their trial balance as of the same date and time, not "end of business, whenever that happens to fall locally."
- Translate to a common currency using a consistent rate. Apply the same exchange rate source and date across every entity for the period, rather than letting each subsidiary apply its own.
- Match intercompany balances between counterparties before eliminating anything. Confirm that Entity A's intercompany payable actually equals Entity B's intercompany receivable. Fix the difference first; eliminate second.
- Apply elimination entries. Once intercompany balances tie out, eliminate them so the consolidated trial balance reflects only transactions with external parties.
- Reconcile the consolidated trial balance back to each entity's own trial balance. This last step confirms nothing was dropped, duplicated, or mis-mapped along the way.
| 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 |
A Worked Example
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.
Where This Breaks Down at Scale
The process above works fine on a whiteboard. In practice, three things tend to erode it as a group grows:
- Mapping tables live in spreadsheets that nobody owns. New accounts get added locally, and the mapping table doesn't get updated until someone notices a number that doesn't reconcile, usually during close, under time pressure.
- Currency translation happens manually, often in Excel, which means the "consistent rate" step is only as reliable as whoever remembered to update the lookup that month.
- Nobody sees a break until month-end. Without ongoing visibility into entity-level balances between closes, small mismatches accumulate quietly and surface all at once when the group trial balance is due.
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."
How Aico Supports Multi-Entity Trial Balance Reconciliation
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:
- Account Reconciliation ties entity-level balances to supporting evidence, so a balance that ties out mathematically is also confirmed against source documentation, not just assumed correct.
- Journal Entries are validated against live ERP data as they're posted, which cuts down on the late manual corrections that throw one entity's trial balance out of step with another's.
- Variance Monitor flags unexpected movements at the account level in real time, so a mismatch surfaces while there's still time to fix it, not during the final push to close.
- Closing Task Manager keeps every entity working to the same cut-off date and the same checklist, which removes one of the most common causes of a break before it ever happens.
Book a demo to see how live ERP integration changes the way a multi-entity close actually runs.
FAQs
What's the difference between trial balance reconciliation and intercompany reconciliation?
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.
How do you reconcile trial balances when entities use different ERPs?
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.
What causes a consolidated trial balance to be out of balance?
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.
How often should multi-entity trial balances be reconciled?
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.
Can this be automated, or does it require manual mapping every period?
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.