Eighty-Five Versions of Order to Cash: The Integration Cost Hiding in Your Buy-and-Build

What mapping every market against one standard process revealed, and what standardising it released.

Acquisitions add revenue. They also add process variants. Buy-and-build models usually count the first carefully and the second barely at all. The cost of inherited variation rarely appears as a line item. It appears as effort: people re-keying orders, chasing disputes across systems, and reconciling numbers that were never designed to match.

What acquisition-built finance looks like from the inside

A decade ago I was a senior consultant and subject-matter expert on setting up Order to Cash service delivery for a European industrial manufacturer. The group had grown its markets largely through acquisitions, and it showed. Across 85 countries there was a plethora of ERPs, local systems and tools, and in practice 85 versions of the same process.

The task was to move the work from those markets into three regional hubs across Asia and Europe. What made it hard was not the distance or the volume. It was that there was no single process to move.

The approach, in three moves

1. Map before you move. I mapped the current-state Order to Cash process in every country against one standard process. The exercise exposed gaps at every level, across all the sub-processes. No individual market looked broken in isolation. Set against the standard, the variation was visible for the first time.

2. Design once. I drew up a single global Order to Cash domain design, so that the hubs would run one process instead of inheriting eighty-five.

3. Implement, and simplify the systems underneath. I implemented the design and migrated multiple countries onto SAP, which streamlined the ERP landscape at the same time.

What it released

The Order to Cash tower ran on 98 people. The redesign released 16 of them, about one in six. It also freed effort in the processes upstream and downstream of Order to Cash, where teams had been absorbing the consequences of inconsistent data and non-standard handoffs.

Sixteen out of 98 is a modest-sounding figure, and I would rather state it plainly than round it up. It came from one tower, in a group that started with a different process in every country.

What an investor should take from it

Count variants, not just entities. Ask how many versions of each core process the group runs, and how many ERP instances and local tools sit underneath them. A high count is a leading indicator of both cost-to-serve and integration risk, and it is rarely in the data room.

Standardise before, or as, you centralise. Moving 85 variants to three hubs without a standard design does not remove the variation. It relocates it, at a cost, into fewer places. In my view the design work is what makes the move pay.

Treat ERP rationalisation as the pace-setter. Each system retired removes a layer of reconciliation and manual handling, and later steps depend on it. Timelines for centralisation are usually ERP timelines.

Look for the locked effort. The saving is often not in the tower being redesigned. It is in the towers around it.

What this means for the investment case

For a buy-and-build, the finance synergy is not just the duplicate cost removed at each bolt-on. It is the cost of the variation each bolt-on imports, and the design work needed to retire it. Priced early, it becomes a plan. Discovered late, it becomes a delay.

Axiom Finance Advisory works with deal teams and portfolio companies on finance operations diligence and transformation.