Stage one: what does the audit notification letter mean?
The audit begins with a formal notification, usually from GLAS, formerly LMS, citing the audit clause in your Oracle Master Agreement and a response window of usually 30 to 45 days. The letter sets a tone of inevitability, but it is the opening of a negotiation, not a verdict.
The right first move is to acknowledge receipt, route the matter to a single owner, and decline to commit to any scope, scripts or dates on the first call. A short, professional acknowledgement that confirms you will respond within the contractual window, and nothing more, is the correct reply. Everything after this stage is shaped by how disciplined you are now, because concessions made in the first week are hard to reverse later.
This is also the moment to read your own contract. The audit clause defines what Oracle can require, how much notice applies, and what your obligations actually are, and those terms are contract dependent. A buyer who knows their clause negotiates from the agreement; a buyer who does not negotiates from Oracle's description of it.
Stage two: how is audit scope set and negotiated?
Scope decides what Oracle can measure, and it is negotiable, so it is agreed in writing before any data moves. You confirm which legal entities, which products and which environments are in, and which are out, and you push back on a scope that reaches into systems with no Oracle footprint.
A merger, a cloud migration or a virtualization change often prompted the audit, so Oracle will try to scope toward those areas, where exposure is most likely. A tight scope is the single most valuable thing you set in the whole process, because anything outside it cannot become a finding. Vague scope, by contrast, lets the exercise expand as it goes, and every expansion is an opportunity for the number to grow.
Scope also covers method. You can agree how data will be gathered, in what format, and over what period, rather than accepting that Oracle's scripts are the only acceptable source. Settling method at this stage prevents arguments later about whether the data was even valid.
Stage three: what data does Oracle collect?
Oracle asks you to run its collection scripts and return the output, but running those scripts is a decision, not an obligation. The scripts can overcount across virtualization layers, reading a whole VMware cluster as licensable because the partitioning policy does not recognise VMware as hard partitioning.
We review script output before submission, correct overcounts, and where appropriate provide equivalent evidence drawn from your own records. What you submit here becomes the factual basis for the finding, so it is checked line by line first. Raw output sent without review is the most common reason a finding comes back far larger than the real position.
This stage rewards preparation. A buyer who already holds a clean map of the estate, the entitlements and the architecture can validate or replace script data quickly. A buyer who is assembling that picture for the first time under a deadline is far more likely to send something that overstates usage.
Stage four: how are preliminary findings presented?
Oracle presents preliminary findings as a single large number priced at list, and that number is an opening position, not a bill. It is designed to anchor the negotiation high, and the gap between it and the defensible figure is the opening offer, not an accident.
The usual contents are processor core shortfalls against the core factor table, options and management packs flagged as in use, cluster wide virtualization claims, Named User Plus undercounts, and disaster recovery mistakes around the 10 day rule. Each line is challengeable on its own terms. Recomputing the core factor, disputing options that were never operationally used, and rejecting policy based virtualization claims is where an independent line by line review typically removes 60 to 80 percent of the figure.
The discipline here is to treat the finding as a draft to be tested, not a statement to be answered. Every line gets a question: is the metric right, is the factor right, was this option ever really used, does the contract actually support this virtualization claim. Most lines do not survive that scrutiny intact.
Stage five: how is the settlement negotiated?
Settlement turns the defended figure into a commercial close, and timing is leverage. Oracle's quarter and year end create pressure on the sales side that a prepared buyer can use, because a sales team that needs to book a deal before a deadline has reasons to be flexible that it does not have mid quarter.
Findings are often steered toward a ULA renewal, an OCI commitment or a Java Universal Subscription rather than a cash payment, because those outcomes serve Oracle's strategy beyond the audit. You decide whether any of those trades serves you, or whether a clean settlement is better. A trade that looks like a discount can lock in spend you did not want, so each option is weighed on its own merits.
The aim is a close you can live with and a clean record, not just a lower number on this audit. A good settlement also fixes the underlying issue, by disabling unused options, correcting metrics and documenting the agreed position, so the next review starts from a defensible baseline.
What are your rights across the stages?
Across every stage your rights come from the contract, and they are consistent: agree scope, control the data, take time to verify, and negotiate the close. Oracle's policy documents do not override the signed agreement, and where they conflict, the agreement wins.
Keeping control means routing the audit through one owner, documenting every agreement in writing, and never conceding a number before it has been tested. The buyer who does this turns an inspection back into the negotiation it always was. For the wider picture, read why an audit, a license review and a business assessment are the same thing.
A worked timeline
Indicative timeline for a mid sized estate. Actual durations are contract dependent.
| Stage | Typical duration | Buyer move |
|---|---|---|
| Notification | Day 0 | Acknowledge, single owner |
| Scope | Within the 30 to 45 day window | Agree scope in writing |
| Data collection | 2 to 6 weeks | Review before submission |
| Findings | 4 to 8 weeks | Challenge line by line |
| Settlement | Timed to Oracle's quarter | Close on your terms |
What happens if you miss the response window?
Missing the response window weakens your position but does not end the negotiation, and it is recoverable with the right handling. The window in the audit clause is usually 30 to 45 days, and it is negotiable, so the first step if the date is tight is to ask for an extension in writing rather than to rush a flawed response. Oracle would generally rather agree a workable timeline than escalate a cooperative buyer.
The real risk of missing the window is not a penalty clause, it is the loss of preparation time, which pushes a buyer toward returning raw script output just to show progress. That is the worst outcome, because it hands over unreviewed data that overstates usage. Far better to negotiate a realistic schedule and use it to build a defensible position than to meet a date with a number you cannot defend.
How do you keep control across all five stages?
You keep control by routing the whole audit through one owner, documenting every agreement in writing, and never conceding a figure before it has been tested line by line. Control is not a single decision, it is a discipline applied at every stage, from the acknowledgement of the letter to the signature on the settlement.
The buyer who keeps control treats each Oracle output as a draft to be challenged rather than a fact to be answered. Scope is agreed before data moves, data is reviewed before it is sent, findings are questioned before they are priced, and the close is timed to the buyer's advantage rather than Oracle's. Each of those moves is small on its own, and together they are the difference between an inspection and a negotiation.
What are your rights during data collection?
During data collection your rights center on choice of method and review of output, both of which are yours to exercise. Running Oracle's collection scripts is a decision, not an obligation, and where your contract does not compel a specific tool you can propose an equivalent that produces the same facts without the overcounting that scripts introduce across virtualization layers.
You also have the right to review and correct what is submitted. Script output can read a whole cluster as licensable, count options that were never operationally used, and miss the context that makes a number defensible. Reviewing the output, correcting clear errors, and documenting the basis for each correction is not obstruction, it is ordinary diligence, and it is the single most effective thing a buyer does between scope and findings.
How do you avoid triggering the next audit?
You avoid the next audit by closing this one cleanly and fixing the underlying issues, not just lowering the number. A settlement that disables unused options, corrects the metric, and documents the agreed position leaves a defensible baseline, so the next review starts from evidence rather than uncertainty.
Beyond the settlement, the buyers who are audited least are those who keep a current map of their estate, watch the known triggers such as virtualization changes and cloud migrations, and run a periodic internal review so that surprises surface on their own terms. Audits are a sales channel, and a buyer who is visibly in control of their position is a far less attractive target than one who is not.
The next step
This article is part of our Oracle Audit Fundamentals cluster. Read the pillar, the Oracle audit defense guide, for the full picture, and these related reads: Oracle license review, audit and business assessment, how long an Oracle audit takes. For the engagement, see our Oracle audit defense service and contact us.