An Oracle Effective License Position (ELP) is the single document that tells you, before Oracle's auditors do, whether you own enough licenses to cover what you actually run. It reconciles every entitlement against measured deployment and reports a net surplus or shortfall per product. Most enterprises have never built one — which is exactly why Oracle's audit claims land as a surprise.
Short answer: An Oracle Effective License Position (ELP) reconciles what you own (contractual entitlements) against what you deploy (measured usage), producing a net compliance position — surplus or shortfall — for every Oracle product and metric. Build it before Oracle audits, so you find and fix gaps on your own terms.
An Oracle Effective License Position (ELP) is a reconciled, product-by-product comparison of contractual entitlements against measured deployment, expressed as a net position — surplus or shortfall — for every Oracle product and licensing metric. It is the buyer-side equivalent of the document Oracle's auditors build to justify a claim.
Three terms matter here. Entitlement is what you have the contractual right to use: a quantity of Processor or Named User Plus (NUP) licenses for a specific product, recorded on an ordering document and tied to a Customer Support Identifier (CSI). Deployment is what you are actually running, measured the way Oracle measures it — cores after Core Factor, distinct NUP users, options enabled, Java installations. Effective License Position is the reconciliation: for each product, deployment minus entitlement, netted to a single number.
An ELP is not a software inventory and not a spend summary. An inventory tells you what is installed; it does not tell you whether you are licensed for it. A spend report tells you what you have paid Oracle; it does not tell you whether what you paid for matches what you run. The ELP is the only artifact that answers the question Oracle asks in an audit: for this product, on this metric, are you covered? Building one is the foundation of every credible audit defense and every honest renewal negotiation. For the wider process this sits inside, see our Oracle audit defense guide.
Because remediation is only possible before Oracle measures. Once Oracle's USMM scripts run, certain compliance positions freeze. A current ELP lets you find gaps, reset parameters, decommission ghost installs, and right-size deployment on your timetable — not under the pressure of a back-licence claim.
Oracle's License Management Services (LMS) team — and its successor function, Oracle GLAS — enters every audit with a preliminary claim model built before the first conversation. The customer who has never built an effective license position enters the same engagement blind, reacting to Oracle's numbers instead of challenging them. That asymmetry is the entire point of Oracle's audit playbook: measure first, present a large compliance gap, and convert it into a renewal or a cloud commitment.
A customer-built ELP inverts that dynamic. When you already know your net position per product, Oracle's compliance report stops being a revelation and becomes a document you can forensically challenge line by line. You know which options are genuinely in use and which were enabled accidentally; you know which environments are non-production; you know your real Core Factor. In our engagement data, customers who hold a current ELP at the point of audit notification settle for a fraction of Oracle's opening claim, because the gap Oracle can defend is far smaller than the gap Oracle first asserts.
Timing is the whole game: The most valuable pre-audit remediations — resetting CONTROL_MANAGEMENT_PACK_ACCESS to NONE, removing decommissioned Oracle Homes, documenting VMware DRS host pinning — can only reduce your measured deployment if they happen before Oracle runs its scripts. An ELP built after the audit notice is still useful; an ELP built and acted on before it is worth multiples more.
Our Oracle Compliance Review builds a forensic effective license position across your estate in two to four weeks — using the same methodology as Oracle's LMS scripts, but interpreted on your side. See the healthcare remediation case study: $6M audit risk reduced to a $280K settlement.
An effective license position has exactly two inputs — entitlements and deployment — but each is assembled from several sources. The reconciliation is only as defensible as the evidence behind it, so gather the primary documents, not summaries. The table below maps each source to what it proves.
| Side | Source document | What it establishes |
|---|---|---|
| Entitlement | Ordering Documents / Order Forms | Exact product, metric, and quantity you purchased the right to use |
| Entitlement | Master Agreement & T&Cs | Definitions, audit clause scope, territory, and assignment rules |
| Entitlement | CSI / support records | Which licenses are active on support and tied to which entity |
| Entitlement | ULA / PULA terms & certification | Unlimited-use products and the certified quantities at exit |
| Deployment | USMM & Review Lite output | Installed Oracle products, versions, and host inventory |
| Deployment | DBA_FEATURE_USAGE_STATISTICS | Database options and packs that show as used (e.g. Diagnostics Pack) |
| Deployment | Processor / core inventory + Core Factor Table | Licensable processor count after Oracle's Core Factor multiplier |
| Deployment | VMware vCenter / cluster maps | Which hosts Oracle can claim under its partitioning rules |
| Deployment | Java SE install & employee data | Java footprint under the Employee metric |
A ULA (Unlimited License Agreement) is a fixed-term Oracle contract granting unlimited deployment of named products in exchange for a single upfront fee; during the term those products do not feature in your shortfall calculation, but their certified exit quantities become your permanent entitlement afterward. Getting the ULA boundary right is one of the most common reconciliation errors — teams either over-count entitlement during the term or under-count it after certification. Our ULA Advisory team handles exactly this reconciliation. For database-specific deployment mechanics, the Oracle database licensing guide covers Core Factor and option counting in depth.
For each product and metric, normalise both sides to the same unit, subtract entitlement from deployment, and record the net. A positive number is a shortfall (audit exposure); a negative number is shelfware you may be able to re-harvest. The interpretation choices in between are where positions are won or lost.
The mechanics are arithmetic; the judgement is everything. Five reconciliation decisions drive most of the variance between a defensible ELP and an inflated one, and Oracle's auditors resolve every one of them in Oracle's favour by default:
The output is a clean summary table — one row per product, with entitlement, deployment, and net position. A worked example below shows how the same estate reads very differently depending on who interprets the data.
| Product (metric) | Entitlement | Deployment | Net position |
|---|---|---|---|
| Database EE (Processor) | 40 | 34 | +6 surplus |
| Diagnostics Pack (Processor) | 0 | 0 (parameter reset pre-measure) | 0 covered |
| Partitioning (Processor) | 12 | 16 | −4 shortfall |
| Named User Plus (Database EE) | 500 | 410 | +90 surplus |
| Java SE (Employee) | 0 | under review | scope challenge |
Read across the rows and the value of a buyer-side position is obvious: surpluses in one product can sometimes offset shortfalls elsewhere within the same agreement, the Diagnostics Pack exposure has been eliminated by a pre-measurement parameter reset, and the Java line is held open as a scope challenge rather than conceded. Our License Optimization service turns surplus rows into re-harvested licenses and shortfall rows into remediation plans.
Both use the same raw measurement data, but they interpret it for opposite parties. Oracle's compliance report maximises the gap; a buyer-side ELP applies the correct Core Factor, excludes non-production, documents option usage, and narrows VMware scope. In our engagements the two routinely differ by 3–5×.
Oracle's report is not neutral and was never meant to be. It is built by Oracle's audit organisation, whose commercial incentives are aligned with a larger compliance gap and a larger resulting deal. Every ambiguous data point — an option that shows as used, a host that might run Oracle, a Named User minimum — is resolved in Oracle's favour. That is Oracle's agenda, and it is entirely predictable.
A buyer-side ELP is the counter-interpretation. It does not invent licenses you do not own or hide usage you cannot defend; it simply resolves the same ambiguities accurately and on the evidence. The discrepancy between the two documents is the negotiating range. When you can show, line by line, that Oracle's claim rests on default assumptions the evidence does not support, the settlement collapses toward your number — not Oracle's. This is the work our Audit Defense team does in every engagement, and it is why the firms that arrive with a current ELP consistently pay a fraction of Oracle's opening figure.
Refresh your Oracle effective license position at least once a year, and always before a contract renewal, a ULA certification, a cloud migration, or an audit notification. Deployment drifts continuously, so a position older than twelve months understates your real audit exposure.
An ELP is a snapshot, and Oracle estates do not stand still. Teams add cores to virtualisation clusters, enable database options during troubleshooting, stand up new test environments, and install Java on endpoints — every one of which moves the deployment side without anyone updating the entitlement side. A position that was accurate in January can carry a six-figure shortfall by December, entirely invisibly.
Treat the ELP as a living control, not a one-off project. The trigger events that warrant an immediate refresh are predictable: any Oracle renewal or true-up, the run-up to a ULA certification window, a migration to OCI or another cloud, a major datacentre or virtualisation change, and — of course — the arrival of any Oracle audit or "review" email. Customers who maintain a rolling ELP rarely receive an unwelcome surprise from Oracle, because they have already found and priced their own exposure first. If you are starting from zero, begin with a single forensic baseline and move to an annual cadence; talk to a former Oracle insider about which trigger events apply to your estate.
An Oracle Effective License Position (ELP) is a reconciled comparison of contractual entitlements against measured deployment, producing a single net position — surplus or shortfall — for every Oracle product and metric. It answers one question: for each product, do you own enough licenses to cover what you are actually running?
Oracle's compliance report is built by Oracle's LMS/GLAS team to maximise the compliance gap and the resulting claim. A buyer-side ELP is built from the same raw data but interprets entitlements accurately — correct Core Factor, excluded non-production, documented option usage. The two routinely differ by 3–5×.
Two data sets: entitlements (ordering documents, CSI records, ULA terms, Master Agreement, transfer paperwork) and deployment (USMM/Review Lite output, DBA_FEATURE_USAGE_STATISTICS, processor and core inventory, VMware cluster maps, and Java install data). The ELP reconciles one against the other, product by product.
You can build a first-pass position internally if you hold the contracts and can run Oracle's measurement scripts. The risk is interpretation: Core Factor, option attribution, VMware scope, and Named User Plus minimums are where most internal positions go wrong — usually against the customer. Independent review of the reconciliation is where the savings are found.
Yes. A current ELP lets you find and remediate compliance gaps before Oracle measures — resetting parameters, decommissioning ghost installs, right-sizing deployment. Because remediation is only possible before Oracle runs its scripts, the ELP is the single most valuable audit-readiness document an Oracle customer can hold.
A forensic effective license position across a typical enterprise Oracle estate takes two to four weeks once the contracts and measurement data are available. The reconciliation itself is fast; gathering primary entitlement documents and clean deployment data is the part that determines the timeline.
We build forensic, buyer-side effective license positions for enterprises across every Oracle product line — then turn surplus into savings and shortfall into a remediation plan. Independent, evidence-based, and never working for Oracle.
By Fredrik Filipsson — former Oracle sales and licensing professional, 25+ years of experience, founder of Oracle Licensing Experts. Reviewed by the Oracle Licensing Experts Review Team, former Oracle License Management Services consultants. 100% buyer-side advisory — never works for Oracle. About our team →
Audit alerts, renewal tactics, and licensing intelligence from former Oracle insiders. Join 2,000+ Oracle stakeholders. Corporate email required.