Oracle ULA Certification Report: What Oracle Requires & How to Prepare

What Oracle Requires in a Certification Submission

Oracle's ULA certification process does not have a single mandatory submission format that Oracle publishes publicly. What Oracle requires is determined by your specific ULA contract language — which varies by enterprise and by negotiation — combined with Oracle LMS's standard evidence requirements that have evolved through thousands of certification reviews. Enterprises that don't know what Oracle expects will receive extensive information requests during the review process, delaying certification and giving Oracle more time to identify disputable items.

At minimum, Oracle requires: a deployment count for each covered product, expressed in the metric defined in the ULA (Processor or Named User Plus); identification of each deployment by server hostname and hardware specification; Core Factor Table calculations for all Processor metric deployments; and a certification declaration signed by an authorised officer of the enterprise. Beyond this minimum, Oracle LMS will almost always request supporting scripts or tool output, hardware specification sheets for the underlying servers, and virtualisation configuration documentation where applicable.

Oracle's account agreement defines the certification timeline. Most ULA contracts require the enterprise to submit a certification notice within a specified window — often 30 to 90 days before the ULA end date. Missing this window can have contractual consequences. Some ULA contracts allow Oracle to certify on your behalf if you fail to certify — and Oracle's account-led certification will be conservative, documenting only what Oracle can independently verify, which is rarely in the enterprise's interest.

Running the Deployment Audit: USMM and Alternative Methods

The deployment audit underpins the entire certification report. The quality of the evidence you collect determines how well you can defend the certification numbers when Oracle challenges them. Oracle's preferred collection tool is the Oracle Universal Software Discovery Manager (USMM) script — a shell script that Oracle provides to enterprises, which scans installed Oracle software across a server and reports product names, versions, and install paths. USMM output is what Oracle's own LMS team uses when running audits, which means submissions based on USMM are harder for Oracle to challenge on methodological grounds.

The limitation of USMM is practical: it requires access to every server in scope, it must be run by someone with root or administrator privileges, and it must be run on the certification date (not retrospectively). Enterprises with large, heterogeneous server estates face significant operational complexity in running USMM comprehensively. The alternative is to use a third-party Software Asset Management (SAM) tool — such as Snow Software, Flexera, or ServiceNow SAM Pro — that has Oracle product recognition capabilities. These tools can provide continuous discovery data across the estate, which is valuable for ongoing compliance management as well as certification preparation.

For the certification report specifically, whatever collection method you use should be documented in the submission. Oracle will ask about the discovery methodology and may request evidence that the methodology covers the entire in-scope server estate. Gaps in coverage — servers that could not be scanned, recently acquired systems, cloud environments — must be addressed explicitly. Unexplained gaps are an invitation for Oracle to dispute the completeness of the submission.

The detailed guidance on running internal discovery before Oracle's LMS scripts arrive is covered in our article on Oracle LMS audit scripts — the same methodology applies to the pre-certification self-assessment.

Processor Metric Calculations: Core Factor Table

If your ULA covers Oracle Database EE or other Oracle products under the Processor metric, the Core Factor Table is the most important — and most contested — element of the certification calculation. Oracle's Processor metric counts physical cores, not CPUs or sockets. But different processor architectures are weighted differently by the Core Factor Table, so a system with 64 cores on Intel Xeon processors generates a different licence count than 64 cores on IBM POWER processors.

The Core Factor Table assigns a multiplier to each processor architecture. For the most common enterprise server configurations in 2026, the critical Core Factors are: Intel Xeon at 0.5 (meaning each physical core counts as 0.5 Processor licences), AMD EPYC at 0.5, ARM-based processors at 0.5, and IBM POWER at 1.0 (each core counts as 1.0 Processor licence). The complete Core Factor Table is published by Oracle and updated periodically — verify you are using the version in effect at the time of certification, not a historical version.

The certification report must document, for each server: the processor model and specification (matching the Core Factor Table entry), the physical core count per processor, the number of sockets, and the resulting Core Factor calculation. Provide hardware vendor specification sheets as evidence for the processor model and core count. Do not rely on OS-reported CPU information without cross-referencing vendor specs — OS-level tools sometimes misreport virtual vs physical core counts in complex configurations.

The Oracle Database Licensing Guide contains a detailed section on Processor metric calculations for different deployment architectures, including Exadata and engineered systems.

Named User Plus (NUP) Metric Calculations

Not all ULAs cover products under the Processor metric. Where the ULA covers products under the Named User Plus (NUP) metric, the certification report must document every named individual who accesses the covered Oracle products. NUP licensing requires a minimum of 25 NUP per Processor licence equivalent — Oracle will enforce this minimum during certification review. Understanding the NUP vs Processor metric comparison is essential before choosing which metric to certify under.

For NUP certification, the enterprise must document: total named users with authorised access to covered Oracle products, the basis for the user count (typically an Active Directory or application access control list), and confirmation that indirect access users — humans who interact with Oracle through non-Oracle front-end applications — have been included. Indirect access is the most common NUP counting error. If your Oracle Database serves data to a web application used by external users, those external users may be licensable as NUP — even though they never directly log into the Oracle system. Oracle's LMS team will probe indirect access configurations aggressively during certification review.

Handling Virtualised Environments in the Report

Virtualised deployments are the single most contested area in ULA certification reports. Oracle's Partitioning Policy — which is Oracle's unilateral statement of how it interprets licence requirements for virtualised environments — takes positions that are significantly more expensive than a contract-based interpretation would suggest. Specifically, Oracle's policy states that most virtualisation technologies, including VMware vSphere, Microsoft Hyper-V, and KVM, do not constitute "hard partitioning" for Oracle licensing purposes, meaning Oracle will count all cores in the cluster as licensable — even if Oracle software only runs on a subset of physical servers within that cluster.

This position is Oracle's preferred interpretation. It is not automatically your contractual obligation. Your ULA contract language takes precedence over Oracle's external policy documents. Many ULA contracts contain specific provisions about deployment scope, infrastructure rules, or virtualisation configurations that are more favourable to the enterprise than Oracle's Partitioning Policy would suggest. Independent legal review of your ULA's specific deployment clauses is mandatory before accepting Oracle's virtualisation count.

For the certification report, document every virtualised deployment with: the virtualisation technology and version, the cluster configuration including all physical hosts, the servers on which Oracle software is installed or runs, the Oracle software's NUMA node and CPU affinity binding where applicable, and any hard partitioning technologies (Oracle VM, Solaris Containers, IBM LPAR) used to restrict Oracle's access to specific processors. This documentation allows you to challenge Oracle's cluster-wide counting position with specific technical evidence. Our article on Oracle compliance in virtualised environments provides the full technical framework.

Certification Report Structure and Format

The certification report should be a formal document with a defined structure — not a spreadsheet dump. A structured report demonstrates forensic rigour, makes Oracle's review process more predictable, and establishes a documentary record for any subsequent dispute. The recommended structure is as follows.

Executive Summary. One to two pages summarising the certification scope, the total licence counts per product, and the key methodological choices made in the count. The executive summary allows Oracle's account team and legal team to review the position without drilling into the technical detail immediately.

Certification Scope Statement. A precise statement of which ULA contract, which Order Form number, which products, which territories, and which entities are covered by the certification. Reference the specific contract documents by title and date. This prevents Oracle from claiming the certification applies to a different scope than intended.

Deployment Inventory. A server-by-server listing for each covered product, including: server hostname, physical location (data centre and entity), processor model and specification, physical core count, Core Factor calculation, number of instances installed, product version, and resulting licence count. This is the core data table of the report and should be exportable to a format Oracle can import into their review tools.

Discovery Methodology Statement. A description of the tools and methods used to collect deployment data, the date the data was collected, and confirmation that the discovery covered the entire in-scope estate. Include USMM script output or SAM tool reports as appendices.

Virtualisation Configuration Appendix. For every virtualised deployment, document the virtualisation technology, cluster topology, and Oracle software placement. Include hypervisor version information and, where hard partitioning is claimed, technical evidence of the partitioning configuration.

Authorised Officer Declaration. A signed statement from an authorised officer of the enterprise confirming the accuracy and completeness of the certification submission, as required by the ULA contract.

The Oracle LMS Review: What to Expect

Oracle's LMS or GLAS team typically takes four to eight weeks to complete their review of a certification submission. During this period the Oracle review team will compare your submitted counts against any data Oracle holds independently — including outputs from previous LMS audits of your environment, data collected during the ULA term with your consent, and Oracle licensing system records of what software keys have been issued to your organisation.

Oracle's review will almost certainly produce a response document that challenges one or more elements of your submission. This is normal — it is not a finding of non-compliance. It is the opening position in the certification negotiation. The review document will list Oracle's alternative count for each disputed item and the basis for the challenge. Every challenge should be addressed in writing with specific technical and contractual evidence. Accepting Oracle's challenged figures without response will reduce your final certified count, potentially by millions of dollars in perpetual licence value.

Oracle may also raise items outside your submission — products it believes you have deployed that are not covered by the ULA, or deployments Oracle claims are outside the ULA's scope. These are separate from the certification and should be treated as the beginning of an Oracle audit defence engagement, not as part of the certification process. Maintain a strict separation between the certification (what the ULA covers) and any compliance discussion (what falls outside the ULA).

Responding to Oracle's Challenges

Every Oracle challenge to your certification report should receive a written formal response within a defined timeframe. Allow Oracle's challenge to go unanswered for more than two weeks and Oracle's account team will interpret your silence as acceptance of their position. The response structure should be: acknowledge Oracle's specific claim, state your position clearly, cite the specific contract clause or technical evidence that supports your position, and request Oracle's written response if they wish to maintain the challenge.

The most important principle in dispute management is that Oracle must justify every challenge with a specific contractual basis. "Our policy says" is not a contractual basis — it is Oracle's preferred commercial outcome. "Section 4.2 of your Master Agreement defines deployment scope as..." is a contractual basis. Force every Oracle challenge to a contractual text. Oracle's account teams often cannot produce a contractual basis for virtualisation challenges because Oracle's Partitioning Policy is not incorporated into the ULA contract.

Where a genuine dispute cannot be resolved at the account team level, escalation paths include Oracle's customer escalation process, independent expert arbitration (if your ULA contains an arbitration clause), or legal proceedings. The vast majority of certification disputes are resolved before reaching these escalation points when the enterprise presents forensic, evidence-based responses and demonstrates it understands its contractual rights. Engage the Oracle Compliance Review service to assess your certification position independently before engaging Oracle.