An acquisition is approved on a thesis. Before completion, an investment committee has agreed why the group is buying the business, whether for a market, a capability it lacks, scale or cost, and that reason has been written down, argued over and priced. It is the most authoritative document the integration programme will ever have. On the day of completion it is often filed away, and moving the acquired business onto the group's ERP becomes the plan.
A migration plan describes how records will move. It says nothing about what the group intends to make common, and the gap shows up in the first quarter's consolidated numbers. Across the transformation portfolios I have led, more than USD 250 million of them in more than 12 countries, the order in which decisions were taken has mattered more than the platform chosen. Acquisitions test that harder than most programmes, because the deal model has usually assumed an answer before anyone is appointed to integrate.
The deal thesis decides what becomes common and what must be protected
Each reason for buying implies a different list. A cost thesis needs shared supplier records and approval authorities early. A capability thesis can be destroyed by forcing the acquired team onto group processes that were never designed for what it does well.
This is the grid I would ask an integration lead to complete before a systems plan is approved. It follows from the logic of each thesis and is not taken from any one deal.
| Deal thesis | Common from the first reporting cycle | Common within the first year | Stays distinct |
|---|---|---|---|
| Market access | Group definitions of revenue and customer; consolidation mapping | Customer consent and account ownership, where cross-selling is planned | The local go-to-market, pricing and service practices that won the market |
| Capability | Financial controls, close calendar, group reporting definitions | The data access the group needs to use the capability elsewhere | The processes, systems and people that hold the capability |
| Scale | Revenue, margin and inventory definitions; supplier and customer records where volumes will be pooled | Planning information, approval responsibilities, shared-service processes | Customer-facing differences that matter in particular markets |
| Cost | Supplier records, contract decisions and approval authorities behind each synergy | Common processes and, where the case holds, a common platform | Little: this is the thesis where standardising fast is usually right |
The first column is short in every row, on purpose. What must be common on the first day is a small set of definitions and controls.
The third column is the one plans most often leave blank, and I treat a blank there as a warning. If nobody can say what the acquired business keeps, the thesis is not yet clear enough to plan systems against. The programme will then make everything common, because that is what platform programmes know how to do.
The group can see clearly long before it is uniform
The first consolidated report after completion is where incompatible definitions usually surface. Customer, revenue, margin and inventory can each be counted differently in the two businesses, and leaders find themselves comparing figures that look alike and describe different things.
Harmonising everything before reporting is the slow answer. Agree the minimum shared meaning the combined business needs in order to be governed, and name an owner for each definition and for the reconciliation behind it. Group reporting can then run on those definitions through a mapping layer while the ledgers underneath still differ, with every adjustment visible. Leadership has a basis for decisions within weeks, and the longer design work proceeds on evidence.
Every synergy rests on records somebody has to own
A procurement saving depends on common supplier records, contract decisions, approval limits and planning data. Cross-selling depends on customer consent, account ownership, product availability and the ability to service what is sold. None of it moves faster than the decision about who owns it.
Sequence the work around those dependencies and write the intermediate states down: which team owns the work, which system holds the record, and how an exception crosses the boundary while both businesses are in transition. Intermediate states that nobody wrote down tend to outlast the programme.
Standardising fast is right when the thesis is cost
A CFO with synergy targets already in the deal model will say, fairly, that every month of delay costs money, and that one system and one process for everyone is the shortest route to them. Under a cost thesis, where the acquired business's processes carry little of the value, I agree, and the grid says so. The same holds for a small bolt-on absorbed into an existing division, which is a cost thesis in all but name.
Under the other three, speed in the wrong place is expensive. Uniformity imposed before the group can see clearly hides differences without resolving them: two meanings of revenue loaded into one field look consistent and are not. Records moved faster than their ownership is decided carry the dispute intact into the new system.
Undecided authority keeps two ways of working alive
When decisions about roles and local autonomy are deferred, teams keep two ways of working because nobody holds the authority to retire one. Finance shows it first. Two close calendars, two approval matrices and two charts of accounts can run side by side for a long time, each defended by people doing their jobs properly and each adding reconciliation work at group level. The CFO should decide early which of them the group needs one of, and put that in writing.
Process owners need a clear mandate. The people affected need to hear why each change is required and where local judgement remains. The knowledge that made the business worth buying has to survive the integration, and it rarely lives in the systems.
Judged against the thesis, the first integration makes the next one cheaper
Interfaces built and data migrated are inputs. Progress is whether the operating and economic thesis is being delivered. Keep one-off integration cost apart from the cost of running the combined business, and forecast synergy apart from realised improvement. Reported together, they flatter the programme until someone has to explain the difference to the board.
A group that intends to buy again should keep what the first integration taught it: how data from a new business is onboarded, which controls are applied from day one, and who decides what. The second acquisition can then start from that record instead of from a blank page.
The decision in front of the CFO comes before the systems decision, and it is shorter than any integration plan. It is two signed lists. The first holds the definitions the combined group will share from its first reporting cycle, each with a named owner. The second records what the acquired business keeps as its own. If the second list is still empty when the systems plan reaches the steering committee, I would send the plan back.
