An Oracle preliminary audit finding arrives inflated at list price because it is an opening position, not a bill, and an independent line by line review typically cuts that claim 60 to 80 percent.
Why is the preliminary number an opening position?
The preliminary number is an opening position because an Oracle audit is a negotiation dressed up as an inspection. The figure in the first report is the largest defensible number Oracle can assemble from the data submitted, not the amount you owe. Treating it as a bill is the single most expensive mistake a buyer can make, because it concedes the negotiation before it has begun.
Oracle audits run through GLAS, formerly LMS, under the audit clause in the Oracle Master Agreement, with a 30 to 45 day response window. The preliminary report is a draft that opens that window. Nothing is owed until you agree it, and every line in it is open to dispute against your contract and your entitlements.
Why is everything priced at list?
Everything is priced at list because list is the highest number on the page and the easiest one to defend internally at Oracle. Real Oracle purchases almost never happen at list. Volume, timing, competitive pressure and existing relationship all pull the real price well below it. A finding built at list therefore starts from a ceiling no buyer would ever have paid in a normal purchase.
List pricing also compounds. When a finding assumes the most expensive edition, the broadest metric and the full list rate, three inflated assumptions multiply into a number several times larger than any defensible exposure. The buyer move is to challenge each assumption separately, because each one is a separate negotiation.
What inflates the number most?
Four mechanisms inflate Oracle findings more than any others, and each has a known buyer answer. Processor core shortfalls counted against the core factor table, options and management packs enabled by accident, cluster wide virtualization claims, and Named User Plus undercounts against minimums together account for most of the gap between the opening number and the defensible one.
| Inflation driver | Buyer move |
|---|---|
| List price on every line | Price against your own contract and historic discount, not list |
| Options enabled by accident | Show the feature was never used and was disabled on discovery |
| Cluster wide virtualization claim | Test the policy claim against the signed contract, which beats policy |
| Named User Plus undercount | Recount real users against the contract minimums, not assumed peaks |
Options are a common surprise. A single Enterprise Manager click can trigger Diagnostics or Tuning Pack, and many options install by default. An accidental flag is not the same as deployed use, and the evidence usually supports the buyer once it is gathered carefully.
Why does Oracle build it this way?
Oracle builds findings this way because the audit is also a sales channel. Findings feed ULA renewals, OCI commitments and Java Universal Subscriptions, and analysts estimate 20 to 30 percent of Oracle's on premises license revenue flows from audits. A large opening number creates room to trade a settlement for a cloud commitment or a subscription the customer did not previously want.
None of this is an accusation. It is the ordinary economics of how the program runs, described factually so the buyer can respond to the mechanism rather than the pressure. The number is large by design, and a buyer who understands the design is no longer surprised by the size of it.
How much does a line by line review remove?
An independent line by line review typically removes 60 to 80 percent of a preliminary claim by stripping out the inflation one line at a time. The review reprices each item against the actual contract, removes options that were never used, tests every virtualization claim against the signed agreement rather than the partitioning policy, and recounts users against the real population. What remains is the defensible exposure, which is the only number worth settling.
Oracle's collection scripts can overcount across virtualization layers, so script output is reviewed before submission, and running the scripts at all is a decision rather than an obligation. Much of the eventual reduction is decided by what is submitted in the first place, which is why the review starts before any data leaves the building.
A worked example of the reduction
Consider an anonymized financial services firm whose preliminary finding opened in the high seven figures at list. The defense repriced every line against the firm's own agreement, removed two management packs that had been flagged but never used, and tested a cluster wide claim on a VMware estate against the contract, where the policy basis did not hold. The settled number landed roughly a quarter of the opening position. No client names, sector level example only, but the pattern is the point: the opening figure described a ceiling, not a debt.
The buyer moves, in order
Reducing an inflated Oracle finding follows a clear order: treat the preliminary report as an opening position, reprice every line against your own contract, remove options that were flagged but never used, test virtualization claims against the agreement, recount Named User Plus against the real population, and settle only the defensible number. Done in sequence, these moves are why an independent line by line review typically cuts a preliminary claim 60 to 80 percent.
Where to go next
This piece links up to the Oracle Audit Defense Guide. Keep reading across the cluster:
For a defensible read on your own opening number, book a strategy call, or read the Oracle Audit Defense Guide.