The acquisitions made when money was cheap are now being asked to justify themselves. Deals that closed in 2021 and 2022 were signed on synergy numbers, and the integration work that would have produced them was deferred while the businesses were left to run as they were. That deferral is expiring. ERP consolidation after an acquisition spree is appearing on capital plans this quarter not because anyone has become enthusiastic about systems integration, but because the promised savings have a due date and the only way to reach them runs through the estate.
You do not consolidate systems. You consolidate decisions, and the system is only where the decision becomes visible
Every consolidation argument that presents itself as technical is actually an argument about who decides pricing, who approves credit, how revenue is recognised and whose month-end calendar governs. The software is where those disagreements become undeniable, which is why the programme feels harder than the architecture diagram suggested.
Four postures, and you should name the one you are in
Absorb. Migrate the acquired business onto the parent instance. Cheapest to run, most expensive to do, and only sensible where the operating models genuinely resemble each other. Coexist. Leave the systems alone and integrate at the consolidation and reporting layer. Fast, low risk, and quietly accumulates cost in every subsequent change. Replatform both. Use the acquisition as the reason to replace everything. Occasionally correct, usually a way of attaching a discretionary programme to a mandatory one, and the schedule risk of the two combined is not additive but multiplicative. Keep it separate deliberately. Because you intend to sell it, or because it is a genuinely different business. Nobody writes this down, and it is frequently the right answer. An asset you plan to divest in three years should not be woven into the group's master data. The cost of not choosing is that you end up in coexistence by accident and describe it afterwards as strategy.
| Posture | Approach | Main consideration |
|---|---|---|
| Absorb | Move the acquired business onto the parent instance | Use when the operating models genuinely resemble each other |
| Coexist | Retain systems and integrate consolidation and reporting | Fast and low risk initially; subsequent changes accumulate integration work |
| Replatform both | Replace both estates | Can combine a mandatory integration with a discretionary replacement and increase schedule risk |
| Keep separate deliberately | Preserve a distinct estate | Relevant to a different operating model or planned divestment |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
The test is process divergence, not system size
The instinct is to decide by scale — the small one moves onto the big one. The better test is how differently the acquired business actually operates. If it sells through different channels, prices on a different basis, recognises revenue differently or carries a materially different working capital cycle, absorbing it into your instance means changing how it trades. That may be exactly what you bought it to stop doing, or it may destroy the thing you paid for. Either way, it is a commercial decision that should not be made by an integration workstream. The workable ordering is to consolidate the ledger early and the operations late. Get one chart of accounts, one consolidation, one set of statutory outputs. Leave order-to-cash alone until someone can articulate, commercially, why convergence is worth the disruption.
Sequence, and most programmes invert it
Chart of accounts first. Then legal entity and intercompany structure. Then master data — customers, vendors, items, employees. Then transactional processes. Then reporting. Reporting is where the visible pain is, so that is where programmes start, and they end up building reconciliations on top of foundations that are about to move. Every hour spent harmonising a report before the chart of accounts is settled is an hour spent twice.
The synergy number and who owns it
Licence consolidation savings are real and small. The numbers in the deal model were almost never software; they were finance, procurement and shared services headcount, and those only arrive if the underlying processes actually converge. The structural failure is that the deal model was built by corporate development and the integration plan is built by IT, and no single person is accountable for reconciling them. Before the programme starts, put the deal's synergy line and the integration plan side by side and identify, item by item, which system change produces which saving. The items with no matching change are not savings. They are assumptions.
Practical Guidance for Systems Consolidation Roadmap
- Name the posture — absorb, coexist, replatform or hold separate.
- Decide by process divergence, not by which system is larger.
- Consolidate the ledger early, the operations late, never the reverse.
- Map every synergy line to a specific system change or delete it.
- Appoint one owner with authority over both sides of the deal.
- Fix day-one obligations first: statutory filing, payroll, access, consolidation.
- Freeze discretionary change in the acquired estate from close.
- Set a decision date for coexistence, so it cannot become permanent by default.
The Regional Angle
The first constraint for groups operating here is that systems consolidation cannot outrun legal consolidation, and the legal timetable is rarely under your control. A regional acquisition typically arrives as a share purchase of an entity with a trade licence, an establishment card, a labour file, its own visa quota, and in many cases its own tax registration. Until the licensing and immigration position is merged or formally restructured, you cannot run one payroll instance across both populations, because two labour files and two wage protection registrations mean two filings. The same applies to tax grouping: whether the acquired entity can join the group registration, and from what date, determines whether one set of consolidated returns is even permissible. Sequence the systems plan behind the licensing and tax milestones, get written confirmation of the grouping position before anyone touches the chart of accounts, and expect the legal workstream to move slower than the integration team's plan assumes. The second is geographic and fiscal, and it constrains process design rather than timing. Groups here routinely hold a mix of free zone and mainland entities, and the boundary between them is a customs and tax boundary, not an internal reporting one. Movements of goods across it are declarations. Services across it have a VAT treatment. An acquired free zone entity absorbed carelessly into a mainland instance produces intercompany flows that look like ordinary internal transfers in the system and like taxable events to the authority. A single instance can handle this perfectly well, but only if the entity structure, the document flow and the intercompany pricing are designed around the boundary from the start. Retrofitting that after go-live means reopening posted periods, which is the conversation nobody wants with the auditors in year one of an acquisition. The third is what diligence failed to ask. The acquired estate is very often a partner implementation with substantial custom development, and the questions that matter were not on the checklist: who holds the software licence and is it transferable on change of control, is support current or lapsed years ago, who wrote the custom modules and who owns them, is there any source code or documentation, and can the data be extracted in a usable form without the original partner's cooperation. It is common to discover after close that the acquired company's system is maintained by one individual on an informal arrangement, on a version three releases behind support. That discovery changes the posture decision entirely — it usually converts a comfortable coexistence plan into an urgent absorb — and finding it in month eight rather than during diligence costs both money and credibility. If you are acquisitive, put those six questions into your standard diligence pack now.
The objection worth taking seriously
The strongest objection is that consolidation is a cost programme wearing a technology costume. Nobody in the market rewards a group for having one instance. Coexistence is genuinely cheap to maintain once the consolidation reporting works, integration platforms have made cross-system data movement unremarkable, and the capital that would fund a two-year harmonisation programme could instead fund something that grows revenue. Plenty of successful groups run a dozen systems indefinitely and are perfectly well managed. That is true more often than consolidation advocates admit, and the coexistence option deserves more respect than it usually gets. If the businesses do not share customers, suppliers, staff or processes, the case for a common instance is largely aesthetic. The cost of coexistence is not the running cost. It is the option value. With separate estates, every subsequent move requires a project: shifting a customer between entities, standing up a shared service, changing group credit policy, applying a new statutory requirement across the group, or carving out a division for sale. Each acquisition compounds it, and the compounding is silent because nothing ever breaks — things simply take three months instead of three weeks. The recommendation is not to consolidate by reflex. It is to make coexistence an explicit decision with a written expiry date and a named owner, so that when the group makes its next acquisition, someone has to renew the decision rather than inherit it.
Common Questions
How long should a realistic consolidation take?
For the ledger and statutory layer, two close cycles. For operational convergence, plan in years and stage it by business process, not by entity.
Should we migrate historical transactions?
Usually not. Migrate open items, balances and the master data. Keep the legacy system readable for the statutory retention period and budget for that access.
Who should lead — group IT or the acquired business?
Neither alone. The programme needs one accountable executive with authority over both finance functions, because most of the contested decisions are accounting policy rather than technology.
What should we expect over the next twelve months?
Expect integration debt from the 2021 and 2022 deal cohort to surface in this year's budgets, largely rebadged as modernisation. Expect boards to ask for evidence against the original synergy case rather than accepting a status update, and expect that question to be uncomfortable where nobody mapped savings to system changes. If financing conditions ease during the year, expect deal activity to resume before the previous round's integration is finished, which is precisely how estates become unmanageable. Groups that use the quieter part of this year to settle their chart of accounts and master data will absorb the next acquisition in a quarter. The rest will start this conversation again.
Systems Consolidation Roadmap — we map the synergy case to the system changes that actually produce it, and tell you honestly which acquisitions should never be absorbed.