Your entitlements live in scattered ordering documents, migration credits, and legacy metrics that no single system holds. This is the method to reconcile all of it against your actual installed footprint before Oracle does it for you.
Your entitlements live in scattered ordering documents, migration credits, and legacy metrics that no single system holds. This is the method to reconcile all of it against your actual installed footprint before Oracle does it for you.
An Oracle license position has two sides. The deployment side is a technical inventory problem: which programs, which options, how many cores, on which processors, behind which virtualization layer. Buyers spend most of their effort there because tooling helps. The entitlement side is a contract archaeology problem, and it is where the position usually breaks. Entitlements are not stored in one place, they are not expressed in one metric, and Oracle's own records (the License and Services Agreement summaries the audit team pulls) frequently disagree with what you signed.
Reconciliation is the act of joining these two sides on a defensible common basis. Done properly, it produces a baseline you can defend in an audit, price in a renewal, and hand to a divestiture team without a six-week scramble. Done poorly, or not at all, you walk into every Oracle conversation accepting Oracle's count as the starting point. In 25 years of negotiating against this vendor, the single most expensive habit we see is buyers who can quantify their deployment to the core but cannot produce a clean entitlement total. That asymmetry is exactly what Oracle's LMS and now GLAS teams are built to exploit. If you have not yet built the deployment side, start with the buyer-side baseline guide and return here to join the two.
Buyers who can count their deployment to the core but cannot total their entitlements have already handed Oracle the starting position.
Entitlements are not a database record inside Oracle you can request and trust. They are the sum of every legal grant across the life of the account, and those grants are scattered across document types that were signed years apart by people who have often left the company. Before you can reconcile anything, you have to assemble the full corpus. In practice that means finding and reading every one of the following.
The failure mode is treating Oracle's LMS-supplied entitlement summary as the source of truth. That summary reflects what Oracle's systems captured, not what your contracts grant. We have repeatedly found ordering documents that Oracle's own records omitted, and equally, phantom entitlements in Oracle's summary that no signed document supports. Reconcile to the signed paper, not to the spreadsheet Oracle emails you.
You cannot subtract deployment from entitlement until both are expressed on the same axis. This is the step most reconciliations skip, and it is where the numbers stop being defensible. Oracle's metrics do not convert to each other on a fixed rate, so you must normalize deliberately, program by program, and record every assumption.
For Database Enterprise Edition, the relationship between the two live metrics is fixed and worth pricing. On the April 16, 2026 Technology Global Price List, EE lists at 47,500 dollars per Processor and 950 dollars per Named User Plus, exactly one fiftieth. The Named User Plus minimum is 25 per Processor. That crossover matters: past 50 real authorized users per Processor, the Processor metric is cheaper, but below the 25 NUP floor you pay the floor regardless of usage. A four-Processor EE database with twelve real users still licenses 100 NUP, not twelve.
| Reconciliation dimension | Entitlement side (what you own) | Deployment side (what you run) | Common basis to reconcile on |
|---|---|---|---|
| Metric | Processor, NUP, or legacy (Named User, UPP) | Cores, sockets, users | Normalize legacy to Processor/NUP first |
| Processor count | Grant quantity from ordering doc | Cores times core factor, rounded up | Processor licenses required vs held |
| NUP minimum | 25 NUP per Processor (EE) | Actual authorized users plus non-human devices | Higher of floor or real user count |
| Core factor | Fixed at time of purchase, applies to on-prem only | Chip generation determines factor (0.5 x86, 1.0 unlisted) | Do not apply on-prem factor to cloud |
| Options and packs | Separately granted per Processor | Whether the option is installed/used | Each option reconciled independently |
The core factor is where deployment side arithmetic gets expensive. Intel and AMD x86 carry a 0.5 factor, so a 16-core socket counts as 8 Processor licenses. IBM POWER9 is 1.0 and POWER10 is 0.75. Any chip not on Oracle's table defaults to 1.0 until Oracle formally adds it. The 2025 table update extended 0.5 factors to Intel Xeon 69xx/67xx/65xx and AMD EPYC 5th generation, but Xeon 6 E-core parts now reach 144 cores per socket, so a hardware refresh can inflate the deployment side without a single new install. Price the next refresh into your reconciliation, not just today's estimate.
The dirtiest part of reconciliation is legacy metrics that never mapped cleanly to Processor and NUP. Named User (the pre-NUP metric), UPP, and Concurrent Device grants sit in old ordering documents and do not translate on any published rate. Oracle will happily assign them a conversion that favors Oracle, and buyers, lacking their own basis, often accept it.
Do not convert legacy entitlements silently into current metrics inside your position. Carry them as a distinct line, quantified in their original metric, with the original ordering document referenced. When Oracle proposes a conversion, you then have a documented starting point to negotiate from rather than a blank. We treat this as a separate workstream because the exposure and the leverage are both material. The dedicated guide on legacy metrics in your Oracle license position walks through Named User Legacy, UPP, and Concurrent Device handling in detail.
Never let Oracle convert a legacy metric on your behalf. Carry it in its original metric, cite the ordering document, and negotiate the conversion from your own basis.
Migration credits are where entitlement totals leak. When Oracle credits a prior purchase into a new order, or converts a technology purchase into a cloud or Java grant, the arithmetic sits in an amendment that rarely gets folded back into your central record. Two failure patterns recur. First, buyers double-count: they carry the original grant and the credited replacement as two entitlements when only one is live. Second, buyers under-count: a credit created new capacity that was never added to the baseline, leaving usable entitlement invisible and unused.
Cloud complicates this further. BYOL to OCI converts on-premises Processor licenses at 2 OCPUs per Processor, so 16 Processor licenses cover a 32-OCPU OCI VM. Authorized Cloud Environments (AWS, Azure, GCP) use a different and less favorable rule: one Processor license covers two vCPUs with multithreading enabled, and critically the on-premises core factor does not travel to those clouds. A 0.5 factor entitlement that covered 32 cores on-prem does not cover 32 vCPUs in AWS. These conversion rules also sit in policy documents, not your signed contract, so Oracle can change them. Pin the policy version in force at deployment and document each instance against it. If credits and cloud terms are central to your account, the Oracle cloud credit model breakdown covers what the credit model hides.
A defensible reconciliation follows a repeatable sequence. Skip a step and the position becomes an estimate rather than a baseline. This is the method we run on client engagements, compressed to its essentials.
The virtualization step deserves emphasis because it is the largest single swing in most reconciliations. Oracle's soft-partitioning position counts every core the database could migrate to across a VMware cluster, not the cores it actually runs on. In a ten-server cluster of dual 32-core Xeon hosts, that is 640 physical cores times 0.5, or 320 Processor licenses, even if Oracle runs on one VM with 4 vCPUs. Whether that claim holds depends on your contract language and your isolation architecture, but you must carry it as a distinct, quantified line so the audit does not surprise you.
Reconciliation is not a SAM-tool button. Discovery tools count deployment well but read entitlements poorly, because entitlements live in unstructured legal paper the tool never sees. The realistic split is: tooling for the deployment inventory, a human for the entitlement corpus and the normalization judgments. Our comparison of SAM tool, spreadsheet, or advisor approaches sizes each against Oracle specifically. On ownership and frequency, the position must be refreshed on hardware refresh, headcount change, and at least annually before renewal, with a named owner accountable; the guide on refresh cadence and ownership covers the operating model.
One timing rule outranks all others. Build this before an audit, never during one. A reconciliation built under audit pressure inherits Oracle's framing, Oracle's deadlines, and Oracle's metric conversions. A reconciliation built in peacetime is your baseline, and Oracle has to argue against it. The difference in outcomes is documented in the comparison of a position built before an audit versus during one. For a general framing of entitlement versus use, the Oracle license info primer is a useful companion.
Two closing points on value. First, support economics amplify every reconciliation error. Support runs at 22 percent of net license fees, so an over-licensed position quietly overpays support for years, while an under-licensed one exposes you to back-support in an audit settlement. Second, gaps cut both ways. Unused entitlements (shelfware) are not just waste, they are leverage in a renewal; the method for finding and reclaiming shelfware value starts from exactly this reconciliation. Build the baseline once, correctly, and it pays back at every renewal, every audit, and every carve-out.
Start by assembling the entitlement corpus, because you cannot reconcile what you have not read. Total grants per program and metric, keep legacy metrics and migration credits as distinct lines, and refuse to let Oracle supply the conversion. Build the deployment side with rounding up and core factors applied correctly, carry the VMware soft-partitioning claim as a named line, and produce a required-versus-held figure per program. Then classify every gap as real or negotiable. Do this before your next audit letter arrives, assign an owner, and refresh it on every hardware or headcount change. That baseline is the difference between negotiating from your numbers and defending against Oracle's.
No. Oracle's LMS or GLAS summary reflects what Oracle's systems captured, not what your signed contracts grant. We routinely find ordering documents Oracle's records omit and phantom entitlements Oracle's summary shows with no supporting paper. Reconcile to the signed ordering documents and master agreement, not to Oracle's spreadsheet.
Carry them as distinct lines in their original metric, referencing the ordering document that granted them, rather than converting them silently to Processor or NUP. There is no published conversion rate, so any conversion is negotiable. If you convert them yourself, you lose the documented starting point you need when Oracle proposes a conversion that favors Oracle.
Only to OCI, and even there the rule is BYOL-specific: 2 OCPUs per Processor license. For Authorized Cloud Environments like AWS, Azure, and GCP, the on-premises core factor does not apply at all. One Processor license covers two vCPUs with multithreading enabled, with no fractional multiplier, so a 0.5-factor entitlement that covered 32 cores on-prem does not cover 32 vCPUs in AWS.
Oracle's soft-partitioning position counts every core the database could migrate to across the cluster, not just where it runs. A ten-host cluster of dual 32-core servers can produce a 320 Processor claim even if Oracle uses one 4-vCPU VM. Carry that claim as a distinct, quantified line so the audit does not surprise you, and check whether your contract language and isolation architecture actually support it.
Before, always. A position built under audit pressure inherits Oracle's framing, deadlines, and metric conversions. A position built in peacetime becomes your baseline, and Oracle has to argue against your numbers rather than the reverse. The outcome difference is consistently material.
On every hardware refresh, on material headcount change for user-based metrics, and at least annually ahead of any renewal. Core density is rising fast (Xeon 6 E-core parts reach 144 cores per socket), so a refresh alone can inflate your deployment side without any new installs. Assign a named owner accountable for the cadence.
Oracle Exadata can lock you into full core licensing across X9M, X10M, and Cloud at Customer. The buyer side strategy to size the platform and cut the bill.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
