Oracle Compliance Declaration and Reporting: What to Submit, When, and How to Protect Yourself

What Oracle Means by a Compliance Declaration

Oracle uses the term "compliance declaration" to describe the customer's formal statement of their Oracle software deployment — what is installed, where, on which hardware, and in what quantities. This declaration can arise in two contexts: as part of a formal LMS (Licence Management Services, now part of Oracle GLAS — Global Licensing and Advisory Services) audit, or as a condition of a ULA (Unlimited License Agreement) certification at the end of a ULA term.

In an LMS audit context, the compliance declaration typically takes the form of a completed Excel spreadsheet — Oracle's standard data collection template — containing inventoried Oracle software installations, server hardware configurations, processor counts, virtualisation details, and user counts. Oracle compares this declaration against the licences the customer holds under their Oracle contract(s) to identify compliance gaps.

In a ULA certification context, the compliance declaration is the formal count of Oracle software deployed at the certification date, which becomes the customer's perpetual licence entitlement. The accuracy and completeness of the ULA certification declaration directly determines the value of the perpetual licences the customer walks away with after the ULA term ends.

Both contexts carry significant financial risk if the declaration is prepared incorrectly, submitted prematurely, or without independent validation. Organisations that approach compliance declarations without specialist support routinely discover, after submission, that they have over-declared in ways that create new compliance obligations, or under-declared in ways that left licences on the table.

The LMS Audit Process and Where Declarations Fit

Oracle's formal LMS audit process follows a structured sequence. Understanding where the compliance declaration sits in this sequence is essential for managing the process effectively.

Stage 1: Audit Notification Letter

The process begins with a formal audit notification letter — typically addressed to the CIO, CFO, or General Counsel — stating that Oracle intends to conduct a licence review pursuant to the terms of the Oracle Master Agreement. The letter identifies Oracle's LMS representative and requests a response within five to ten business days acknowledging receipt and agreeing to proceed.

This first letter is the most critical point in the entire process. How you respond — and what you agree to — establishes the scope, timeline, and methodology for everything that follows. Many organisations make the mistake of responding too quickly, agreeing to unreasonable timelines, or accepting an audit scope that is broader than the contractual audit rights Oracle actually has. Always engage independent legal and licensing counsel before responding to an Oracle audit notification letter.

Stage 2: Kickoff Meeting and Questionnaire

Following acceptance of the audit, Oracle schedules a kickoff meeting during which LMS representatives explain the audit process and distribute their standard questionnaire. The questionnaire requests detailed information about IT infrastructure: server inventory, hardware specifications, processor types and counts, virtualisation platform details (VMware, KVM, Hyper-V), Oracle software installations (product names, versions, patch levels), and user and device counts for Named User Plus licensed products.

Oracle's questionnaire is designed to be comprehensive — it requests far more information than Oracle strictly needs to assess compliance. Providing unnecessary information can broaden the audit scope and create compliance exposure in areas that were not Oracle's original focus. Review every field of the questionnaire carefully and provide only the information that is strictly required under your contract's audit provisions.

Stage 3: Data Collection — Script Deployment and Declaration Submission

Oracle's LMS team deploys data collection scripts on your Oracle database and application servers. These scripts — part of Oracle's Collection Manager toolset — gather installation data, processor configurations, feature usage metrics, and licence-relevant system data. The scripts are supposed to be non-invasive and read-only, but organisations should review them before deployment and ensure they are run only on in-scope systems.

In parallel, Oracle requests the manual compliance declaration — the completed Excel spreadsheet covering infrastructure and software inventory. This is the document that Oracle will use as the basis for its compliance analysis. It must accurately reflect your deployed Oracle estate. Inaccuracies — in either direction — create problems. Over-declaring (stating more than you actually have) concedes compliance obligations you may not have. Under-declaring (failing to disclose deployments) creates risk if Oracle's scripts reveal inconsistencies.

Stage 4: Oracle's Compliance Analysis

Oracle's LMS team analyses the script output and the customer's compliance declaration against the licence entitlements on file. Oracle identifies any gaps between what is deployed and what is licensed. This analysis typically takes four to twelve weeks depending on the complexity of the environment.

Oracle's compliance analysis is not neutral. It is conducted by Oracle's LMS team, which is tightly integrated with Oracle's sales organisation. When a compliance gap is identified, Oracle's sales team is notified immediately and begins preparing a commercial proposal to remediate the gap — typically framed as a "compliance settlement" requiring the customer to purchase additional licences and, in recent years, Oracle Cloud services.

Stage 5: Compliance Report and Commercial Proposal

Oracle delivers its formal Compliance Report stating the identified licence gaps in quantitative and financial terms. The initial gap value is stated at Oracle's undiscounted list prices — which are typically two to four times the price a new customer would pay in a negotiated deal. Oracle then presents a commercial proposal offering to "settle" the compliance gap through a licence purchase, often at a discount from list price that is still substantially above what an arms-length negotiation would achieve.

At this stage, organisations have significant negotiating leverage that is rarely exercised effectively. Oracle's compliance claim is a starting position, not a final determination. The gap analysis methodology, the product coverage determinations, the virtual server counting rules, and the back-support calculations are all contestable. Organisations that challenge Oracle's methodology with independent analysis consistently achieve reductions of 60 to 70 percent from Oracle's initial claim.

ULA Certification Declarations

A ULA certification declaration is fundamentally different from an LMS audit declaration — it is the customer's opportunity to maximise the perpetual licence value they capture at the end of a ULA term, not a disclosure of compliance gaps.

What ULA Certification Requires

At the end of a ULA term (typically three years), the customer must declare the quantity of each ULA-covered Oracle product deployed across the organisation. This declared quantity becomes the customer's perpetual licence entitlement. Oracle support fees are then recalculated based on these certified quantities and continue on a perpetual basis.

The declaration must count all deployed instances of ULA-covered products — on all servers, in all environments (production, test, development, DR), on all platforms (physical, virtualised, cloud). Every additional deployment counted in the certification declaration adds perpetual licence value at no cost, because under a ULA, support fees are fixed regardless of deployment volume.

Maximising ULA Certification Value

The critical principle in ULA certification: you must maximise deployment before the certification date. Under a ULA, support fees are fixed regardless of how much you deploy, meaning every additional deployment before certification is free — it captures perpetual licence value at zero marginal cost. Organisations that certify before completing their planned deployment permanently lose this opportunity.

Best practice for ULA certification preparation includes running Oracle's collection scripts across every in-scope environment at least 90 days before the certification date to identify undiscovered Oracle deployments. Many organisations find Oracle software running in environments they had forgotten — test labs, decommissioned-but-still-running servers, cloud instances, contractor environments. Every deployment found adds to the certification count.

Common ULA certification errors include failing to include disaster recovery environments, test and development environments, and virtual machines in the count; using an incorrect virtualisation methodology that understates the deployment; and certifying before completing planned infrastructure rollouts. Each error permanently reduces the perpetual licence entitlement.

Self-Reporting and Voluntary Disclosure

Some organisations consider proactively disclosing compliance gaps to Oracle before receiving a formal audit notice. This approach — sometimes recommended by Oracle's account teams — requires careful legal analysis before execution.

Proactive disclosure may be appropriate when the gap is clearly identifiable, the remediation cost is quantifiable, and the organisation wants to control the timing and commercial terms of remediation. It is generally not appropriate when the gap's extent is uncertain, when it could trigger broader Oracle scrutiny, or when the organisation is approaching an Oracle contract renewal where the disclosure could undermine negotiating position.

If proactive disclosure is undertaken, it should be structured as a commercial conversation, not a formal compliance declaration. Frame the discussion as a licence expansion conversation tied to an upcoming business initiative, not as a voluntary admission of non-compliance. The distinction matters significantly for the commercial terms Oracle offers in response.

Key Mistakes to Avoid in Oracle Compliance Declarations

Submitting prematurely: Once submitted, a compliance declaration becomes the evidentiary basis for Oracle's compliance analysis. Rushing to submit before independently verifying every figure concedes issues you could have resolved.

Providing more information than required: Oracle's questionnaire scope is often broader than the contractual audit scope. Items outside the audit scope should not be disclosed voluntarily.

Accepting Oracle's virtualisation methodology without challenge: Oracle's default virtualisation counting methodology — counting all physical cores in a VMware cluster as licensable for Oracle — is contractually challengeable in many environments. Oracle-approved hard partitioning, properly implemented, limits licence counting to allocated resources rather than the full cluster. Review your virtualisation configuration against Oracle's approved hard partitioning methods before accepting Oracle's core count.

Underestimating integration software exposure: Compliance declarations that account for Oracle Database and application licences but omit WebLogic Server, Oracle Service Bus, and SOA Suite integration infrastructure systematically understate the full Oracle estate. Oracle's scripts will find everything; the declaration should match.

Accepting Oracle's gap valuation at list price: Oracle's compliance report values gaps at undiscounted list prices. This is a negotiating position, not a legal obligation. All remediation costs should be negotiated using the same leverage available in any Oracle commercial negotiation — competitive alternatives, Oracle Q4 timing, ULA restructuring, and cloud credit conversion.