Why Oracle's Initial Findings Are Always Overstated

When Oracle delivers its preliminary compliance findings, the number on the first page is rarely the number you will ultimately pay. Oracle's LMS (License Management Services) methodology is engineered to apply worst-case interpretations at every step: every enabled database option is treated as actively used, every processor core is counted at full capacity regardless of actual workload, and virtualisation environments are assessed using the most aggressive partitioning rules available.

The structural reality is that preliminary findings overstate actual exposure by 30 to 60 percent in the majority of cases. Oracle's audit team is commercially motivated — the findings document is a negotiating instrument, not an independent technical assessment. Understanding this changes how you should respond from the very first communication.

Organisations that accept Oracle's findings at face value and pay without challenge consistently overpay. Those that mount a structured, evidence-based challenge — typically with support from Oracle audit defence specialists — consistently reduce claims to a fraction of the original figure. The difference between these outcomes is not luck — it is methodology.

The Five Most Common Sources of Oracle Over-Counting

1. Virtualisation Counting Errors

Oracle's virtualisation licensing policy requires a full physical host to be licensed when using non-Oracle-approved virtualisation technology, such as VMware vSphere, unless hard partitioning is in place. However, LMS scripts frequently misidentify the partitioning technology or fail to detect correctly configured VMware restrictions that would reduce the licensing requirement. Many organisations have valid hard partitioning configurations that LMS scripts do not recognise, resulting in entire physical hosts being counted where only a subset of cores is in scope.

Challenge this by providing the full hypervisor configuration documentation, vMotion policy records showing VMs cannot migrate to unlicensed hosts, and CMDB records corroborating the partitioning approach. Correctly configured hard partitioning removes the host-wide counting requirement and dramatically reduces processor licence exposure.

2. Database Option Misclassification

Oracle database options — Advanced Compression, Partitioning, Advanced Security, Diagnostics and Tuning Pack, Real Application Clusters — are licensed separately from the base database product. LMS scripts detect whether an option's features have ever been invoked, even a single time during the data collection period. A DBA running a diagnostic query that briefly activated the Diagnostics Pack is treated identically to an organisation running Diagnostics Pack in production at scale.

For each flagged option, produce a detailed usage log showing the date, duration, user account, and business context of every invocation. If the option was enabled accidentally or used once during testing, this evidence substantially changes the commercial discussion. Disabling options going forward and providing a credible remediation plan further strengthens the challenge position.

3. Decommissioned and Inactive Servers

LMS scripts capture a point-in-time inventory from the systems they scan. They cannot distinguish between production servers running live Oracle software and servers that have been decommissioned, are in the process of being migrated, or are powered on but running no active Oracle workloads. Preliminary findings frequently include hardware that is no longer in use or was already scheduled for retirement before the audit was initiated.

Provide signed decommissioning certificates, infrastructure change records from your ITSM system, and network evidence showing the servers in question were offline or inactive at the time of the audit. Removing decommissioned hardware from the scope can reduce processor licence counts by 20 to 40 percent in organisations with large legacy estates.

4. Entitlement Attribution Errors

Oracle's audit process requires cross-referencing your current software deployment against your historical licence entitlements. This is more complex than it sounds. Licences acquired through mergers and acquisitions, transferred between legal entities, re-attributed following contract amendments, or purchased through Oracle's ULA certification process all require specific evidence to apply correctly. LMS auditors frequently apply the wrong entitlement to the wrong deployment, creating apparent shortfalls that do not exist when the full contractual history is reviewed.

Compile your complete Oracle Master Agreement history, all Order Documents, ULA certification letters, and any contract amendments that affect entitlement. Present these to challenge specific line items where Oracle has applied the wrong licence metric, failed to recognise a historical purchase, or overlooked licences acquired through a subsidiary.

5. Support and Maintenance Contract Gaps

Oracle audits assess both licence compliance and support coverage. Oracle's standard support fees increase by 8% per year — a $1 million support obligation today becomes $1.47 million in five years without renegotiation. This compounding trajectory is a core reason Oracle pursues support gap claims aggressively: reinstating lapsed support at current rates plus back-support at the 8% escalated rate produces significant revenue for Oracle. Understanding this dynamic is essential when evaluating whether to challenge, settle, or walk away from support-related audit findings.

Servers running Oracle software under lapsed, cancelled, or incorrectly attributed support contracts create a separate category of exposure. However, Oracle frequently includes support gap claims that are incorrect — attributing support lapse to a server that was actually covered under a different contract number, or failing to recognise that a support contract renewal was processed through a different procurement route.

Cross-reference every server in Oracle's support gap findings against your internal CSI (Customer Support Identifier) records, your Oracle Support portal history, and your procurement records. Support gaps that cannot be verified against your contractual documentation are challengeable in the same way as licence gaps.

Facing an Oracle audit? Get independent expert support before you respond.

We have defended 200+ Oracle audits. Clients pay 2 to 3 times less than those without support.
Request Audit Support →

The Challenge Process: Phase by Phase

Phase 1: Do Not Respond Immediately

Oracle's standard audit process provides approximately 45 days to respond to preliminary findings. Use every day of this window. An immediate response without thorough internal analysis is one of the most damaging mistakes organisations make. The 45-day window is your opportunity to assemble a structured challenge, not a deadline to accept or reject a number.

In the first two weeks, conduct your own parallel assessment. Run an independent licence position analysis using your own internal tools or a third-party adviser. This parallel assessment gives you a defensible counter-position on every line item in Oracle's findings before you engage in any substantive discussion.

Phase 2: Conduct Your Own Technical Verification

Commission an independent technical review of every server flagged in Oracle's Oracle Server Worksheet (OSW). Compare Oracle's processor and core counts against your enterprise CMDB, hypervisor management consoles, and server telemetry data. For virtualised environments, document the partitioning configuration in detail for every flagged host.

For database options, review the AWR (Automatic Workload Repository) data and DBA_FEATURE_USAGE_STATISTICS views for every flagged database. Determine whether each flagged option was intentionally used in production, accidentally invoked, or never meaningfully deployed.

This technical verification forms the evidentiary backbone of your challenge. Every counter-claim you make must be supported by documentation that your own technical team can stand behind.

Phase 3: Prepare a Formal Written Rebuttal

A well-structured rebuttal document challenges Oracle's findings line by line, separates disputes into categories (technical errors, methodology disputes, entitlement attribution errors), and presents supporting evidence for each challenge. The rebuttal should be prepared with legal review to ensure that nothing in the document inadvertently creates admissions that work against you in the settlement discussion.

The rebuttal is not a Oracle contract negotiation letter. It is a technical and contractual document that establishes the factual record. Confusing the rebuttal phase with the negotiation phase is a common error that weakens the challenge position.

Phase 4: Engage Oracle's Settlement Team

Once Oracle has reviewed your rebuttal, they will schedule a meeting with their Global License Advisory Services (GLAS) team — Oracle's commercial settlement function. This is the negotiation phase. At this point, Oracle's initial claim has already been weakened by your formal rebuttal, and the commercial discussion starts from a fundamentally different position than if you had entered negotiation without challenging the findings.

In the settlement discussion, organisations with independent expert support consistently achieve better outcomes. Oracle's GLAS team is experienced, commercially aggressive, and negotiates hundreds of settlements per year. Having an adviser who has seen the full range of Oracle settlement tactics is a material advantage.

What Oracle Cannot Force You to Do

Many organisations respond to Oracle audits from a position of perceived legal obligation that is broader than the actual contractual requirement. Understanding the limits of Oracle's audit rights is essential for maintaining control of the process.

Oracle's standard licence agreement audit clause requires reasonable cooperation and access, but does not require you to accept Oracle's methodology without question, respond to informal compliance enquiries outside the formal audit process, provide documentation beyond what is necessary to verify the specific claims Oracle is making, or accept Oracle's interpretation of ambiguous contractual terms.

Oracle cannot compel you to run LMS scripts on systems not covered by the Oracle agreements under audit, provide access to non-Oracle environments, or respond within shorter timeframes than those specified in your agreement. If Oracle's audit request exceeds these boundaries, push back in writing and request the specific contractual basis for each request.

"Oracle's preliminary findings are the opening bid in a commercial negotiation, not the closing price. Every number on that document is the product of assumptions that can be tested, methodology that can be challenged, and entitlements that may not have been applied correctly."

Building Your Challenge Team

The organisations that achieve the largest reductions in Oracle audit claims are those that assemble the right team from the outset. An effective challenge team requires a technical lead who understands Oracle database architecture and can interpret LMS script outputs, a licence specialist from our Oracle licensing advisory specialists team who can map the deployment data against the contractual entitlement history, legal counsel who can review the rebuttal document and ensure no inadvertent admissions, and a commercial lead who manages the Oracle relationship and the settlement negotiation.

Independent third-party advisers who have defended Oracle audits at scale bring a specific advantage: pattern recognition. Oracle's audit methodology uses consistent techniques across engagements, and advisers who have seen hundreds of Oracle audit findings can identify over-counting patterns, methodology errors, and entitlement misattributions that an internal team seeing their first Oracle audit would not recognise.

Six Priority Actions When You Receive Oracle's Findings

Do not acknowledge findings as accurate in any written communication. Any written statement that implicitly accepts Oracle's figures — even as a starting point for discussion — creates a documented position that Oracle will reference in subsequent negotiations.

Assemble your licence entitlement history immediately. Pull every Oracle Order Document, Master Agreement, Oracle ULA advisory certification letter, and contract amendment. The entitlement record is the foundation of your challenge and must be complete before you respond.

Run your own parallel technical assessment. Do not rely solely on Oracle's OSW data. Conduct your own server inventory, option usage analysis, and virtualisation configuration review independently.

Identify the three to five largest line items and focus your challenge there. Oracle's audit findings follow a Pareto distribution — the majority of the claimed exposure is typically concentrated in a small number of items. Winning the biggest disputes has disproportionate impact on the total settlement figure.

Engage Oracle audit defence specialists before the formal response. Once you submit a formal response, the direction of the challenge is set. Getting expert input before the first formal communication allows you to frame the challenge correctly from the outset.

Document everything. Every phone call, every email, every meeting with Oracle's audit and GLAS teams should be documented with written follow-up notes. The paper trail protects you if Oracle's settlement discussions become adversarial.

Oracle Audit Defence Resources

Also see the Oracle licensing knowledge hub for guides on ULA, support exits, and database licensing.

Access our complete Oracle audit defence kit — scripts, rebuttal templates, and challenge frameworks used in 200+ Oracle audit engagements.