Kennisbank

Is this synergy still achievable, or has it become an assumption

A synergy on a synergy baseline starts as an estimate. The moment the deal is signed, that same estimate often silently becomes a certainty. Nobody tests it again, because it's already in the model. That is the moment at which a synergy can shift from realistic to wishful thinking, without anyone noticing until the figures for month four or five disappoint.

Testing whether a synergy is still achievable means looking at three things in sequence: the assumption behind it, its owner, and the way you track whether it is actually landing. Without those three, a synergy is a line in a spreadsheet, not a plan.

The assumption underneath the synergy

Every synergy rests on an assumption about the world: that two procurement departments can be merged without loss of supplier terms, that a sales team has the capacity to sell a second product line, that a system can be phased out without a customer noticing. That assumption has often never been made explicit. It sat in the head of the person who supplied the figure during due diligence.

Testing starts with bringing that assumption back to the surface and asking whether it still holds, now that more is known about the organization than during the deal. In a buy-and-build, that assumption often changes faster than in a single acquisition, because the basis on which the synergy rests — a third or fourth platform being added — is itself still in motion. How you substantiate that assumption within such a structure is described in how you substantiate a synergy in a buy-and-build.

The owner of the synergy

A synergy without an owner is a figure that nobody defends and nobody adjusts. Testing whether it is achievable requires someone who can say why it still holds or no longer holds, and who also notices this before it's too late. That is not automatically the person who put the synergy forward during the deal; often it is someone else, closer to the operation where the synergy has to land.

In a buy-and-build with multiple platforms, that question is trickier than it seems: who owns a synergy that runs across two or three companies, and what happens when those companies have different priorities. That question is worked out in who owns a synergy in a buy-and-build. Without an identifiable owner, testing remains a formality: someone is needed who is also allowed to find the answer uncomfortable.

How you track whether the synergy is landing

The third step is not a one-off but ongoing: how do you know, month after month, whether the synergy is still on track. That requires a format that does not depend on a single final figure at the end of the year, but on interim signals. A traffic-light model — green, amber, red per synergy — is a useful format for this, because it forces a choice per period rather than a story after the fact. How such a system works is described in how you track synergies with traffic lights.

The value of that tracking lies not in the report itself, but in the moment when amber turns to red and there is still time to do something. If you wait until the year-end close, testing is no longer testing but merely noting.

What testing must not become

Testing whether a synergy is achievable must not be confused with holding on to a synergy because it was in the original model. There are synergies that, on closer inspection, are not achievable, or no longer outweigh the effort of realizing them. That is not a failure of the process; that is precisely why testing exists. What you do when a synergy fails to land despite testing, and which options realistically apply there, is described in what you do with a synergy that fails to land.

In addition, for every synergy the question applies that is often skipped: should this part be integrated at all. A synergy that works on paper but can only be realized by mixing up two cultures, two systems, or two customer relationships can destroy more value than it creates. Testing also means asking that question again, not only at the start but at every review.

What this asks in terms of time

Testing a synergy costs capacity: someone has to revisit the assumption, question the owner, and keep track of progress alongside their regular work. In an integration where testing has to happen on multiple fronts at once — synergies, Day 1 tasks, contract dependencies as described in which contracts require Day 1 attention — that capacity fills up quickly. Which part of that testing and tracking work is task-bound enough to hand over to AI, and which part the owner must keep doing themselves, is something the werkscan of FTE TO AI calculates per task.