The Oracle Audit Defense Handbook 2026.

RecommendationsFive moves for buyers

1. Treat the soft audit signal as the start of the audit.The soft audit, the customer satisfaction call, the architecture review, and the cloud readiness assessment are all data gathering exercises for the Oracle LMS pipeline. Engage buyer side counsel the moment one of these signals appears, not the moment the formal audit letter arrives. The window between soft signal and formal letter is typically 90 to 180 days, and that window is the most productive preparation period in the entire audit timeline.
2. Negotiate the scope before negotiating the findings.The audit scope letter is where Oracle defines what will be measured, on which systems, over which time period. Buyers who treat the scope letter as fixed lose leverage they cannot recover later. The scope is negotiable, and it should be narrowed on geography, product, time window, and measurement methodology before LMS runs any script in your environment. A narrow scope produces a narrow finding, which produces a narrow settlement.
3. Never run the LMS measurement scripts unsupervised.Oracle LMS provides measurement scripts that customers are expected to run in their own environment and return the output to Oracle. The scripts work, but the interpretation of the output is where most over counting happens. Run the scripts in a controlled environment with buyer side analyst review of every machine and every license metric before any output is returned to LMS. Disaster recovery, development, test, and decommissioned hosts are the four categories where over counting is most common.
4. Settle in licenses you actually need, not in licenses Oracle wants to sell.Audit settlements are typically paid in Oracle licenses purchased at audit settlement pricing. The composition of that license purchase is negotiable. Oracle account teams will push the licenses they have on their quota, which are often products you do not actually deploy. Insist on settling in the products that match your actual usage, even if Oracle's opening proposal pushes other products. A settlement composed of licenses you do not need adds support obligations that compound for years.
5. Insist on a closure letter that bars future audits on the same scope.The closure letter is the contractual artefact that survives the audit. Its language determines whether a future Oracle audit can revisit the same period and same scope, whether the licenses purchased to settle are properly counted in future renewals, and whether any disputed findings are formally withdrawn or merely set aside. Boilerplate closure letters from Oracle do not protect the buyer. Negotiated closure letters do.

Section 01How Oracle audits work

An Oracle audit is a formal contractual procedure executed under the audit clause of the OMA, the Oracle Master Agreement. The clause gives Oracle the right to verify compliance with the licensing terms of the order documents executed under the OMA. The right is broad. It covers the products, the metrics, the deployment locations, the affiliates and subsidiaries, and the time period since the OMA was signed.

Although the audit clause itself is short, the procedure built around it is substantial. Oracle LMS, the License Management Services team, conducts the audit on Oracle's behalf. LMS is structurally separate from the Oracle account team that sells the customer licenses, but the two work closely together. The audit pipeline begins inside the account team and is handed to LMS once the account team has identified a target.

The pipeline starts with a signal. The signal can be a renewal coming up in 6 to 18 months, a ULA certification approaching, a cloud migration project the customer has announced, an acquisition that may have introduced unlicensed Oracle usage, or a customer satisfaction signal that suggests the customer is considering moving off Oracle. Once a signal is identified, the account team begins a discovery process designed to surface a potential compliance gap before the formal audit letter is sent.

That discovery process produces the soft audit. The soft audit looks like a friendly conversation about architecture, deployment, virtualisation strategy, or cloud readiness. The customer is asked questions about how Oracle is being used. The answers feed the LMS pipeline. By the time the formal audit letter arrives, Oracle already has a working hypothesis about where the compliance gap is. The formal audit is then conducted to confirm the hypothesis, document the finding, and convert it into a commercial demand.

Section 02The signals before the letter

The audit signals that precede the formal letter are the most important data in the audit defense process. Every signal that the customer answered without buyer side preparation is data Oracle is now using. Every signal that the customer did not answer is leverage the customer still has.

The six common signals

• Architecture review request from the Oracle account team, often framed as part of a cloud strategy conversation
• Customer satisfaction survey conducted by Oracle that includes questions about deployment scale
• Java compliance enquiry, typically triggered when an account team learns that Java is in use without a current Oracle Java SE Universal Subscription
• Virtualisation discussion focused on VMware, where Oracle is gathering data on potential partitioning disputes
• Pre-renewal review where Oracle proposes to baseline current usage before the renewal proposal
• ULA certification preparation calls where Oracle requests detailed deployment data ahead of the certification submission

None of these conversations are illegitimate on their face. They become problems only when answered without preparation, without buyer side coordination, and without an understanding that the answers feed the audit pipeline. A defensible response to each of these signals is possible, but the response should be designed with audit risk in mind, not delivered casually by whichever Oracle DBA happened to take the call.

Section 03The scope letter

The formal audit begins with a scope letter from Oracle LMS. The scope letter identifies the products in scope, the affiliates in scope, the geographic scope, the time period, and the proposed measurement methodology. The standard Oracle scope letter is broad. It typically claims rights over every Oracle product the customer has ever licensed, across every affiliate, in every country, for the full duration since the OMA was signed.

That breadth is the opening position. It is not the final scope. Buyers have the right under the OMA to negotiate the scope of the audit, the timeline of the audit, and the methodology of the audit. Buyers who negotiate at this gate settle materially lower than buyers who accept the scope as drafted.

The scope moves

• Narrow the product list to products the customer actually deploys, supported by the licence catalogue
• Narrow the geography to entities directly party to the OMA, excluding affiliates governed by separate agreements
• Narrow the time period to the most recent two years rather than the full life of the OMA
• Require LMS to specify the measurement methodology in writing before any script is run
• Require LMS to share the measurement scripts in advance for buyer side review
• Set a single point of contact on the customer side and require LMS to route all communications through that contact

Section 04The measurement phase

The measurement phase is where Oracle quantifies the compliance gap. The instruments are Oracle LMS measurement scripts. There are different scripts for different products. Database has its own script. Middleware has its own. Java has the Oracle Java SE Audit Tooling. EBS, PeopleSoft, JDE, and Siebel each have their own measurement approach, often manual user count exports rather than scripts.

The scripts produce output. The output is interpreted by LMS against the licence catalogue and the deployment inventory. The interpretation is where most disputes arise. The script does not produce a license count. It produces raw data. LMS then converts that raw data into a license count using assumptions that are not always shared with the customer.

The four common over counts

• Disaster recovery hosts counted as production licenses, when the contract allows passive DR rights
• Development and test hosts counted at full production license rates, when Oracle's own policies allow lower cost arrangements
• Decommissioned hardware still in inventory and reported by the script, when the hardware is not actually running Oracle
• Java agents embedded in third party software that ships with a Java runtime, counted as customer Java SE installations

Section 05The findings letter

After measurement, LMS produces a findings letter. The findings letter sets out the alleged compliance gap, the products and quantities at issue, the methodology used to arrive at the number, and the proposed remediation. The remediation is almost always a purchase of additional Oracle licenses, sometimes with a backdated support component, sometimes with a forward looking cloud subscription substituted for the perpetual license purchase.

The findings letter is the document that determines the size of the settlement. It is also a document that buyers have the right to challenge. The challenge runs through three categories: methodology challenge, fact challenge, and contractual challenge.

The three challenges

A methodology challenge disputes the way LMS interpreted the measurement output. The challenge requires the buyer to demonstrate that a different interpretation of the same output yields a smaller license obligation. A fact challenge disputes the underlying data, typically by demonstrating that hosts were decommissioned, that environments were not actually running Oracle, or that the script reported software that was not deployed for production use. A contractual challenge disputes the right of Oracle to assert the finding, typically by reference to specific clauses in the OMA, order documents, or amendments that bar Oracle from counting the disputed deployment.

The most effective audit defenses combine all three. Methodology, fact, and contractual challenges layered together produce the largest compressions from initial finding to final settlement.

Section 06The settlement

The settlement is the commercial close to the audit. It typically takes the form of a license purchase at audit settlement pricing, a cloud subscription that substitutes for some or all of the license purchase, or a renewal restructure that absorbs the audit obligation into a multi year deal.

Each settlement structure has tradeoffs. License purchase carries forward support obligations for the life of the licenses. Cloud subscription carries forward subscription obligations for the term of the cloud deal. Renewal restructure embeds the audit settlement in the renewal baseline, which then drives every future renewal calculation.

The settlement composition

The composition of the settlement matters as much as the headline number. A $2M settlement composed of products the customer actually deploys is materially better than a $1.5M settlement composed of products the customer does not deploy and will not renew. The cheaper headline number creates a worse total cost of ownership.

Section 07The closure letter

The closure letter is the contractual close to the audit. It is the document that, in theory, prevents Oracle from auditing the same scope again. In practice, the strength of that prevention depends entirely on the language of the letter.

A weak closure letter says only that the current audit is concluded and that the settlement license purchase has been made. It does not bar Oracle from initiating a new audit on the same scope, with the same methodology, six months later. A strong closure letter bars exactly that. The strong letter specifies the products audited, the time period covered, the methodology applied, and the finding accepted, and it states that no further audit may be initiated on the same scope until a defined time period has elapsed, typically 36 months.

The closure letter checklist

• Identify the audit by its formal reference number and the date range
• State the products audited and the metrics applied
• State the deployment scope, including geography and affiliates
• State the time period covered by the audit and barred from re audit
• State the settlement licenses purchased and their effective dates
• State that all disputed findings are released and that Oracle has no further claim arising from the audit
• State that the customer reserves any rights with respect to the audit methodology beyond the matters resolved