)
)
An M&A deal closes and Day 1 is declared a success. Post-merger finance integration then begins in earnest.
Two entities, each with its own chart of accounts and close cycle, have to become one consolidated reporting structure. The Group CFO owns the reporting risk while controllers carry the reconciliation burden, often across systems they’ve never seen while running their own entity close at the same time.
The timeline for resolving this is determined by the architecture of the finance systems on both sides. Acquirers operating with fragmented, multi-entity finance estates tend to discover this challenge later than the integration plan anticipated.
Finance integration is where deal value holds or starts to slip
M&A timelines reduce in the run-up to close. Due diligence assesses the target’s financial health and the deal model projects synergies. What integration plans frequently underestimate is how long it takes to produce a consolidated, board-ready financial picture of the combined entity. They also underestimate the cost in reporting delay, close effort, and the synergy-tracking uncertainty of operating without one.
In the interim, leadership makes decisions on unreconciled data from entities that haven’t yet been brought into a common reporting structure. The board receives group reports that have been consolidated manually by teams carrying their day-to-day close responsibilities on top of the integration workload. Every reporting period without a reconciled combined view is a period where the synergies the deal was structured to deliver are harder to evidence to the board.
For PE-backed businesses, this plays out at both ends of the hold period. In the early months, the inability to see consolidated margin and entity-level contribution delays the operating decisions the investment proposal depends on. At exit, a fragmented finance architecture introduces uncertainty that can show up in diligence conditions and the depth of scrutiny an acquirer applies.
Why finance integration takes as long as it does
The common explanation is systems complexity that comprises different platforms and processes. However, that explanation describes only the surface. The structural cause, in complex multi-entity acquisitions, is that finance systems consolidation after acquisition requires the acquired entity’s financial data to be mapped and restructured before it can be consolidated.
Charts of accounts need mapping to a common structure, close calendars need sequencing, and intercompany positions, which by definition span both entities, need reconciling across systems built around separate general ledger models. Manual journals and consolidation adjustments bridge the reporting gap while the systems work proceeds.
In an aggregate-first architecture, each of those bridging steps generates additional reconciliation work. This includes exception review, mapping checks, intercompany matching, and sign-off that accumulates because both ledgers hold period summaries. Consolidating them requires reconstructing the underlying transactions and mapping them to a common structure before the result can be posted. For complex acquisitions, that process typically runs well into the first year and beyond in multi-entity ERP environments.
During that window, the finance function carries a structural overhead. The overhead exists because the architecture defers reconciliation work to a point where timing differences, mapping mismatches, and incomplete postings are already embedded in period-end summaries.
Where the intercompany problem becomes visible
For businesses that have grown through acquisition, like PE roll-ups and multi-entity corporates managing consolidated group accounts, intercompany reconciliation automation is where the architectural gap shows up most clearly. It’s also where the manual overhead accumulates fastest without the right architecture in place.
Intercompany transactions have to be matched and eliminated at consolidation. Entities close on their own calendars, posting intercompany balances that then must be matched against their counterparts across the group. Elimination entries follow, and consolidated accounts are produced from there. Mismatches that breach materiality thresholds delay the group close. The time spent resolving those mismatches becomes a recurring overhead which grows as intercompany relationships become more complex, with transaction volume, ownership structure, and elimination requirements all adding to the workload.
The manual process that fills this gap requires dedicated resource and review layers that grow with group complexity.
When intercompany positions are matched as transactions occur, eliminations can be handled progressively through the period. By the time the consolidated close begins, a substantial portion of the intercompany work has already been completed and reviewed. What remains is validation, exceptions, and final sign-off. For a business with many entities and a long consolidated close cycle, the architecture is a significant contributor to that cycle length.
What due diligence surfaces in a fragmented finance stack
Diligence is where finance architecture becomes a valuation question.
An acquirer’s due diligence team wants transaction-level financial data that is auditable and traceable. It wants to understand revenue quality by entity and the intercompany positions that can inflate reported EBITDA when not properly eliminated. In a fragmented architecture, with spreadsheet-led consolidation and manually assembled group accounts across multiple ERPs, assembling that picture takes longer and relies on more interpretation. The diligence team ends up validating the numbers rather than working from them directly.
The uncertainty this introduces can show up in diligence conditions and extended scrutiny, both of which cost the seller deal momentum and resources. A business with a consolidated finance architecture – one that can produce entity-level and group-level financials from the same data model, with transaction-level lineage accessible without manual reconstruction – reduces that friction considerably. Because the audit trail is complete and accessible, the numbers are easier to stand behind under pressure.
The architecture decision that shapes integration speed
The timeline for finance integration is influenced by the architecture of the acquiring entity’s finance stack. Specifically, whether it can absorb a new entity without a full systems replacement on both sides.
In a composable finance architecture – the design principle behind a modern multi-entity finance platform – a new entity can be onboarded to a common data model without replacing its operational ERP. The entity’s transactions flow into an event-level processing layer shared across the group, with the mapping, controls setup, and connector work that onboarding requires. Intercompany positions are reconciled progressively as the integration proceeds. Entity-level reporting becomes available before full systems integration is complete, because the consolidation layer sits above individual ERP systems and doesn’t wait for them to be unified.
The mapping, controls, and implementation work that any acquisition requires still applies. The difference is where the reporting dependency sits. Finance can begin reporting on the combined entity as onboarding advances, with the picture building progressively rather than being held back until systems work is complete.
For PE sponsors with short value-creation windows, synergy visibility comes earlier in the hold period. The operating model of the combined entity becomes clearer sooner, and continuous group reporting becomes available progressively as onboarding advances, rather than being held back until full systems integration is complete. At exit, a finance architecture that has already absorbed the integration work presents the combined entity’s financials as traceable and auditable at entity level. The result is reduced preparation burden on the finance team and reduced interpretation burden on the acquirer’s diligence team.
When the new system reproduces the old problem
Many M&A finance integration programs treat systems work and financial reporting as parallel tracks. While integration proceeds, reporting teams either bridge the gap manually or use interim consolidation tooling. As an operational response to a structural problem, it’s reasonable. But issues start to surface when the integration completes and the consolidated architecture carries the same design as the one it replaced. It performs aggregate-first processing, batch-oriented close, and reconciliation is handled downstream. The manual bridging stops and the structural overhead, made up of investigation work, manual journals, and the period-end reconciliation sprint, continues inside the new system. The architecture is different; the workload is not.
The ERP Illusion examines why finance transformation after M&A so often reproduces the same constraints in a newer system, and what the sequence looks like when architecture decisions come before system selection. For finance leaders managing an active integration, evaluating a target’s finance architecture, or carrying the operational burden of a partially consolidated group, the eBook sets out the diagnostic and the alternative sequence in full.
)
