Every consolidation discussion starts in the wrong place. People talk about elimination rules, translation methods, and consolidation software. These matter. But they are the last ten per cent of the problem. The first ninety per cent is getting the data into a state where consolidation is even possible.
A group with five entities across three countries, each running a different ERP system, does not have a consolidation problem. It has a data standardisation problem. The consolidated P&L is only as trustworthy as the infrastructure that feeds it.
Four Layers Between Raw Data and Trusted Numbers
The infrastructure that makes consolidated financials trustworthy has four distinct components. Skip any one of them and the output breaks — not obviously, not immediately, but in ways that surface during audits, investor due diligence, or the one board meeting where the numbers actually matter.
Chart of Accounts Mapping
This is where consolidation lives or dies.
Entity A uses a four-digit account code structure designed by its local accountant in Bratislava. Entity B uses a six-digit structure from a Helios implementation in Prague. Entity C was acquired last year and inherited a Comarch chart in Warsaw. Before a single number can be consolidated, every account in every entity must map to a single group-level structure.
The mapping table is not a one-time exercise. New accounts are created. Entities are added. Local requirements change. The mapping must be maintained, reviewed, and updated every period. Treat it as a static document and within six months the consolidated P&L has line items that mean different things depending on which entity posted the transaction.
A well-maintained chart of accounts mapping eliminates the majority of consolidation friction before any reporting tool is involved. This is not a technology task. It is a governance task — someone must own the mapping, enforce compliance, and review exceptions.
Currency Normalization
A group reporting in euros with subsidiaries in Czech koruna and Polish zloty needs translation rules that are consistent, documented, and applied correctly every period.
The rules themselves are straightforward. Balance sheet items at the closing rate. Profit and loss items at the average rate for the period. Equity at the historical rate. Dividend payments at the rate on the date of declaration. Where it breaks is in the details: which average rate — monthly average, quarterly average, or period-to-date? What happens when an entity changes its functional currency? How are unrealised FX gains on intercompany loans treated?
Getting this wrong does not create a rounding difference. It creates a translation reserve in equity that grows over time and that nobody can explain. Auditors flag it. Investors question it. Management ignores it until they cannot.
The fix is not a better FX feed. It is a documented currency policy applied consistently across every entity, every period, with rate sources and rounding rules defined once and enforced automatically.
Intercompany Tagging and Reconciliation
When Entity A sells goods to Entity B, the revenue in A and the cost of goods in B must eliminate on consolidation. In theory, both sides record the same amount on the same date with the same reference. In practice, they almost never do.
Industry research consistently shows that the vast majority of multinational organisations experience operational difficulties with intercompany reconciliation. Over half still perform intercompany eliminations manually. The most common problems: timing differences between when each entity records the transaction, currency conversion applied at different rates, different posting dates, and simple coding errors where one side forgets the counterparty tag.
The solution is not better elimination logic at month-end. By then the errors have already compounded. The solution is a discipline enforced during the period: every intercompany transaction gets a counterparty entity code. Every transaction gets a matching reference. Unreconciled differences above a defined threshold are escalated before close — not discovered during consolidation.
Half of organisations cite lack of defined ownership as a major challenge for intercompany processes, according to Deloitte. Someone must own the matching. Someone must chase the exceptions. Someone must ensure both sides agree before the books close. This is not software configuration. It is operational governance.
Validation Gates
This is the most underinvested layer. Validation gates are automated checks that run before the consolidation engine processes the data. They catch errors upstream, when they are cheap to fix, rather than downstream, when they have already contaminated the consolidated output.
A minimum viable set of validation gates for mid-market group reporting:
Does every entity’s trial balance balance to zero? Does every intercompany position net to zero within tolerance? Are all required accounts mapped to the group chart? Has every entity submitted data for the period? Are there any accounts with balances but no mapping? Do currency rates exist for all entity currencies for the period?
These checks take seconds to run and prevent hours of investigation after the fact. Without them, the consolidation process becomes a detective exercise: the numbers do not tie, and nobody knows which entity, which account, or which period is the source of the problem.
Companies with mature consolidation processes report close cycle reductions of fifty to seventy per cent, according to the Hackett Group. The reduction does not come from faster elimination logic. It comes from fewer errors entering the consolidation in the first place.
Where This Goes Wrong
Three patterns recur in mid-market groups that attempt consolidation without proper infrastructure.
Starting with the tool, not the data model. A group buys consolidation software and expects it to solve the problem. The software assumes standardised data inputs. The group does not have standardised data inputs. The implementation stalls at the mapping phase, which was not budgeted or planned for because it was assumed to be trivial. It is not trivial. It is the core of the problem.
Annual cleanup instead of monthly discipline. The external auditor flags intercompany differences once a year. The finance team spends two weeks reconciling. By the next year-end, the same differences have reappeared. The root cause — lack of period-by-period matching — is never addressed because the annual cleanup is treated as the process rather than as evidence that the process is broken.
Distributed responsibility with no accountability. Each entity’s local accountant is responsible for their own books. Nobody is responsible for the group-level data model. Nobody owns the mapping table. Nobody reviews intercompany matching. The result: five locally correct sets of books that are collectively unintelligible when combined.
What Good Infrastructure Produces
A group with proper consolidation infrastructure does not spend the first week of each month fixing data. The mapping tables are maintained. The currency policy is documented and applied automatically. Intercompany positions are matched during the period. Validation gates catch exceptions before consolidation runs.
The consolidated P&L, balance sheet, and cash flow are available within days of the last entity closing — not weeks, not months. The numbers are auditable. The CEO can see the group position and make decisions based on data that is less than two weeks old.
This is not a technology outcome. It is a governance outcome. The technology matters, but it matters less than the discipline of maintaining mappings, enforcing intercompany rules, and running validation checks every period.
The infrastructure is invisible when it works. Nobody notices that the chart of accounts mapped correctly or that the intercompany positions netted to zero. What they notice is that the group numbers arrived on time, that they tied to the entity numbers, and that nobody had to stay until two in the morning reconciling differences that should not have existed in the first place.