M&A Software Audit Risk

Inherited Software Audit Liability Explained

When you buy a company, you buy its licensing position, including the gaps it never disclosed because it never measured them. Here is how that liability transfers, why it is invisible, and what it is worth.

Inherited software audit liability explained in one sentence: when you buy a company, you buy its software licensing position as it stands, including the shortfalls it never disclosed because it never measured them. The liability is latent, it transfers with the entity, and it surfaces as a publisher audit after close, frequently priced at a multiple of what it would have cost to fix in advance. This page explains how that liability arises, why it stays invisible through standard diligence, how it transfers, and what it is worth, as a core page in the cluster on M&A software audit risk.

What inherited software audit liability means

Inherited software audit liability is the exposure a buyer takes on when a target is under licensed or out of compliance at the point of sale. It is not a debt on the balance sheet and not a disclosed contingent liability. It is the gap between what the target deployed and what it was entitled to, valued at what a publisher could charge to settle it. Because the target rarely measured the gap, it could not disclose it, and because standard diligence does not measure deployment against entitlement, the buyer does not find it either. The liability therefore passes silently from seller to buyer and only becomes visible when a publisher decides to count.

How inherited liability is priced versus a proactive fix A bar comparison showing the small cost of fixing a shortfall proactively against the larger list priced audit settlement including back maintenance and penalties. Proactive fix Negotiated Audit settlement List price + back maintenance + penalties cost The same gap costs far more once a publisher prices it in an audit than it does fixed in advance.
The liability is the same gap either way. What changes is who sets the price, and when.

How the liability arises inside the target

The gap accrues through ordinary operations. A target deploys software on more servers than it licensed, adds users faster than it trues up, connects a new application that reads data from a licensed platform without buying indirect access, or virtualizes infrastructure in a way a publisher counts more expensively. None of this is fraud. It is the normal drift of a software estate that nobody reconciles, and it is widespread because reconciliation is unglamorous and rarely owned. Each instance of drift is a latent shortfall, and the sum of them is the inherited liability waiting for a buyer.

Why standard diligence misses it

The liability survives diligence because no standard workstream is assigned to it. Legal diligence reviews assignability and consent, the financial team reviews quality of earnings, and a code scan reviews open source and security. The one number that matters here, deployed usage measured against contractual entitlement for the publishers that drive audit risk, falls between those workstreams and is owned by none of them. That gap in the diligence process, not any deception by the seller, is why an eight figure exposure can pass through a deal unremarked. The structural reason is set out in why acquired companies are soft audit targets.

How inherited liability transfers by deal structure
Deal structureWhat happens to the liabilityBuyer's lever
Stock purchaseTransfers intact with the entityReps, warranties, and indemnity
Asset purchaseMay require consent to assign licensesStructure transfers, secure consents
MergerCombines into the surviving entityQuantify and reconcile post close
Carve outSplits shared licenses, can strand rightsTSA and clean re licensing

Key takeaways

  • Inherited software audit liability is the gap between what a target deployed and what it was entitled to, valued at what a publisher could charge.
  • It is latent and undisclosed because the target never measured it and standard diligence does not look for it.
  • Deal structure decides how the liability transfers, with stock purchases carrying it intact.
  • An audit prices the same gap at list with back maintenance and penalties, often a multiple of a proactive fix.
  • Quantified before signing, the liability can be priced into the deal, escrowed, or covered by warranty and indemnity.

How the liability transfers through the deal

The structure determines the mechanism. In a stock purchase the buyer takes the entity whole, so the liability transfers intact and the buyer's protection lies in the purchase agreement, through representations, warranties, and indemnities covered in reps and warranties for software audit exposure. In an asset purchase, licenses may need consent to assign, and a botched transfer can leave the buyer operating without rights. A merger folds the liability into the surviving entity, and a carve out can strand license rights when shared agreements are split. In every case the liability does not vanish; it moves, and the structure decides how.

What the liability is worth

The value of the liability is what a publisher could realistically charge to settle it, not the cost of the licenses at fair value. That difference is the whole point. An audit settlement applies list pricing, adds back maintenance for the period of under licensing, and can add penalties, so the figure is routinely several times the cost of remediating the gap proactively. Public cases mark the upper range: as of mid 2025, SAP pursued AB InBev for a reported 600 million dollars and Diageo for a reported 60 million over disputed and inherited licensing. Most deals are smaller, but the multiple between a quiet fix and an audit settlement holds, which is why valuing the liability honestly matters. The mechanism is detailed in how latent under licensing becomes an eight figure claim.

How a buyer prices and covers it

A quantified liability is a manageable one. Measured before signing, it becomes a number the deal team can act on: priced into the valuation, held back in escrow, or covered by warranty and indemnity insurance. Each route is a way to make the seller, the deal price, or an insurer bear a risk that would otherwise land entirely on the buyer after close. The options are set out in software audit indemnities in purchase agreements and escrow and holdbacks for software licensing risk. The one option that fails is the default: inheriting the liability unmeasured and discovering its size in an audit notice.

Recommendations for buyers

  1. Assign the deployment versus entitlement question. Make it someone's job in diligence, because no standard workstream owns it.
  2. Quantify the liability before signing. A measured exposure is one you can price, escrow, or insure.
  3. Match the protection to the structure. Use reps and indemnities in stock deals and clean transfers in asset deals.
  4. Value it at the audit price, not fair value. The realistic settlement, not the license list, is the true liability.
  5. Reconcile fast after close. Remediating the gap proactively beats settling it under an audit clock.

Inherited software audit liability explained, and made manageable

Inherited software audit liability explained comes down to this: you buy the target's compliance position as it is, the gaps included, and those gaps are worth what a publisher could charge to settle them, not what the licenses cost at fair value. The liability is invisible because no one measured it and diligence was not looking, and it transfers according to the deal structure. The buyer who quantifies it before signing turns an unbounded surprise into a priced, coverable line. We measure that liability on the buyer's side only, paid solely by the acquirer, and we frame it so it can be carried in the deal rather than discovered after it.

Independent and buyer side. We act only for the acquirer. We hold no affiliation with any software publisher or reseller and are paid solely by you. This page is commercial and licensing guidance, not legal advice. Confirm any contractual interpretation with your own counsel.

Frequently asked questions

What is inherited software audit liability?
It is the exposure a buyer takes on when a target is under licensed at the point of sale. It is the gap between what the target deployed and what it was entitled to, valued at what a publisher could charge to settle it, and it transfers with the entity at close.
Why is the liability invisible during diligence?
Because no standard workstream is assigned to it. Legal reviews assignability, finance reviews earnings, and a code scan reviews open source. Deployed usage measured against entitlement for audit prone publishers falls between them and is owned by none.
How does the liability transfer in a deal?
By structure. A stock purchase carries it intact, an asset purchase may require consent to assign licenses, a merger folds it into the surviving entity, and a carve out can strand license rights when shared agreements are split.
What is the inherited liability actually worth?
What a publisher could realistically charge to settle it, not the fair value of the licenses. An audit applies list pricing, back maintenance, and sometimes penalties, so the settlement is often several times the cost of a proactive fix.
How large can inherited audit liability be?
It can be very large. As of mid 2025, SAP pursued AB InBev for a reported 600 million dollars and Diageo for a reported 60 million over disputed and inherited licensing. Most deals are smaller, but the multiple between a quiet fix and an audit settlement holds.
How can a buyer protect against inherited liability?
Quantify it before signing, then price it into the valuation, hold it in escrow, or cover it with warranty and indemnity. Match the protection to the deal structure, and reconcile fast after close to remediate the gap before an audit prices it.

Price the liability before you inherit it.

We quantify the inherited software audit liability inside a target before you sign, so it can be priced into the deal, escrowed, or covered by warranty and indemnity.

Request an audit risk assessment