Building an audit defensible license position post close is the single most valuable thing a buyer can do in the months after a deal completes. The combined estate now carries entitlements from two sources, deployment that has shifted during integration, and at least one publisher whose compliance team has noticed the change of ownership. A defensible position turns that uncertainty into a documented, evidence backed record that ties what the estate is entitled to against what it actually runs. When the audit notice arrives, and after a deal it usually does, the buyer already holds the answer rather than scrambling to assemble it under deadline. This page sets out how to build that position, as a child of the cluster on M&A software audit risk.
Building an audit defensible license position post close begins with entitlement
The foundation of any defensible position is the entitlement record, the proof of what the combined entity is actually licensed for. This is the part the seller almost never kept in usable form. Ordering documents are scattered, amendments are missing, and the link between a contract signed years ago and the software running today has been lost. The first task is to rebuild that record from primary documents, the original agreements, order forms, and amendments, and to establish which of them transferred under the deal structure. A buyer that cannot prove entitlement cannot defend anything, because the publisher will simply assert that nothing was licensed and demand payment for everything deployed. Entitlement is the anchor, and it must be reconstructed from source rather than taken on faith from a spreadsheet the seller handed over.
Verify deployment, do not assume it
The second pillar is the deployment baseline, the verified record of what is actually installed, enabled, and used across the combined estate. This is where raw tool output is dangerous, because publisher measurement scripts overstate the position by design, counting environments at their widest scope and treating options as in use unless proven otherwise. A defensible baseline corrects for all of that. It strips out decommissioned servers, duplicate counts, and inactive users, isolates any footprint created by integration rather than inherited from the target, and records exactly how each number was derived. The point is not to understate, it is to measure accurately, because an accurate baseline is one the buyer can stand behind under scrutiny. The discipline of measuring on the buyer's own terms before sharing anything is the same one we describe in responding to an audit notice post close.
Evidence the configuration, especially virtualisation and options
The third pillar is configuration evidence, and it is where the largest audit findings are won or lost. Oracle, for example, counts every physical core in any server where its software can run, and on soft partitioned virtualisation that can mean an entire cluster rather than the host the database sits on. Oracle states this position in a published partitioning policy document, not in the contract, and as of June 2026 it remained the basis Oracle uses to scope virtualised environments. A defensible position captures dated evidence of host affinity rules, of which options are enabled, and of the actual boundaries of each environment, so the buyer can hold the measurement to the facts. The same logic applies to user classifications, indirect access, and named user counts across SAP, Microsoft, and IBM. Evidence that is captured and dated while the estate is under the buyer's control is far stronger than evidence reconstructed after a notice lands.
| Component | What it establishes | Evidence required |
|---|---|---|
| Entitlement | What the estate is licensed for | Contracts, orders, amendments, transfer terms |
| Deployment | What is installed and used | Verified baseline, decommission records |
| Configuration | Scope of environments and options | Affinity rules, option status, dated screenshots |
| Reconciliation | The gap, if any, between the two | Single mapped view, traceable to source |
Key takeaways
- A defensible position rebuilds entitlement from primary documents, because without proof of what is licensed nothing can be defended.
- The deployment baseline must be verified and corrected, not taken from raw publisher tool output.
- Dated configuration evidence on virtualisation and options is where the largest findings are contained.
- Reconciliation ties entitlement to deployment in one traceable view the publisher cannot easily move.
- The position is most valuable when built before the audit notice arrives, while the buyer holds the initiative.
Reconcile entitlement against deployment
The fourth pillar is reconciliation, the act of placing entitlement and deployment side by side and identifying the genuine gap, if any. This is the number that matters, and it is almost always smaller than the one a publisher will assert, because the publisher works from deployment alone and assumes the worst about entitlement. A reconciled view shows where the estate is fully covered, where it is over licensed and carrying waste that can be removed, and where a real shortfall exists that should be closed. Crucially, a shortfall identified through reconciliation can be closed at renewal pricing in a planned conversation, rather than at list price under audit deadline. The reconciliation is the heart of the defensible position, and it is the deliverable a buyer should be able to hand to any publisher with confidence.
Account for the deal structure
A defensible position has to reflect the deal as it was actually structured, because structure determines which entitlements transferred and on what terms. A stock purchase usually carries agreements across intact, so the buyer inherits both the licenses and any historic gap. An asset purchase or carve out can require fresh consent, a transfer fee, or relicensing entirely, which changes what the buyer is even entitled to. Change of control and anti assignment clauses can trigger consent, termination, or repricing, and the structure decides which of those clauses bite. A position built on the seller's pre deal estate, rather than on the contracts that actually bind the buyer after the structure is applied, is not defensible at all. The interaction between structure and entitlement is set out in audit clause review in inherited contracts.
Recommendations for buyers
- Rebuild entitlement from source. Reconstruct the licensed position from original contracts and orders, not from a handed over spreadsheet.
- Verify, do not assume, deployment. Correct raw tool output for decommissioned systems, duplicates, and integration footprint.
- Capture configuration evidence now. Date the affinity rules, option status, and environment boundaries while you control the estate.
- Reconcile to one view. Produce a single traceable record that ties entitlement to deployment and isolates the genuine gap.
- Assign an owner. Give the position a named owner and a refresh cadence so it does not decay after integration.
Prioritise the publishers that audit after deals
A combined estate may run dozens of vendors, but audit risk is concentrated. The publishers most likely to pursue a recently acquired company are Oracle, SAP, Microsoft, and IBM, with Broadcom increasingly active following its VMware acquisition, and Salesforce and ServiceNow rising. A defensible position should be built for these names first, because they carry the highest probability and the highest value of a post close audit. Spreading effort evenly across every vendor wastes time on low risk software while leaving the high risk publishers exposed. Sequencing the work by audit likelihood is what turns a large, slow exercise into a focused one that protects the buyer where it matters, an approach that connects directly to preventing the post close audit before it starts.
Maintain the position so it stays defensible
A license position is not a one off document. It decays the moment the estate changes, and after a deal the estate changes constantly through consolidation, migration, and new deployment. A defensible position needs a named owner, usually in software asset management or procurement, a refresh cadence tied to the integration milestones, and a controlled record of changes so that every adjustment is dated and traceable. A position that is built once and then abandoned is worth little when the audit arrives two years later. The work of building it is also the work of operationalising it, which is why this discipline sits at the centre of a buyer side defense rather than as a standalone project. The broader defense it supports is described in defending a software audit after an acquisition. We build and maintain these positions on the buyer side only, paid solely by the acquirer.