Carve out software audit risk for both sides.

Carve out software audit risk for both sides is the exposure that a publisher audit can land on the seller and the buyer at the same time, because for a period around close the two share the same licenses, the same deployments and the same unanswered questions about who is entitled to what. Most diligence treats audit risk as a single party problem. In a carve out it is not. The parent keeps a residual estate sized for the old combined business, and the new entity runs on the parent licenses under the transition services agreement until it stands up its own. Both positions are auditable.

Why carve out software audit risk for both sides is different

In a standard acquisition the buyer inherits the target estate and the seller walks away. In a carve out the estate does not divide cleanly, so for the length of the transition services agreement the parent and the new entity occupy overlapping licensing positions. The parent retains contracts and entitlements that were counted at combined scale, including the headcount, processors and consumption of the unit being sold. The new entity, meanwhile, has no entitlement of its own on day one and operates on borrowed access. A publisher looking at the deployment data after close can find usage that exceeds the parent entitlement and usage in the new entity that has no contract behind it. Either finding opens an audit, and the cost can fall on whichever party the publisher chooses to pursue.

This is why audit risk in a carve out has to be mapped from both perspectives at once. The seller wants to avoid being charged for usage that belongs to a business it no longer owns. The buyer wants to avoid an emergency purchase at list price when a consent is refused or a TSA ends before migration is complete. The two interests are linked, because the same deployment record can be read against both. As of June 2026, the publishers most active in this pattern are Oracle, SAP, Microsoft, IBM and increasingly Broadcom for the former VMware estate, all of which treat ownership changes as a moment to review usage and entitlement.

The public proof that inherited licensing becomes an audit

The clearest evidence that latent licensing exposure surfaces as a post deal audit comes from the public record. As of June 2026, SAP pursued Anheuser Busch InBev for a reported 600 million dollars over disputed and indirect access licensing, and pursued Diageo for a reported 60 million pounds in a related indirect use dispute. These figures are widely reported rather than firm confirmed, and they illustrate the scale that licensing exposure can reach once a publisher decides to act. In a carve out the same dynamic is sharper, because the entitlement that covered a deployment yesterday may no longer cover it once ownership splits. Quantifying that gap before signing is the work that standard due diligence usually skips.

Mapping the exposure on both sides before close

The practical answer is a single reconciliation that looks at both parties together. Start from the actual deployment, not the contract. Measure what is installed and consumed across the unit being carved out, then test it against the parent entitlement to see how much usage is genuinely covered and how much was only ever covered because the unit and the parent were one company. The gold band in the diagram below is that uncovered overlap, the usage neither side can cleanly claim. The table that follows maps where the exposure lands for each party so the deal team can price and allocate it before signing rather than discovering it in an audit notice.

This reconciliation is part of our carve out and TSA separation service and sits within the carve out and TSA software playbook. It draws directly on separating shared software licenses, the cost view in stranded software costs, and the timing discipline in the TSA exit timeline and software critical path.

Allocating audit risk in the deal documents

Once the exposure is quantified it has to be allocated. The purchase agreement and the transition services agreement are where audit risk is shared or shifted. A buyer should press for the seller to warrant the entitlement position of the unit as of close, for indemnity language that survives long enough to cover an audit window, and for a TSA that obliges the parent to maintain valid licensing for any software the new entity uses through the service. A seller should press for clean usage data, a defined exit date and protection against the new entity over consuming on the parent contracts. Neither side gets there without a shared, evidence based view of what is actually deployed and what is actually entitled.

A short anonymised composite shows the pattern. A private equity backed buyer acquiring a 1,400 employee software unit carved out of a larger industrial group assumed the database and middleware estate was fully licensed because it had always run without complaint. A pre signing reconciliation found that roughly a fifth of the database deployment was only covered by an enterprise agreement that stayed with the parent and did not transfer. The exposure, had it surfaced as an audit, was an eight figure list price gap. Because it was found before signing, it was solved with a transitional license under the TSA and a re contract at the new entity scale, and the risk was priced into the deal rather than absorbed by surprise.

The data a both sided reconciliation needs

A reconciliation that protects both parties depends on the right inputs, and gathering them is where the work is won or lost. The first input is deployment data measured at the source, drawn from the publisher own tooling where it exists, from inventory and discovery scans across the estate, and from the management consoles that report actual consumption. The second is the contract set, every agreement, ordering document, amendment and renewal that defines what each party is entitled to and on what metric. The third is the organisational boundary, a clear definition of which legal entities, sites, users and servers belong to the unit being carved out, because the entire exercise turns on drawing that line precisely. Without all three, a reconciliation is an estimate, and an estimate does not survive an audit.

The boundary is the input buyers underestimate most. In a combined business, users move between divisions, servers host workloads for more than one unit, and a single named user record may carry access that spans the parent and the unit being sold. Splitting that cleanly requires a decision on every ambiguous record, and those decisions change the count and therefore the cost. An advisor who has run these reconciliations builds the boundary first, documents every judgement, and keeps the working papers so that if a publisher later challenges the split, the buyer answers with evidence rather than reconstructing the logic under pressure.

Finally, the reconciliation has to be dated and version controlled, because deployment moves. A count taken three months before close is stale by completion, and a publisher reviewing usage after close will measure the live environment, not the diligence snapshot. The discipline is to take a baseline early, refresh it close to completion, and reconcile the two so the deal team can see what changed and why. That dated, evidence backed position is what lets a buyer price audit exposure with confidence and defend it on either side of the table.