Building an Oracle EBS License Position Baseline
An EBS licence position baseline is a reconciliation of what you are entitled to against what you have deployed, module by module and metric by metric. Built proactively and refreshed before any triggering event, it converts Oracle's audit from a discovery exercise into a verification of a position you already control, which is the single biggest determinant of audit outcomes.
What an effective licence position is
An effective licence position, usually abbreviated ELP, is the foundational document of Oracle licence management. It is a reconciliation that places entitlement and deployment side by side for every product and metric, and reports the difference. For each EBS module it answers three questions: what do we own, what have we deployed, and what is the gap. The output is not a single compliance score but a per product, per metric statement of surplus and shortfall, which together form a complete picture of where the estate stands against its contracts.
The reason the ELP matters so much is that it changes who controls the narrative. Without a baseline, an Oracle audit is a discovery exercise: Oracle runs its scripts, produces numbers, and presents them as findings, and the customer is on the back foot trying to dispute a position they never measured. With a current baseline, the audit becomes a verification: the customer already knows the numbers, has already remediated the inflation, and meets Oracle's scripts with a documented position. The shift from discovery to verification is the single largest determinant of audit outcomes, which is why the baseline sits at the centre of the EBS licensing discipline.
Establishing the entitlement side
The entitlement side of the baseline is built from contract documents, not from memory or from Oracle's account team. The primary sources are the ordering documents that record what was purchased, the licence schedules that define the products and quantities, and the contract definitions that govern how each metric is counted. An entitlement number is meaningless without its counting rule. Knowing you own two thousand Application Users of Payables is only useful alongside the contract definition of how an Application User of Payables is counted, because that definition determines whether your deployment of two thousand one hundred is a breach or a rounding question.
| Document | What it establishes | Why it matters |
|---|---|---|
| Ordering documents | Products and quantities purchased | The baseline of what you own |
| Licence schedules | Product definitions and metrics | Which metric governs each product |
| Contract definitions | How each metric is counted | Converts entitlement into a comparable number |
| Amendments and migrations | Changes to the original grant | Prevents reconciling against stale terms |
Entitlement is frequently the harder side to assemble, because the documents accumulate over decades, span acquisitions, and include migrations and amendments that alter the original grant. A baseline built against the original order while ignoring a later migration agreement will misstate the position. Gathering the complete contractual record, in order, is the unglamorous but decisive first step.
Measuring the deployment side
The deployment side is measured from the same EBS security tables that Oracle's License Management Services team queries. For user metrics, this means assembling the per module Application User count by walking from users to responsibilities to licensed products, exactly as described in the Application User article. For employee based modules it means reconciling the active worker population. For the database layer it means counting processors or named users under the relevant metric. The point is that you can run these measurements yourself, on your own schedule, before Oracle does.
Measuring your own deployment surfaces the inflation that a baseline exists to remove: terminated accounts still holding responsibilities, broad responsibility bundles granting access nobody uses, duplicate users, and undocumented service accounts. Each of these is remediable before a measurement crystallises it, and remediation done in the configuration changes what any future query, Oracle's included, will return. The deployment measurement is therefore not a passive count but the trigger for the cleanup that makes the position defensible.
Reconciling to a net position
With both sides assembled, the reconciliation is mechanical: for each product and metric, subtract deployment from entitlement to produce a surplus or a shortfall. The discipline is to do this per product, not in aggregate, because nets across products are meaningless to Oracle. A surplus of five hundred General Ledger users does not offset a shortfall of two hundred Payables users; they are different products under different lines of the contract. The reconciliation produces a list of shortfalls to remediate and surpluses that may represent shelfware to challenge at renewal.
Shortfalls are addressed in priority order, by financial exposure and by audit likelihood. A shortfall in a module touched by a known audit trigger, such as a recent virtualisation change, is more urgent than an equal shortfall in a stable module. Surpluses are catalogued for the renewal conversation, where unused entitlement on maintenance is a candidate for reduction. The net position, product by product, is the artefact that drives both the remediation plan and the commercial strategy.
Why a standing baseline wins
A one off baseline, built in response to an audit notice, is far less valuable than a standing one refreshed on a schedule. The reason is timing. An audit notice starts a clock, and remediation done under that clock is rushed, defensive, and visible to Oracle. The same remediation done months earlier, as part of routine governance, is unhurried, complete, and invisible. By the time an audit arrives, a standing baseline has already removed the inflation, documented the position, and resolved the shortfalls, so the audit verifies a clean estate rather than discovering a messy one.
The standing baseline also tracks the events that change the position. Upgrades, virtualisation changes, mergers, and renewals all move entitlement or deployment, and each should trigger a refresh before, not after, it completes. This is why the baseline is described throughout the EBS cluster as the prerequisite for everything else, from user count control to trigger management. The applications licensing practice builds and maintains standing baselines, and where an audit is already live, audit defence uses the baseline as the spine of the response.
The buyer side view
The baseline is the quiet discipline that determines loud outcomes. Customers who maintain a current effective licence position meet audits with documented numbers and resolved shortfalls, and the audit becomes a formality. Customers who do not maintain one meet audits as a discovery exercise, on Oracle's timetable, with inflation still in the estate and penalty pressure attached. The difference between these two experiences is not luck or negotiation skill; it is whether the reconciliation was done in advance, on your terms, or extracted from you under Oracle's.
The buyer side discipline is therefore to treat the baseline as a standing artefact, refreshed annually and before every triggering event, built from complete contract documents on the entitlement side and from self measurement on the deployment side. It is the cheapest insurance in Oracle licensing, because it converts the most expensive event, an audit of an unknown estate, into the cheapest, a verification of a known one. To build or refresh an EBS licence position baseline before your next triggering event, request a consultation.
Virtualisation, the database layer and the baseline
An EBS baseline that stops at the application layer is incomplete, because the technology beneath the application is where the largest and least controllable exposures sit. The Oracle Database under EBS is licensed on its own metric with its own minimums, and the way that database is deployed, particularly across virtualised infrastructure, can multiply the licensable footprint far beyond what the application layer suggests. A baseline must therefore reconcile the database and any separately licensed middleware as deliberately as it reconciles the modules, or it understates the true position.
Virtualisation is the sharpest issue. Where EBS databases run on a virtualisation platform that Oracle treats as soft partitioning, Oracle's position is that the licensable footprint extends to every host the workload could run on, not just the host it does run on. This can convert a modest database deployment into a claim across an entire cluster, and a baseline that records only the cores actually in use will miss it entirely. The baseline must capture the virtualisation architecture and Oracle's view of it, which is the subject of the dedicated EBS on VMware article and a central reason the technology layer cannot be an afterthought.
The practical step is to build the deployment side of the baseline in two stacked parts: the application user counts per module, and the technology footprint expressed in licensable cores or named users, with the virtualisation boundary documented. Reconciling both against their respective entitlements produces a complete position. Reconciling only the application layer produces a comfortable number that an audit of the database layer can demolish.
Governing the baseline: ownership, cadence and evidence
A baseline is only as valuable as the governance that keeps it current, and the most common failure is not building one but letting it decay. A baseline built once, then left while the estate changes, is worse than useless because it creates false confidence. Effective governance assigns a clear owner, sets a refresh cadence, and ties refreshes to the events that change the position, so the baseline is always a true reflection of the estate rather than a snapshot of how it looked at one moment.
| Element | Practice | Why it matters |
|---|---|---|
| Ownership | A named owner accountable for the baseline | Prevents the baseline becoming nobody's job |
| Cadence | At least annual, plus event driven refreshes | Keeps the position current |
| Trigger linkage | Refresh before upgrades, M&A, renewals | Catches change before it crystallises |
| Evidence retention | Archive each baseline with its source data | Defends the position against later challenge |
Evidence retention deserves particular emphasis. Each baseline should be archived with the entitlement documents and deployment data it was built from, so that if Oracle later disputes a historical position you can show what the estate looked like and what it was reconciled against at the time. This turns the baseline from a current management tool into a defensible historical record, which is exactly what is needed when an audit reaches back across years. The events that should trigger a refresh are the same ones catalogued in the audit triggers article, and the discipline of refreshing before them is what keeps the baseline ahead of Oracle rather than behind it.
Common questions.
What is an effective licence position for Oracle EBS?
An effective licence position, or ELP, is a reconciliation of entitlement against deployment for every EBS module and metric. It states, per product, what you own, what you have deployed, and the resulting surplus or shortfall, producing a single defensible view of compliance you control rather than one Oracle discovers.
How often should we refresh the EBS baseline?
At minimum annually, and always before a triggering event such as an upgrade, a virtualisation change, a merger, or a renewal. A baseline is only as useful as it is current, and the events most likely to prompt an audit are exactly the ones that change the position, so the refresh should precede them.
What documents establish EBS entitlement?
Ordering documents, the licence schedules, and the contract definitions that govern each metric. The ordering documents state what was purchased and under which metric; the contract definitions state how that metric is counted. Both are needed, because an entitlement number without its counting rule cannot be reconciled to deployment.
Can we measure our own EBS deployment before Oracle does?
Yes, and you should. The same security tables Oracle queries are available to you, so you can assemble the user counts per module, classify non human accounts, and identify inflation before a measurement. Self measurement is what turns an audit into a verification rather than a discovery.
What is the difference between a baseline and an audit response?
A baseline is built on your schedule, with time to remediate, before any claim exists. An audit response is built under Oracle's timetable and pressure, after a claim has begun. The same reconciliation underlies both, but a standing baseline means the audit response is largely already done.
Does a baseline reduce audit risk?
It reduces the financial risk of an audit rather than the chance of one. An audit of an estate with a current, accurate baseline finds little to claim, because the inflation has already been remediated and the position documented. The baseline does not prevent the audit; it removes most of its leverage.