Software Due Diligence

Who Should Own Software Due Diligence on the Deal Team

The software licensing review falls between legal, IT and finance on most deals, so no one measures deployment against entitlement. Here is who should own it, and why.

Deciding who should own software due diligence on the deal team is one of the quietest decisions a buyer makes, and one of the most expensive to get wrong. On most deals the question is never asked directly, so the software licensing review falls between the desks of legal, IT and finance, and no one measures whether the target deploys more than it is licensed to use. That gap is where inherited exposure survives into ownership, and it is why the ownership question matters. Effective software due diligence depends on someone holding the licensing workstream as their own, not assuming a neighbour will catch it.

The honest answer is that no single role on a standard deal team owns it well, because the work is a specialist discipline that sits outside what legal, IT and corporate development are built to do. Each touches a part of the software estate, but none of them measures deployment against entitlement, and that measurement is the heart of the exposure. Understanding who carries what, and where the gap is, lets a buyer close it on purpose rather than by accident.

Who should own software due diligence on the deal team

Ownership of software due diligence should sit with whoever can measure the licensing position and quantify the exposure, and on most deals that is an independent software advisor brought in for the purpose. Corporate development owns the deal calendar and coordinates the workstreams. Legal counsel reads the contracts and answers the consent and assignment questions. IT or technical diligence maps the architecture. The licensing measurement, deployment counted against entitlement on each publisher own metrics, belongs to none of them by default, which is why a buyer should assign it deliberately.

Who carries each part of software due diligenceBar chart showing the share of software due diligence work that naturally falls to each role on the deal team, with the independent software advisor carrying the licensing measurement the others do not cover.Who carries each part of software due diligenceCoordinatesCorporatedevelopmentContractsLegalcounselArchitectureIT ortechnical DDLicensingSoftwareadvisor

The reason the gap exists is structural. A financial team reads spend, a legal team reads terms, and an IT team reads systems, but the exposure lives in the space between what a target pays and what it actually runs. That space is invisible to all three reviews unless someone is tasked with counting it. The discipline is set out in what standard IT due diligence misses about licensing, which explains why an architecture review and a licensing review are not the same exercise.

Who owns each software due diligence task on the deal team
TaskNatural ownerWhy it sits there
Set the diligence scope and timelineCorporate development or deal leadOwns the deal calendar and coordinates every workstream
Interpret contract terms and consentsLegal counselChange of control, assignment and termination are legal questions
Review architecture and IT systemsIT or technical diligenceMaps the systems but does not measure license entitlement
Measure deployment against entitlementIndependent software advisorThe licensing position is a specialist discipline none of the above run
Quantify the exposure into a deal leverIndependent software advisorTurns findings into a number the deal team can price or indemnify

Why the deal lead cannot simply delegate it

A deal lead under time pressure will often assume the licensing question is covered, because legal is reading the master agreements and IT is reviewing the stack. Both are true, and neither closes the gap. Legal will flag a change of control clause but will not count Oracle cores on a virtualised cluster. IT will diagram the data centre but will not classify SAP named users or measure indirect access. The work that produces an exposure number is neither a legal nor an architectural task, so it has to be owned by someone whose job is precisely that. The deliverable that results is described in software due diligence deliverables.

What the owner is accountable for

Whoever owns the workstream is accountable for four things: scoping the publishers that matter, requesting the right data from the target, measuring deployment against entitlement, and quantifying the result into a range the deal team can use. Each of these is a discrete skill. Scoping is covered in how to scope software due diligence on a target, and the data request is set out in how to request software data from a target. The owner does not need to be an employee of the buyer, and on most deals is better placed outside it.

Key takeaways

  • Software due diligence ownership should sit with whoever can measure the license position and quantify the exposure.
  • On a standard deal team that work falls between legal, IT and finance, so no one runs it unless assigned.
  • Legal reads contracts and IT reads systems, but neither counts deployment against entitlement.
  • The owner is accountable for scope, data, measurement and a quantified exposure range.
  • An independent advisor is usually the right owner because the work is a specialist discipline with no inside conflict.

Why an independent advisor is usually the right owner

There are three reasons an independent buyer side advisor is usually the right owner. The first is skill: measuring an effective license position across Oracle, SAP, Microsoft, IBM and increasingly Broadcom, Salesforce and ServiceNow is a full time discipline, not a task to bolt onto a generalist review. The second is independence: an advisor paid only by the acquirer has no incentive to soften a finding, unlike a reseller or a party that also sells to the publisher. The third is speed: an owner who has run the workstream many times knows where the largest exposures cluster and can prioritise them inside a tight deal window, as described in prioritising publishers in a time boxed diligence.

How ownership changes the outcome

When the licensing workstream has a clear owner, the deal team receives a quantified exposure it can act on, price into the model, or convert into an indemnity. When it has no owner, the same exposure stays latent, the deal closes at full price, and the publisher audit lands months later as the new owner problem. As of mid 2025, SAP pursued AB InBev for a reported 600 million dollars and Diageo for a reported 60 million in disputes tied to indirect and inherited licensing, which shows how large an unowned exposure can become once it surfaces after close. Assigning the ownership early is the cheapest insurance a buyer can buy.

Recommendations for buyers

  1. Name the owner of the software licensing workstream in writing at the start of diligence, not by assumption.
  2. Give the owner the four accountabilities: scope, data request, measurement, and a quantified exposure range.
  3. Keep legal on contracts and IT on architecture, and do not expect either to measure the license position.
  4. Use an independent buyer side advisor where the estate spans Oracle, SAP, Microsoft, IBM or Broadcom.
  5. Require the exposure number early enough to price it, indemnify it, or make it a condition of close.

Ownership is the first decision in the software due diligence method and the one that determines whether the rest of the work happens at all. The full workstream is delivered through our software due diligence service.

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

Who should own software due diligence on the deal team?

Whoever can measure the license position and quantify the exposure. On most deals that is an independent software advisor, because legal owns contracts, IT owns architecture, and neither measures deployment against entitlement.

Can legal counsel own software due diligence?

Legal should own the contractual questions such as change of control, assignment and termination, but interpreting terms is not the same as counting Oracle cores or classifying SAP users. The licensing measurement is a separate discipline.

Does IT due diligence cover software licensing?

IT or technical diligence maps the architecture and the systems, but it does not measure entitlement against deployment. The exposure lives in the gap between what a target pays and what it runs, which an architecture review does not count.

Why use an independent advisor rather than an internal team?

Because the work is a specialist full time discipline, an independent buyer side advisor has no conflict, is paid only by the acquirer, and has seen where the largest exposures cluster, so it runs faster inside a tight deal window.

What is the owner of software due diligence accountable for?

Four things: scoping the publishers that matter, requesting the right data from the target, measuring deployment against entitlement, and quantifying the result into a range the deal team can price or indemnify.

What happens if no one owns it?

The licensing exposure stays latent, the deal closes at full price, and the publisher audit lands after close as the new owner problem. Assigning ownership early is the cheapest way to avoid that.

Give the licensing workstream a clear owner.

We own the software licensing workstream on your deal, measure deployment against entitlement, and hand your team a quantified exposure before you sign.

Request a software due diligence