Enterprise Software Audit Preparation Checklist: 30 Steps Before the Auditors Arrive

Gather every signed contract, order form, purchase order, and addendum for each major vendor. Include original agreements, amendments, and any side letters. Gaps in your contract documentation are gaps in your entitlement defence.

Create an entitlement register documenting exactly what you are licensed to use — processor licences, named users, employee metrics, device licences. For Oracle, this means mapping each product to its licence metric. For SAP, each user type and quantity.

Know exactly what audit rights your vendors have: how much notice they must give, what data they can require, and what limitations exist on audit frequency and scope. Oracle's audit rights are broad; SAP's are more prescribed. These clauses define what you must provide and what you can legitimately decline.

Know which products are approaching or have passed vendor support end dates. Running software beyond extended maintenance windows creates both support exposure and potential licence compliance issues that can appear as audit findings.

Licences acquired through M&A activity require explicit contractual assignment to be valid. Licences used by an acquired company before proper assignment can represent exposure. Review all acquisition integration documentation for gaps.

Ensure you have documentary evidence for every licence purchase: invoices, licence certificates, order confirmations. Verbal agreements and informal email approvals are not licence entitlement — if you can't document it, you likely can't defend it in audit.

Use your SAM tool (ServiceNow, Flexera, Snow Software, or equivalent) to discover all installed software instances across on-premises, virtual, and cloud environments. The scan must cover all devices — endpoints, servers, VMs, containers — including assets that may not be on the standard management domain.

Oracle's licensing rules for virtualised and cloud environments are uniquely complex and are the most common source of Oracle audit findings. Identify every server running Oracle software and document whether it is physical, VMware, AWS, Azure, or OCI — each has different licensing implications. The Oracle cloud licensing rules are particularly punitive.

For IBM products licenced on sub-capacity terms, ILMT (IBM Licence Metric Tool) or SLMT must be continuously running and generating reports. Gaps in ILMT coverage — servers not reporting, scan failures, configuration errors — eliminate your right to sub-capacity licensing and can result in full-capacity billing for all unlicensed periods. This is a contractual requirement, not a best practice.

Map every SAP system (ECC, S/4HANA, BW, CRM, SRM, PI/PO) and all third-party systems connecting to them. SAP's indirect/digital access exposure arises from integrations, not from direct named users. Knowing your integration landscape is prerequisite to understanding your true SAP compliance position.

Development and test deployments often use production software licences without proper authorisation or use licences that don't cover non-production use. Identify every non-production environment and verify its licence coverage — including whether developer licences are being used for builds that access production data.

Software running on versions that have exited standard support may have different licensing terms — or may not be covered by your current licence agreement at all. This is particularly relevant for Oracle Database versions prior to 19c and SAP ECC components approaching 2027 end-of-maintenance.

Oracle processor licensing is calculated based on physical core counts adjusted by Oracle's processor core factor table. For VMware environments, Oracle's policy (disputed by VMware) is that you must licence all physical cores in the VMware cluster unless using hard partitioning. Get independent legal advice before relying on soft partitioning defences.

Calculate your effective licence consumption against your entitlements using the same methodology the vendor will use. For Oracle, run the LMS data collection scripts in a test environment to understand exactly what they will see. For SAP, run USMM. For IBM, generate the ILMT PVU report. Know the number before they do.

Not all compliance gaps are equal. A 5% shortfall in named users is different from a fundamental mis-deployment of Oracle on VMware. Categorise each gap by: potential financial exposure, strength of your contractual defence, and available remediation options. This is the foundation of your audit negotiation strategy.

ULA (Unlimited Licence Agreement) certifications, unused licence credits from prior true-ups, rights granted in legacy agreements, or entitlements from acquisitions may offset findings. These require careful contractual analysis — vendors will not volunteer offset entitlements they've identified if you haven't claimed them.

Prior audit settlements sometimes include provisions that affect current compliance status — warranties about licence sufficiency, commitments to purchase additional licences, or representations about deployment configurations. These documents are relevant context for any new audit process.

Microsoft's annual true-up requires you to report deployment increases accurately. Under-reporting creates cumulative exposure. Review your Microsoft 365 deployment data — user counts, E3 vs E5 assignments, Azure subscription usage, Dynamics deployments — against your currently licenced quantities. The licence right-sizing process can significantly reduce your true-up number.

Several major vendor licence agreements contain genuinely ambiguous provisions that have never been tested in court — Oracle's virtualisation policy being the most prominent example. Independent legal advice on these ambiguities, obtained before an audit, is significantly more valuable than advice obtained after the audit notification arrives.

The most common source of audit vulnerability is licences purchased but not properly documented. Every software purchase should generate: a licence entitlement record in your SAM tool, a stored copy of the licence agreement, and a clear record of the metric and quantity purchased. Implement this before the audit — not as a response to it.

When software is removed from production, the associated licences should either be reallocated or noted as available inventory. Unused licences that appear as entitlements but have no corresponding deployment record are audit assets — they can offset findings in other areas. Don't let them disappear from your records.

When an audit notification arrives, who has authority to respond to the vendor? Who can commit the organisation to data sharing? Who decides whether to accept or challenge findings? These decisions should be made before the audit, not in the 48 hours after notification. An undefined response process means the vendor controls the pace and direction.

Indirect access, sub-licensing, BYOL rules, and virtualisation licensing are all areas where well-intentioned infrastructure decisions by non-licensing staff create audit exposure. Annual training on the major licence metrics for your top vendors reduces the rate of accidental non-compliance.

Run USMM, ILMT reports, Oracle LMS scripts, and Microsoft 365 licence reports on an annual cycle. The goal is not to fix compliance issues — it is to know your position so that any audit is not a discovery process but a validation exercise. The element of surprise belongs to you, not the vendor.

Audit outcomes are not purely compliance outcomes — they are commercial outcomes. A vendor's willingness to negotiate an audit settlement is influenced by your overall commercial relationship, renewal history, and strategic value as a customer. Know your commercial leverage before the audit discussion begins.

For Oracle, the LMS (Licence Management Services) team operates separately from the sales organisation and has a quota tied to audit findings. For SAP, the LAM (License Audit Management) process is similarly detached from account management. Understanding that the audit team and your account team have different incentives is essential to managing the dual-track relationship during an audit.

Vendors frequently initiate audits in the 6-12 months before a major contract renewal. The timing is not coincidental. An audit finding creates commercial pressure to resolve findings through a renewal agreement. Knowing this pattern allows you to anticipate audit risk in renewal cycles and negotiate from prepared positions rather than reactive ones.

Your ability to negotiate an audit settlement is affected by your strategic dependence on the vendor. An organisation with a credible migration path away from Oracle has more leverage in Oracle audit negotiations than one that just signed a 5-year Oracle Cloud commitment. Document your realistic alternatives before the commercial discussion begins.

The time to identify your external audit defence specialists is not after you receive the audit letter — it is 6-12 months before, during the preparation phase. Understand your options, brief potential advisors on your environment, and have engagement terms agreed so that activation is immediate when needed. We work on gainshare — you pay nothing unless we reduce your exposure.

When a vendor requests data, you have rights to control the format, scope, and method of data collection. Establish in advance what data you will provide directly, what data will be reviewed on-site, and what data you will challenge as outside the scope of contractual audit rights. Enterprises that accept every vendor data request without challenge consistently produce audit reports that overstate exposure.