Your certified ULA count is only as strong as the evidence behind it. A defensible file ties every number to a server inventory, configuration data, tool output, and a written methodology. That file proves the count at the certification review and defends it in any audit that follows.
By the Meridian advisory team · Ex Oracle licensing analysts · Updated June 2026
A certified number on its own is an assertion. The evidence file is what turns it into a position you can stand behind. At minimum a defensible file contains a complete server inventory of every host running an in scope Oracle product, the configuration and core data for each of those hosts, tool output or queries that show what Oracle software was installed and in use, and a written methodology that explains how the raw data became the certified count. Each certified number should trace cleanly back to a source in that file. When it does, the certification review moves quickly and a later audit has nothing to pull on. When it does not, every number is a question waiting to be asked.
Build the evidence file as you build the count, not afterward. The two are a single piece of work. A number you can evidence is an asset. A number you cannot evidence is a liability wearing the same clothes.
This is the spine. A complete, dated list of every server running an in scope product, with enough identifying detail to distinguish production, disaster recovery, test, and non production. The inventory has to reflect the estate as it stood at the measurement point, usually the term end, because that is the state the certified count describes. An inventory that is partial or out of date undermines everything built on top of it.
For each server, the processor type, physical core count, and configuration are what feed the processor calculation. This is where the core factor is applied, so the chip identification has to be exact. Configuration data also evidences how virtualized environments were bounded, which is the single most contested area in any review.
Output from inventory tools, database queries, and management consoles shows what Oracle software was actually installed and running. Screenshots and exports capture the state at a point in time and make the evidence harder to dispute. The aim is to show, not just tell, that each counted deployment existed and was in use.
The methodology is what holds the other three together. It explains how the inventory was gathered, how cores and core factors were applied, how virtualized and cloud deployments were treated against the contract, and how the totals were reached. A reviewer or auditor reading the methodology should be able to reproduce the number. Without it, the file is a pile of data rather than a defensible position.
| Element | What it proves |
|---|---|
| Dated server inventory | Which hosts ran in scope products at the measurement point |
| Core and processor data | How each host converts to an Oracle processor count |
| Virtualization topology | That Oracle workloads were isolated and bounded |
| Tool output and screenshots | That counted deployments existed and were in use |
| Cloud deployment records | That cloud instances met the contract's counting conditions |
| Written methodology | How the raw data became the certified number |
No, and this is worth stating plainly because customers often assume otherwise. Running Oracle LMS or GLAS data collection scripts is a choice, not an obligation, and the data those scripts produce is interpreted by Oracle, which tends to read it toward the larger number. An independent measurement that you own can evidence the same facts while keeping the methodology, the timing, and the narrative in your hands. There are cases where running scripts is a sensible decision, but it should be a decision analysed against your specific contract, not a reflex triggered by a request. Your evidence file does not depend on script output to be credible.
Far longer than the certification itself. Audit risk rises in the first two years after the exit, because the unlimited right is gone and any growth beyond the certified count is now a gap. The evidence file that supported your certified number is precisely what answers a later audit, so it should be stored, dated, and retrievable for years rather than discarded once the certification is accepted. Treat the file as a long lived corporate asset. The cost of keeping it is trivial next to the cost of reconstructing a position you can no longer prove.
Take an anonymized example with indicative figures. A telecom operator certified a large processor position and stored a complete evidence file: dated inventories, core data, virtualization topology, and a methodology a third party could reproduce. Eighteen months later an audit notice arrived. The operator answered with the existing file and closed the audit with no findings and no penalty. A comparable operator that had certified on a thin set of spreadsheets spent months trying to rebuild evidence for numbers it had already declared, and negotiated from weakness throughout. The certified counts were similar. The files were not, and the file is what the audit tested.
Read processor counting rules at certification to see how the core data in your file produces the number, and the peak deployment question to understand which point in time your inventory has to capture. When you want an evidence file built to withstand a review and an audit, our Oracle ULA certification guide is the pillar that covers counting and certification in full.
A defensible certification is supported by a server inventory, configuration and core data for each host, tool or query output showing Oracle usage, and a written methodology that explains how the count was built. Together these tie every certified number to a verifiable source, which is what the certification review and any later audit will test.
Keep it well beyond certification, because audit risk rises in the first two years after the exit. The evidence file that supported your certified count is the defense if Oracle later questions it, so it should be stored, dated, and retrievable for years, not discarded once the certification is accepted.
No. Running Oracle LMS or GLAS scripts is a choice, not an obligation, and the data they produce is interpreted by Oracle. An independent measurement you own can evidence the same facts while keeping the methodology in your control. The decision to run scripts should be analysed against your contract rather than assumed.