The questions buyers ask most often once two software estates have to become one, answered from the buyer side with the licensing and audit realities that decide whether integration protects value or leaks it.
This post merger software integration FAQ answers the questions buyers ask most often once two software estates have to become one, from the buyer side and with the licensing and audit realities that decide whether integration protects value or leaks it. Combining software is not a technical exercise alone. It is a licensing exercise, because every move that merges systems also moves the estate against its entitlements, and a change of control is a recognised trigger for a publisher audit. The questions below cover where to start, what to watch, and how to keep the combined estate defensible.
Every integration comes down to four questions. What do we actually own across the two companies? Where do our contracts overlap and pay twice? Where is the audit risk concentrated? And what do we consolidate first? Answering them in order is what keeps the estate defensible while it changes. Answering them out of order, by merging systems before knowing what is owned, is what creates the exposure that surfaces later as a true up demand.
These questions are not academic. Inherited licensing exposure is usually latent and unquantified in standard due diligence, and it lands as a publisher audit after close. The FAQ format is useful precisely because integration teams under time pressure reach for quick answers, and the quick answers that protect value are different from the ones that feel fastest. Reconciling first feels slower than merging first, but it is the only sequence that holds.
Integration should start with reconciliation: an independent baseline of what each company owns against what it deploys. Every consolidation and renegotiation decision depends on that baseline being accurate, which is why it is the work of license reconciliation and the first thing to commission, covered further in post merger software integration and where to start.
Double spend is the clearest leak the FAQ surfaces. It is paying more than once for the same software capability because the merged companies hold separate contracts for it. Eliminating double spend is usually the fastest and most defensible synergy in software integration, and the method is set out in eliminating double software spend after a merger. The work of choosing one platform per capability and exiting the rest is integration and consolidation advisory.
| Question | Short answer |
|---|---|
| Where do we start? | Reconcile what is owned before merging anything |
| What is double spend? | Paying twice for the same capability across two contracts |
| When is audit risk highest? | During integration, because change of control triggers reviews |
| How long does it take? | Stabilise in weeks, consolidate over the first hundred days |
| Who should own it? | A single accountable owner for the licensing position |
Audit risk is highest during integration, because a change of control is a recognised audit trigger and the estate is changing fastest at exactly that time. The major audit risks come from Oracle, SAP, Microsoft, IBM, and increasingly Broadcom following its VMware acquisition, Salesforce, and ServiceNow, as of June 2026. The estate is therefore most exposed to a review when it is least settled, which is why a defensible position has to be held from close, not built afterward.
On timing, the estate can be stabilised in the first few weeks, with consolidation and renegotiation running across the first hundred days, as set out in the software integration day one to day 100 plan. True up risk, the danger of a publisher demand for past under licensing, is managed across the same window and explained in post merger true up risk and how to avoid it.
The reason this FAQ insists on reconciliation before integration is that the cost of getting it wrong is large and well documented. In publicly reported disputes SAP pursued AB InBev for a reported 600 million dollars and Diageo for a reported 60 million over disputed and inherited licensing, as of June 2026. The Diageo dispute in particular turned on indirect access, where connected systems generated usage the licence position had not accounted for, a dynamic integration can easily create as it wires two estates together.
For a buyer, the lesson is that software integration is a value protection exercise as much as a cost saving one. The synergy from consolidation is real, but it is only kept if the estate stays defensible while it is captured. The integration is then handed to an integration roadmap and a governance model that carry the discipline forward. Engage your own counsel for legal interpretation of any audit clause or publisher claim.
One question buyers raise often is who pays when an inherited exposure surfaces after the deal. The answer depends on the agreement: where the software risk was reflected in reps, warranties, or a specific indemnity, the cost can fall back on the seller, but where it was missed it falls on the buyer in full. This is why the software dimension belongs in diligence before signing, not as a clean up after close. An exposure found early can be priced into the deal or allocated to the seller, while the same exposure found late is simply a cost the buyer absorbs against the return.
This FAQ sits within post merger software integration and points to the deeper guides on starting, eliminating double spend, and managing true up risk. Engage your own counsel for legal interpretation of any contract, clause, or claim.
Tell us where the deal stands. We respond within one business day with a scoped, buyer side engagement that protects the value you underwrote.
Book a confidential call