Knowing how to request software data from a target is the practical skill that decides whether a licensing review produces a real exposure number or a polite estimate, because the measurement is only as good as the data behind it. A vague request returns a spend summary and a list of vendors, which is not enough to measure anything. A precise request returns the contracts, the deployment data and the audit history needed to reconcile entitlement against use. Framing that request well is an early and underrated step in software due diligence, and it sets the ceiling on how good the rest of the work can be.
The request has to be specific because the target will provide exactly what is asked for and rarely more. Ask for spend and the buyer gets invoices. Ask for entitlement and deployment on each publisher own metric, plus audit history and user data, and the buyer gets the raw material for a defensible license position. The categories below are the ones that matter, and the order reflects how much each one shapes the final exposure.
How to request software data from a target
To request software data from a target effectively, ask for five categories: contracts and entitlement, deployment and discovery data, user and access data, audit history, and the renewal calendar. Contracts and entitlement establish what the target is licensed to run. Deployment and discovery data show what is actually installed. User and access data expose named user and indirect access risk. Audit history reveals known and pending exposure. The renewal calendar sets the forward cost. Each category maps to a measurement the buyer needs, and missing any one leaves a hole in the position.
The single most valuable item, and the one most often left out of a generic request, is deployment data measured by a discovery tool rather than a manually maintained spreadsheet. The target own view of what it runs is usually optimistic, and the gap between the spreadsheet and the discovery output is frequently where the exposure lives. Asking specifically for discovery tool output, not a summary, is what makes the deployment side of the reconciliation defensible, as set out in building a software license position during diligence.
Why audit history is non negotiable
Audit history is the category buyers most often forget to request, and it is one of the most revealing. A past audit shows where a publisher has already found a gap and how it was settled, which tells the buyer where the estate is weak. A pending or active audit is a live exposure the buyer would be inheriting in full, and it changes the deal terms immediately. 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, exactly the kind of exposure that a request for audit history is designed to surface before it becomes the buyer problem.
How to frame the request inside the deal process
The data request has to fit the deal process, which means it goes through the data room and is scoped to what the target can realistically produce inside the window. A request that is too broad invites delay and a partial response. A request that is precise, prioritised and tied to named publishers gets answered, because the target understands exactly what is wanted. Prioritising which publishers to press first, when time is short, is covered in prioritising publishers in a time boxed diligence.
Key takeaways
- The measurement is only as good as the data, so the request sets the ceiling on the whole review.
- Ask for five categories: contracts and entitlement, deployment, user and access, audit history, and renewals.
- The most valuable item is discovery tool deployment data, not a manually maintained spreadsheet.
- Audit history is the category buyers most often forget, and it surfaces known and pending exposure.
- A precise, prioritised request tied to named publishers gets answered inside the deal window.
What to do when the data is incomplete
Targets rarely produce everything, so part of the skill is working with gaps. When deployment data is missing for a publisher, the buyer can ask for it directly, estimate a range from what is available and flag the assumption, or treat the gap itself as a risk to price. What the buyer should not do is assume the missing data means there is no exposure. A target that cannot produce a discovery report for its Oracle estate is more likely to be carrying exposure than less, because it has never measured it. Recording each gap and how it was handled keeps the position honest and defensible.
How the request connects to the deliverable
A well framed data request flows straight into the deliverable. Each category answered becomes a measured input, each gap becomes a flagged assumption, and together they produce the license position and exposure range the deal team uses. The request is the first link in a chain that ends in a number the buyer can price or indemnify, and the final form of that number is described in software due diligence deliverables. Getting the request right is what makes the rest of the chain possible.
Recommendations for buyers
- Write a precise data request covering contracts, deployment, user data, audit history and renewals.
- Ask for discovery tool output rather than a target maintained spreadsheet of what it believes it runs.
- Always request past and pending audit history, the category most often forgotten and most revealing.
- Prioritise the request by publisher when time is short, pressing the highest exposure vendors first.
- Treat missing data as a risk to price, not as evidence that no exposure exists.
A precise data request is the quiet foundation of the software due diligence method, because everything downstream rests on it. The full workstream is delivered through our software due diligence service.