Software Due Diligence: The Complete Buyer Guide
Software due diligence is the workstream that finds and prices the latent licensing and audit exposure inside a target, the gap that standard diligence leaves open and that surfaces as a publisher claim after close.
Software due diligence is the buyer side examination of a target's software estate, focused on the one thing other diligence streams do not own: the gap between what the company is licensed for and what it actually runs. This guide sets out what software due diligence is, why it matters, how it is scoped and sequenced, where the largest exposures hide, and how findings are turned into deal protection. It links to every detailed page in the cluster, so a deal team can move from this overview into the specific question in front of them.
Inherited software licensing exposure is usually latent and unquantified in standard due diligence. It does not show on the financial statements, it is rarely raised by the seller, and it lands as a publisher audit after the change of ownership, when the buyer has the least leverage. The purpose of software due diligence is to bring that exposure forward, quantify it, and give the deal team a number to price, indemnify or hold back before signing.
What software due diligence is and why it matters
Software due diligence reads a target the way a publisher would read it after a deal closes. It establishes the entitlement, measures the deployment and consumption against that entitlement, examines the contract terms that bite on a change of control, and assesses the indirect access created by integrations and interfaces. The output is a defensible view of exposure, expressed as a worst case at list price and a likely settlement range.
It matters because software is now among the largest and most contractually complex liabilities a buyer can inherit. The numbers in public disputes show the scale. As of 2024, SAP pursued AB InBev for a reported 600 million dollars and Diageo for a reported 60 million over disputed and inherited licensing, according to contemporaneous reporting. Even in the mid market, a single under licensed enterprise publisher can produce a seven figure claim. A deal model that ignores this is a deal model with a hole in it.
What standard diligence misses about licensing
The exposure survives because of how diligence is divided. Legal counsel reviews assignment and change of control clauses but does not measure deployment. Code scanning vendors check open source obligations but not commercial entitlements. Reporting accountants test the quality of earnings but treat software as a cost line, not a compliance position. IT diligence reviews architecture and roadmap. Between these workstreams sits the under licensing, the indirect access and the virtualisation exposure that nobody is asked to quantify.
The page on what standard IT due diligence misses about licensing goes deeper, and how latent licensing exposure hides from diligence explains the mechanics. The distinction between legal and commercial software diligence is the reason a dedicated buyer side stream is needed at all.
How to scope software due diligence on a target
Software due diligence is almost always time boxed, so scope is a triage decision. The right approach prioritises the publishers most likely to audit and most expensive to remediate, then works down. Oracle, SAP, Microsoft and IBM head the list, with Broadcom rising sharply following its VMware acquisition, and Salesforce and ServiceNow increasingly active. Within each, the focus is the metric that drives cost: named users, processors and cores, indirect access, and virtualisation.
| Publisher | Primary cost metric | Exposure to watch | Diligence priority |
|---|---|---|---|
| Oracle | Processors and named users | Virtualisation and soft partitioning | High |
| SAP | Named users and digital access | Indirect access from integrations | High |
| Microsoft | Users, devices and cores | Edition and cloud entitlement gaps | High |
| IBM | Processor value units | Sub capacity reporting failures | Medium to high |
| Broadcom VMware | Cores and subscription tiers | Repricing after portfolio changes | High |
| Salesforce and ServiceNow | Subscriptions and integrations | Over deployment and connector use | Medium |
Scoping is covered in detail in how to scope software due diligence on a target and prioritising publishers in a time boxed diligence. The full software due diligence checklist for acquirers sets out the requests and tests in order.
The software due diligence process
The process moves from data request to quantified exposure to deal protection. It begins by requesting the right artefacts from the target, building an entitlement baseline, measuring deployment, modelling the exposure, and presenting it to the investment committee in a form that drives price or terms. Each step has its own page in this cluster, and each is time sensitive, since the work has to fit inside the deal calendar.
See how to request software data from a target, building a software license position during diligence, quantifying software audit exposure before you sign, and how to present software risk to an investment committee.
How deal structure changes the analysis
The same estate carries different risk under different structures. Change of control and anti assignment clauses can trigger consent, termination or repricing, and a stock purchase, an asset purchase, a merger and a carve out each make different clauses bite. In a stock purchase the entity survives and most licenses ride along, but change of control clauses may still trigger. In an asset purchase, licenses often need consent to assign. A carve out has to separate shared and group wide agreements entirely. Software due diligence therefore reads the contracts against the actual structure, not a generic one. The page on software due diligence for stock and asset purchases works through the differences.
A diligence report that the committee can act on. The output of software due diligence is not a list of observations. It is a quantified exposure per publisher, mapped to the deal structure, with a recommended instrument for each material finding. See the due diligence report deliverable for what a complete report contains.
Turning findings into deal protection
A quantified exposure is leverage. It can reduce the purchase price, support a specific indemnity that survives close, or justify an escrow holdback sized to the likely settlement. The instrument depends on the size and certainty of the gap and on the structure. The cost of handling a finding before signing is always lower than the cost of absorbing it as a post close audit settlement, which is the entire commercial case for doing software due diligence properly.
- Software due diligence owns the gap between entitlement and deployment that other diligence streams leave open.
- Latent exposure does not show in the financials and surfaces as a publisher audit after close.
- Scope is a triage decision led by the publishers most likely to audit, starting with Oracle, SAP, Microsoft, IBM and Broadcom.
- Deal structure decides which change of control and assignment clauses bite, so the analysis is read against the actual structure.
- Quantified findings become a price reduction, a specific indemnity or an escrow holdback before signing.
- Run software due diligence as its own stream. Do not assume legal, financial or IT diligence will quantify licensing exposure, because none of them owns it.
- Triage by publisher. Spend scarce diligence time on the publishers most likely to audit and most expensive to remediate first.
- Demand quantified output. Require a worst case and a likely settlement range per publisher, mapped to your deal structure.
- Match the instrument to the finding. Use price, indemnity or escrow according to the size and certainty of each exposure.
- Engage an independent buyer side firm. Paid only by the acquirer, with no publisher or reseller affiliation, so the work defends your deal.
Who should own software due diligence on the deal
Ownership decides whether the work gets done well or done at all. Software due diligence does not belong to a single existing workstream, which is precisely why it is so often left out. Legal will not measure deployment, finance will not read product schedules, and the technology team running other diligence is usually focused on architecture and integration rather than commercial entitlement. The work needs a dedicated owner with a mandate to demand data, the expertise to read it against the contracts, and the independence to put an uncomfortable number in front of the investment committee. The page on who should own software due diligence on the deal sets out the operating model, and software due diligence and day one readiness connects the findings to the integration plan that follows close.
Independence is the quiet multiplier. A firm paid only by the acquirer, with no affiliation to any publisher or reseller, has no incentive to soften a finding to protect a vendor relationship or to inflate one to sell remediation software. The number it produces is built for one purpose, which is to defend the buyer's position. That alignment is what makes a diligence finding credible enough to move a price, support an indemnity, or justify a holdback, and it is the standard every page in this guide is written to.
Reading a target's software contracts in diligence
Contracts are where exposure is written down, and they are rarely read for commercial risk during a deal. A software agreement is not one document but a stack: the master agreement, the order forms, the product schedules, the support terms and the amendments that quietly changed the metric three renewals ago. The questions that matter to a buyer are specific. What is the licensing metric, and has the target measured itself against it. Does the agreement permit the deployment that is actually running. What happens to pricing and discounts on a change of ownership. Is there an audit clause, and has it been exercised. The page on reading a target's software contracts in due diligence works through the clauses that decide exposure, and mapping shared and group wide software agreements covers the agreements that span more than the target alone.
Group wide agreements are a particular trap. A target that is itself a subsidiary may run on a parent's enterprise agreement, with no standalone entitlement of its own. On acquisition, that entitlement does not travel, and the buyer inherits deployment with no license behind it. Identifying these dependencies early is the difference between a clean deal and an immediate post close gap.
Vendor specific diligence in depth
Each major publisher fails in its own way, and diligence has to know the pattern. Oracle exposure usually comes from virtualisation, where soft partitioning is not recognised and an entire cluster is treated as licensable. SAP exposure comes from indirect or digital access, where integrations, bots and ecommerce systems read from or write to the system without a named user behind them. Microsoft exposure tends to come from edition mismatches and from cloud entitlements that do not match on premises deployment. IBM exposure comes from sub capacity reporting that was never set up correctly, so the full capacity becomes chargeable. The page on vendor specific diligence for Oracle, SAP, Microsoft and IBM details each, and software due diligence on open source components covers the obligations that sit alongside the commercial ones.
Broadcom has changed the picture since acquiring VMware. Customers have faced subscription conversion and sharp repricing, and a target heavy on VMware can carry a materially higher run rate than its historical spend suggests. Diligence now prices the forward cost, not just the current one.
Software due diligence across different target types
The estate dictates the method. A SaaS heavy target hides exposure in subscription overage, connector licensing and auto renewing commitments rather than in installed software. An on premises estate hides it in deployment that has drifted past entitlement over years. A cross border deal adds currency, regional pricing and data residency to the licensing question. And a competitive auction compresses the timeline, so triage and the highest risk publishers come first. The method bends to the target, but the goal does not change: a quantified, defensible position.
Common mistakes that cost buyers
The recurring errors are predictable. Treating software as a finance line and never measuring deployment. Trusting the seller's user count without testing it. Ignoring indirect access because it is invisible on a license report. Assuming licenses transfer because the deal is a stock purchase. Leaving the work so late that there is no time to price a finding into the deal. Each of these is avoidable, and each is covered in common software due diligence mistakes that cost buyers and in the ten red flags in a target's software.
Estimating the cost to cure licensing gaps
A gap is only useful to a deal team once it carries a cure cost. Estimating the cost to cure means pricing what it would take to bring the combined entity into compliance: the additional licenses at realistic negotiated rates, any back maintenance, and the remediation effort. That figure, set against the worst case at list price, frames the negotiation and the choice of instrument. The page on estimating the cost to cure licensing gaps sets out the method, and software due diligence and the quality of earnings report explains how the cure cost connects to the deal model.
Everything in this software due diligence guide
Frequently asked questions
What is software due diligence?
It is the buyer side review of a target's software estate that finds and quantifies the gap between what the company is licensed for and what it actually deploys, including indirect access and clauses that bite on a change of control. It produces a defensible exposure figure before signing.
How is software due diligence different from IT due diligence?
IT due diligence reviews architecture, security and roadmap. Software due diligence focuses on commercial licensing exposure, measuring deployment against entitlement and reading contracts for change of control and assignment risk. The two are complementary, not the same.
Why does standard diligence miss licensing exposure?
Because the exposure falls between workstreams. Legal reviews clauses, finance reviews cost, technical reviews architecture, and open source scanning checks code. The under licensing and indirect access in the middle is unowned unless a dedicated stream quantifies it.
Which vendors carry the most audit risk?
Oracle, SAP, Microsoft and IBM have historically driven the largest claims, with Broadcom more active following its VMware acquisition, and Salesforce and ServiceNow rising. As of 2024, SAP pursued AB InBev for a reported 600 million dollars over disputed and inherited licensing.
When should software due diligence happen?
Before signing, while the buyer still has leverage. Findings are far cheaper to handle as a price or terms adjustment than as a post close audit settlement, and the work has to fit inside the deal calendar.
How are findings used in the deal?
As a purchase price reduction, a specific indemnity that survives close, or an escrow holdback sized to the likely settlement, chosen according to the size and certainty of the exposure and the deal structure.
Is software due diligence legal advice?
No. It is independent buyer side commercial and licensing advisory. For interpretation of specific contract clauses, engage your own counsel.
Request software due diligence on your target.
Bring us the target, the deal structure and the timeline. We map and quantify the inherited licensing exposure before it becomes a post close audit.