Vendor specific diligence is the discipline of reading a target software estate publisher by publisher rather than as a single spend line, because the risk in an Oracle deployment looks nothing like the risk in a SAP, Microsoft, or IBM one. A generic software checklist treats every contract the same way. Vendor specific diligence asks the question each publisher actually audits on, then tests the target deployment against that publisher own metrics. It is the difference between a tidy vendor list and a number the deal team can defend, because the major publishers behind post deal audits each have a signature trap.
This guide sets out where the exposure hides for the publishers that drive most post close audits, and how to test for each one inside a deal timetable. It is part of the core software due diligence method and connects to M&A software audit risk. When the clock is tight, pair it with prioritising publishers in a time boxed diligence and quantifying software audit exposure before you sign.
Why vendor specific diligence beats a generic checklist
Each major publisher monetises a different ambiguity. Oracle audits on processor counting, options and management packs switched on by default, and Java usage that crept in without a license. SAP audits on indirect or digital access and named user classification. Microsoft audits on server and client access licensing, SQL Server core counts, and cloud subscription true ups. IBM audits on sub capacity reporting and the processor value unit. A single checklist that asks whether the target is licensed cannot catch any of these, because each one is compliant on the surface and exposed in the detail. Vendor specific diligence goes straight to the detail that the publisher itself would test.
Oracle: processors, options, Java, and the unlimited agreement
Oracle exposure rarely comes from missing licenses. It comes from how cores are counted on virtualised and cloud infrastructure, from database options and management packs that are installed and active without a matching entitlement, and from Java usage that became chargeable under subscription terms. The unlimited license agreement adds its own trap: the certification at the end of the term fixes the entitlement, and a target mid way through one carries a future true up that few sellers disclose. Test the deployment against Oracle own counting rules, not against the invoice, because the invoice reflects what was bought, not what is running.
SAP: indirect access and named user classification
SAP exposure centres on indirect or digital access, where third party systems read or write SAP data and trigger license requirements the target never counted, and on named user classification, where users sit in a more expensive category than their actual use justifies. The public record makes the scale concrete. As of June 2026, SAP was reported to have pursued AB InBev for around 600 million dollars and Diageo for around 60 million over disputed and inherited licensing tied to indirect access, according to coverage of those disputes. Confirm current figures and outcomes with primary sources. The lesson for a buyer is that a clean SAP invoice can sit on top of a nine figure indirect access exposure that only a vendor specific read will surface.
Key takeaways
- Each major publisher monetises a different ambiguity, so vendor specific diligence tests the target against each publisher own metrics, not a generic checklist.
- Oracle risk hides in core counting, options, Java, and unlimited agreement certification. SAP risk hides in indirect access and user classification.
- Microsoft and IBM risk hides in client access licensing, SQL core counts, and sub capacity reporting that fails the publisher own rules.
- Broadcom has made VMware a fast growing post deal risk through subscription repackaging and steep renewal uplifts, as of June 2026.
Microsoft and IBM: licensing complexity that fails quietly
Microsoft exposure builds across server and client access licensing, SQL Server core counts on virtual hosts, and cloud subscription true ups where deployed usage outran the committed quantity. The estate is usually large and the rules change often, so the gap is rarely one big breach and more often many small ones that sum to a material number. IBM exposure turns on sub capacity reporting through the license metric tool: where the reporting is incomplete or stale, IBM can charge at full processor capacity rather than the sub capacity the target actually used, which multiplies the bill. Both publishers reward a careful, deployment level read and punish a buyer that trusts the entitlement summary.
Broadcom, VMware, and the newer audit risks
The audit map has widened. Since Broadcom acquired VMware, virtualisation licensing has moved to subscription bundles with materially higher renewal pricing, which makes a target heavy on VMware a forward cost risk as much as a compliance one. Salesforce and ServiceNow have also grown more active on usage and edition compliance. Vendor specific diligence now has to cover these newer names alongside the traditional four, because a buyer that maps only Oracle, SAP, Microsoft, and IBM can still inherit a steep VMware renewal or a Salesforce overage that moves the forward run rate. Treat the publisher list as live and confirm the current posture of each one with primary sources, since vendor programmes change quickly.
Recommendations for buyers
- Rank the target publishers by audit likelihood and gap cost, and run a deployment level read on each of the top names rather than a single checklist.
- Test Oracle against its own core counting and options rules, and read any unlimited agreement for the certification true up before signing.
- Map SAP indirect access and user classification, and price the exposure as a range given the nine figure precedents.
- Add Broadcom for VMware, Salesforce, and ServiceNow to the publisher list, and model the renewal uplift, not just the compliance gap.
Sequencing vendor specific diligence inside a deal timetable
Vendor specific diligence has to fit a deal clock, so the order of work matters as much as the depth. Start with the two publishers that carry the largest exposure, usually Oracle and SAP, because a finding there can move the bid and the others rarely will. Use the first data room release to confirm which publishers are present and at what scale, then request the deployment evidence each one audits on, the core counts for Oracle, the interface list for SAP, the license metric tool data for IBM, the tenancy and core data for Microsoft. Reserve the management session for the questions the documents cannot answer, such as whether an Oracle unlimited agreement is mid term or whether a known indirect access exposure has ever been raised by SAP.
The output is a per publisher exposure, each expressed as a range with a confidence level, that rolls up into a single number the deal team can price. Where access runs out before a publisher can be fully tested, say so and carry it into the confirmatory checklist rather than guessing. A buyer that knows which publishers were tested, which were not, and how confident the team is in each, bids with far more conviction than one holding a single blended figure with no provenance.
Why an independent buyer side advisor runs vendor specific diligence
Vendor specific diligence demands knowledge of how each publisher audits and an incentive to use it on the buyer side. A reseller that earns on the publisher spend has no reason to shrink it, and the target will not surface a gap it has lived with. An independent, buyer side advisor with no affiliation to any publisher or reseller reads the estate publisher by publisher, prices each exposure against the publisher own metrics, and hands the deal team a number it can defend before signing and carry into reconciliation after close.