What is an Oracle preliminary audit report?
An Oracle preliminary audit report is the first formal statement of findings that GLAS produces after it has gathered measurement data from your estate, and it is an opening position rather than a settled debt. It lists where Oracle believes your deployment exceeds your entitlements, attaches a quantity to each gap, and prices the shortfall at list. The document usually arrives with a tone of finality, a large total, and a request to discuss next steps. None of that makes it a bill. It is the number Oracle would like you to start from, and the gap between that number and what you actually owe is the room in which the audit gets resolved.
The single most useful reframing on the day this report lands is to stop reading it as an invoice and start reading it as a draft. Every line rests on an assumption about what is installed, what was used, how the core factor table applies, and which contract governs. Each of those assumptions can be checked, and many of them will be wrong or overstated. Until each line has been validated against your real deployment and your signed agreement, the total is an estimate built to favour Oracle, not a figure you are obliged to accept.
Why is the preliminary number so high?
The preliminary number is high because it is assembled from raw script output, priced at full list, and read at the most aggressive interpretation available at every junction. Oracle audits are also a sales channel, and analysts estimate that 20 to 30 percent of Oracle on premises license revenue flows through audits. A large opening figure is functional. It creates the urgency that points a customer toward a commercial outcome that suits Oracle: a Unlimited License Agreement renewal, a commitment on Oracle Cloud Infrastructure, or a Java SE Universal Subscription priced per employee.
Three mechanics do most of the inflation. First, the collection scripts can overcount, particularly across virtualization layers, where a feature that ran on one host can be reported as in use across an entire cluster. Second, options and management packs are read as licensable wherever they register as enabled, even though a single click in Enterprise Manager can trigger Diagnostics Pack or Tuning Pack and many options install by default. Third, the whole estate is priced at list, with no discount, and often with backdated support stacked on top. Each mechanic is defensible to challenge, and together they are the reason a first number can be several times the eventual settlement.
The policy document is not the contract. Cluster wide virtualization claims and many options positions rest on Oracle policy papers that are weaker than the signed agreement. Where the contract is silent or more favourable, contract language beats policy, and that single distinction decides a large share of audit value.
What is inside a preliminary finding?
A preliminary finding is built from a small set of recurring components, and learning to read them separates the contestable from the genuine. A typical line names a product, a metric, a measured quantity, an entitled quantity, a shortfall, and a list price. The shortfall is simply the measured figure minus the entitled figure, so an error anywhere upstream of that subtraction flows straight into the total. The job of a buyer side review is to test each input rather than the output.
The metric matters as much as the count. Oracle Database is licensed by Processor or by Named User Plus, and the same server produces very different numbers depending on which metric and which core factor apply. A Processor calculation multiplies physical cores by the core factor from the published table, and a misapplied factor changes the result before any usage is considered. A Named User Plus calculation must clear per processor minimums, and undercounting against those minimums is one of the classic findings. Options sit on top of the database license and are counted on the same metric, so an options error inherits the database error beneath it.
| Component | What to test |
|---|---|
| Product and metric | Is the right metric applied, and does it match your agreement |
| Measured quantity | Did the script overcount across virtualization or default installs |
| Entitled quantity | Are all your licenses and historic entitlements captured |
| Core factor | Is the correct factor from the published table applied |
| Price basis | Is this list, and is any backdated support justified |
Where does the 60 to 80 percent reduction come from?
The reduction comes from validating the findings line by line, because each correction removes a layer of overstatement that was baked into the opening number. A line by line review of Oracle findings typically cuts the claim 60 to 80 percent, and that figure is not a discount Oracle grants out of goodwill. It is the difference between the aggressive reading the preliminary report used and the accurate reading your deployment and contract support once each line is checked.
Several sources of reduction stack. Virtualization overcounts collapse when usage is mapped to the hosts where Oracle genuinely ran rather than to whole clusters. Options findings shrink when incidental activation is separated from production use, because a feature that registered once is not the same as a feature relied on in production. Core factor corrections lower Processor counts. Captured but uncounted entitlements raise the entitled quantity. And the contract versus policy distinction removes claims that rest on policy papers your signed agreement does not support. None of these moves is adversarial toward the people running the audit. Each simply insists that the number be accurate before it becomes a settlement.
A worked example
Consider an anonymized manufacturer running Oracle Database Enterprise Edition on a VMware cluster, with a preliminary finding of a high seven figure sum. The number is indicative and the situation is composite, but the pattern is the one we see repeatedly.
| Step | Effect on the claim |
|---|---|
| Opening preliminary report at list | Baseline, set at 100 |
| Map virtualization to genuine hosts | Removes the cluster wide overcount |
| Separate incidental options from production use | Removes packs never relied on |
| Correct the core factor and capture entitlements | Lowers Processor counts and raises entitlement |
| Apply contract terms over policy papers | Removes claims the agreement does not support |
| Validated position | Lands in the 20 to 40 range of the opening number |
The arithmetic is deliberately simple, because the point is not a precise percentage. The point is that the opening number and the validated number are different documents, and the distance between them is recovered by method, not by argument. The figures here are indicative and any real estate is reviewed against the signed contract and the actual measurement data.
What is the buyer move?
The buyer move is to refuse to negotiate against the preliminary total and instead negotiate each line down to its accurate value first. Ask Oracle for the basis of every finding: the script output it relied on, the metric it applied, the core factor it used, and the contract clause or policy paper it cites. Reconcile that basis against your own measurement and your own entitlement records. Correct the virtualization overcounts, the options activations, the core factors, and the missed entitlements. Then apply your contract over Oracle policy wherever the two diverge. Only once you have a validated position should the conversation turn to commercial resolution.
This also protects you from a common trap. Oracle frequently offers to make a large preliminary finding disappear in exchange for a forward commitment, a ULA, an OCI deal, or a Java subscription. That can be a reasonable outcome, but only when measured against the validated exposure, not the opening number. Splitting the finding from the deal keeps the two negotiations honest. For the full sequence from letter to close, read the Oracle audit defense guide, and for the moments either side of this report, see who GLAS is and why they audit and how to run the audit kickoff call.
If a preliminary report has landed, a short buyer side review will tell you how much of it is real. We reduce your Oracle exposure or we reimburse our service fee, on a Fixed Fee or Gainshare basis with no risk to you.
FAQ
Is an Oracle preliminary audit report a final bill? No. It is an opening position priced at list, and a line by line review of the findings typically cuts the claim 60 to 80 percent before any settlement is agreed.
Why is the preliminary number so high? It is built from raw script output at full list price with options and virtualization read at their most aggressive, designed to create urgency toward a ULA, an OCI commitment or a Java subscription.
Should I pay the preliminary finding? Not before validating it. You are entitled to see the basis for every line, correct the overcounts, and apply your contract terms before any number becomes a settlement.