Oracle bills move up year on year, but most of the overspend in an Oracle estate is not set at renewal. It is set between renewals, across five separately defensible lines, and read out loud at the audit.
Oracle overspending in 2026 is not one big number at one big renewal. It is five separately defensible lines, set between renewals, and priced by what Oracle finds when it audits.
About this report
This report reads Oracle overspending as a stack of separately defensible lines. It draws on three inputs.
We report bands and directions, not precise findings. Outcomes vary widely with estate size, prior audits, contract age, and willingness to baseline early. Where a single number appears, treat it as the middle of a range, not a guarantee.
The honest answer is rarely the renewal letter. In most Oracle estates we read, overspending is set between renewals and shows up across five lines: Database over deployment, the Java employee count, ULA exit gaps, support shelfware, and the audit settlement premium. Each line is defensible on its own evidence.
Treating the bill as one big negotiation each cycle hides which line is actually moving. The disciplined buyer reads the five lines separately, builds a baseline for each, and brings that file to the audit and the renewal rather than reacting to Oracle's figure.
The order is not universal, but the pattern repeats. Database is usually the largest line because the estate is the largest, and options and packs drift quietly. Java has become the second largest line for many enterprises since the per employee reset. ULA exits, support shelfware, and the audit settlement premium fill the rest.
Each of the five lines has its own evidence, its own remedy, and its own clock. The bill that arrives at renewal blends them into a single figure that is hard to challenge in aggregate.
Pulling the lines apart restores the ability to negotiate. A 10 percent move on the Java line is a different conversation from a 10 percent move on Database options, and the buyer side response is different for each.
Slowly, line by line, in the gap between what is installed and what is licensed. Oracle pricing publishes the rate card, but most over deployment is not about the rate. It is about the unit. The unit count grows when DBAs enable an option, attach a pack, or rebuild a cluster, and the contract rarely tracks the change.
The single biggest source of Database overspend in our engagement file is options and packs. Partitioning, Advanced Compression, Diagnostics Pack, Tuning Pack. Each one is installed by default in many Enterprise Edition builds, and a DBA who clicks the option once can create a licensable usage event for the whole CPU.
The defense is unglamorous. A quarterly options usage report from Oracle LMS style scripts, reviewed by the SAM team, removes most of the surprise. Unused packs should be uninstalled or capped before the next audit cycle.
The other large Database line is VMware sub capacity. Oracle's position has been that any host a vMotion event could reach is a licensable host. The buyer position is that pinned, host affinity bound deployment limits the count to the bound hosts.
The gap between those two readings is enormous. In one engagement, the cluster wide count produced a finding 6 times the pinned count. The defense is a written affinity policy, a configured host group, and an evidence pack collected continuously, not after the LMS letter arrives.
Even where rights are clean, the metric can drift. A Named User Plus contract assumes a defined user community. As the estate moves to broader access or self service tools, the user count can outgrow the entitlement without anyone noticing until renewal.
Because the unit is the whole organization. Oracle Java SE Universal Subscription prices per employee, defined broadly to include full time, part time, temporary, and agent staff. The rate card looks modest. The count is the surprise.
In the Oracle Java estates we baselined, the employee count exceeded the genuine active Java user base by a factor of 3 to 8. A 20,000 person organization with 3,000 active Java users still receives a 20,000 unit proposal at the Oracle list rate.
The overspend is the difference between paying for a metric you can defend and paying for one Oracle proposes. The defensible position is the active user base, evidenced by usage telemetry, build inventory, and JDK image deployment data.
A credible OpenJDK plan is the strongest single lever in a Java renewal. Eclipse Temurin, Azul Zulu, Amazon Corretto, Red Hat OpenJDK. Each is a real path off Oracle Java for the majority of typical workloads, and the existence of the path resets the conversation.
The plan does not have to be fully executed. It has to be costed, sequenced, and visible to the Oracle account team before the renewal opens. A buyer who can move is a buyer who pays differently.
For most enterprises, a defensible Java cost lands somewhere between zero, achieved through full OpenJDK migration, and 10 to 25 percent of the per employee proposal, achieved by paying for the genuine subset of users that needs Oracle support and binaries.
More than most certification files capture. A ULA exit is a one shot crystallization of deployed capacity. Whatever is in the certified count carries forward as perpetual entitlement. Whatever is missed is gone, and any later growth lands as a fresh licensing event.
In the ULA exits we have advised, the largest source of overspend was capacity that existed in the estate but was not in the certified count. Decommissioned hosts that ran the workload earlier in the year, virtual capacity that moved before the snapshot, options invoked once and removed.
The buyer side move is to build the certification file 9 to 12 months before the window closes, not in the last 30 days. The file is a record of deployment across the term, supported by configuration management evidence and discovery data, not a snapshot.
Where Oracle proposes a Perpetual ULA conversion or an extension, the buyer side analysis is the same. Map the certified count against the full deployment trail. Walk away from a conversion that crystallizes a count below the defensible total. The renewal pressure is real but so is the cost of accepting a depressed baseline.
Once exited, the support floor is set by the certified count, not by usage that follows. Estates that overcount at exit then carry the support fee on capacity they never deploy. Estates that undercount lose growth rights and pay again on the next contract.
By staying the same name while changing the count. An Oracle metric that worked when the contract was signed often counts very differently five years later, after the estate has reorganized, virtualized, or moved to broader access tools.
The buyer side risk is that the metric is treated as a fixed cost line in the finance ledger. It is not. Each metric is a living unit count, sensitive to architecture decisions made by other teams who do not see the contract.
Named User Plus contracts assume a defined user community, often as a minimum per processor. Estates that originally licensed for a back office team can find that user count outgrown the moment the same database is exposed to self service reporting or a broader portal.
The defense is a quarterly named user reconciliation tied to a documented user list. Where the count grows, the right move is often to switch to a processor metric at renewal rather than absorbing a year of overage.
Oracle's processor core factor table is a contractual reference. Where a buyer moves to newer hardware or a different chip family, the core factor changes and the licensed processor count can rise or fall without any change in workload.
This is one of the most overlooked sources of Oracle overspend. Buyers should run a core factor refresh on every hardware refresh cycle and document the new entitlement count before the next audit.
The Java per employee metric is the most visible example. Workday and successor metrics follow a similar pattern: the unit count expands with the organization rather than with usage, and contracts signed at one headcount carry forward into a different one.
The protection is contractual. Negotiate a true up cadence with a defined ceiling and a documented count source, not an open ended employee count drawn from finance records each cycle.
The license usually moves with it, and that is where most cloud cost overruns hide. Oracle workloads do not automatically become cloud native. They run as VMs on a hyperscaler or on OCI, and the on premise license still applies.
Oracle's BYOL policy permits use of existing on premise licenses on AWS, Azure, and Google Cloud, with a defined conversion ratio. The ratio is rarely one to one and the buyer who skips the calculation pays for both the cloud compute and a licensable shortfall.
The fix is a written BYOL plan signed off before any migration. Map current entitlement, apply the published conversion, and compare against actual cloud compute. Anywhere the gap is positive, the workload either resizes or licenses up before the move.
Oracle classifies AWS and Azure as authorized cloud environments with specific counting rules. Google Cloud has a different position. Outside these three, Oracle takes the view that standard on premise counting applies, often more strictly than buyers expect.
The buyer should keep a written record of which environments are in scope, which are not, and the contractual basis for each. The record is the first item the LMS team asks for in a cloud audit.
Oracle prices its own cloud aggressively for existing customers, and the OCI BYOL ratio tends to be more favorable than other hyperscalers. That is not an accident. The pricing is set to make OCI the rational destination for Oracle workloads.
That is a fair commercial position. The buyer side discipline is to compare it against other paths on the merits, with a costed model, rather than accepting the steered choice by default.
The standard view is that you negotiate Oracle hard at renewal and accept the result. We disagree that the renewal is where the win lives. In roughly 50 of the 60 to 80 Oracle estates we ran in 2024 and 2025, the largest single source of overspending was over deployment built up between renewals, not the renewal rate, and it was priced by what Oracle found when it audited. The buyer side move is to baseline deployment continuously, reconcile against entitlement every quarter, and bring your own defensible numbers to the conversation rather than reacting to Oracle's. The audit is where the bill is made; the renewal is where it is paid.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
The Oracle bill is not made at renewal. It is made between renewals, in the gap between what is installed and what is licensed, and it is read out loud at the audit.
In the comfort of accepting Oracle's framing. An audit finding is a claim, not a verdict. Oracle's investor disclosures describe license revenue and unspecified license outcomes; they do not describe the gap between a finding and a defensible position. That gap is the settlement premium.
The premium has three usual components. List price applied to the remediation where the buyer's contract rate exists. Assumed usage of options and packs where install does not equal use. A metric or counting assumption, such as cluster wide VMware or per employee Java, that overstates the defensible count.
None of these components are unfair on their own. They are Oracle's opening position. Each one is moveable with the right evidence, and the buyer who arrives with that evidence settles closer to the defensible figure.
What an Oracle audit finding really contains
| Component | Typical share of finding | Defensible share | What lives in the gap |
|---|---|---|---|
| Real shortfall in entitlement | 20 to 35% | 20 to 35% | Genuine deployment beyond owned rights |
| Options and packs assumed in use | 15 to 25% | 0 to 10% | Packs installed but never licensed or invoked |
| Per employee or per metric assumption | 20 to 30% | 5 to 15% | Whole headcount counted where only a fraction use the product |
| VMware cluster wide counting | 10 to 20% | 0 to 5% | Hosts the workload never ran on |
| List price applied to remediation | All of it | Negotiated rate | Use of LMS list without the buyer's contract rate |
The defense is a short list of operational habits. A baseline that is older than the audit. A written sub capacity policy with technical enforcement. A user telemetry file for Java. A quarterly options usage report for Database. Together they convert an audit from a negotiation under pressure into a reconciliation against known numbers.
The team that does this well is not the largest team. It is the team that started the baseline a year before the LMS letter. The signature on the settlement letter follows the work done long before the audit arrived.
Compounding works against the buyer because Oracle's support model resets the base each year. Support is invoiced as a percentage of the original net licensed cost, lifted by an uplift each renewal. Shelfware lines that lost business value years earlier keep collecting that uplift indefinitely.
Three common sources. Estates that retired a workload but kept the underlying license. Acquisitions where the parent inherited duplicate Oracle entitlements. Cloud migrations where the original on premise license remained on support after the workload moved.
Each of these is invisible if the support invoice is paid as a single number. Each is recoverable through a structured support scrub and the contractual termination rights most enterprises do not exercise.
The simplest discipline is an annual support scrub. List every CSI, map it to a business workload, and flag every line where the workload no longer exists or has moved. The flagged lines are candidates for termination, third party support, or renegotiation at the next anniversary.
The savings compound the other way. Removing a shelfware line not only saves this year's support; it removes a permanent uplift base from every renewal that follows. A clean support file is one of the highest return projects in the SAM portfolio.
For Database and middleware lines that no longer depend on new releases or active vendor updates, third party support is a credible alternative to Oracle support at roughly half the cost. The risk profile is real but containable on stable workloads.
The move is not for every line. It works best where the workload is stable, the release schedule is well understood, and the legal terms have been reviewed. Held as a credible option, it changes the realistic price Oracle is willing to renew at, even without adoption.
Where Oracle overspend hides, line by line
| Line | Typical opening exposure | Defensible range | Buyer side move |
|---|---|---|---|
| Database EE + options drift | 12 to 25% of DB line | 4 to 10% | Quarterly options audit + delete unused packs |
| Java SE Universal employee count | Whole headcount | Active users only | Baseline real users, default to OpenJDK |
| ULA exit certification | Lowball certified position | Full deployed count | Build the ULA certification file 9 months out |
| Support on retired or shelfware | 100% renewal on full base | Retired lines removed | Annual support scrub + termination rights |
| VMware sub capacity exposure | Cluster wide count | Pinned hosts only | License bound hosts, written affinity, evidence pack |
| OCI Universal Credit underuse | Full commitment burned | Used credits + carry | Quarterly burn reviews + reset at renewal |
By being signed on optimistic adoption forecasts and burned slowly. An Oracle Universal Cloud Credit commit is a take or pay arrangement. The buyer commits a dollar figure across a term; unused credits expire. Estates that under consume the commit overpay for cloud they never used.
The defense is the same as for any commit driven cloud arrangement. A quarterly burn review, a defined runway, and a documented decision to either accelerate adoption or restructure the commit at the next renewal.
The decision should be made by month nine of a twelve month cycle, not at month eleven. Earlier visibility gives the buyer the option to renegotiate, partly convert to discount, or align the new commit to actual demand. Late visibility hands Oracle the upper hand on extension terms.
A second source of OCI overspend is a deep discount rate that does not carry forward into the next commit. Buyers focus on the headline rate at signing and miss the contract language that lets it revert at renewal. Pin the rate to the next term explicitly.
An OCI commit is denominated in dollars across all services. Buyers who model the commit on a small set of expected services often find that real adoption shifts toward different services at different rates, leaving the commit underused in some and overspent in others.
A quarterly service mix review converts this from a surprise into a planned adjustment. Where the mix has moved, the right move is to rebalance the commit at the next renewal rather than renew the original mix and absorb the gap.
Three anonymized patterns from the engagement file show how the same five line stack plays out differently across estates. The figures are bands, not exact outcomes, and details are generalized.
A global bank received a Java SE Universal Subscription proposal at the full per employee count. The opening figure was several multiples of the budget the SAM team had carried for Java in the prior year.
A focused active user baseline, built from build inventory and JDK image telemetry, identified the genuine Oracle Java users across the bank. The defensible count came in at roughly 12 percent of the per employee proposal, evidenced and documented.
The settled position adopted a tiered subscription for the defensible user count, with a staged migration of remaining workloads to Eclipse Temurin across the following 18 months. The realized cost was a fraction of the opening proposal, with an explicit exit path for the rest.
A multinational manufacturer received an LMS finding that counted every Database license against the full vSphere cluster footprint. The opening exposure ran into eight figures, citing list price across the full cluster wide host count.
A rebuild of the host affinity configuration, with a signed sub capacity policy and a documented affinity rule set, narrowed the defensible host count to the pinned subset. The settled position landed at less than a quarter of the opening claim, with a clean technical record going forward.
The longer term outcome was structural. The manufacturer adopted a written sub capacity policy across the estate and embedded the affinity rules in change control, removing the audit surface that produced the initial finding.
A retailer approached the end of its Oracle ULA with a draft certification prepared by the Oracle account team. The draft understated deployed capacity by about a third against the buyer side reconciliation.
An independent inventory across the full ULA term recovered the missing capacity into the certification count. The exit landed on a higher perpetual entitlement than the original draft, and the support floor was set at a defensible level for the next decade.
The buyer side investment in the certification file paid back many times its cost across the next contract life, because every line of capacity in the certified count is permanent entitlement that does not need to be relicensed.
Not all levers are equal. Three move the realized Oracle number materially, and the rest are noise. Knowing which is which keeps an Oracle negotiation focused on what actually changes the bill.
The single highest return lever is the baseline. A buyer who arrives with a clean baseline, older than the audit letter, controls the conversation from the first response. No table tactic is worth as much as the baseline behind it.
The baseline is what every other lever depends on. Without it, negotiation reduces to absorbing Oracle's numbers at a smaller discount. With it, the conversation is about which defensible figure to settle on.
The second lever is a costed alternative. OpenJDK for Java. Third party support for stable Database lines. PostgreSQL or other open paths for new applications. The alternative does not have to be exercised. It has to be costed and visible.
The presence of a credible alternative resets the Oracle account team's read of the buyer. A captive buyer pays one price. A buyer who can move pays a different one, even when the move never happens.
Lead time is leverage because it creates the space to baseline and to cost the alternative. Oracle renewals opened inside 60 days carry the highest settlement premium because the time to use any defense has already been lost.
The fix is a standing 12 month Oracle calendar, owned by SAM, that flags every contract a year ahead. Built once and maintained, it converts every Oracle conversation from a surprise into a planned event.
Bundling new commitments with renegotiations of existing lines can earn a meaningful concession on the existing base. The risk is bundling commitments the buyer would not otherwise make to earn a discount that does not justify them.
Use bundling as a lever only where the new commitment carries its own business case. Avoid it where the discount won is smaller than the long term cost of the bundled commitment, which is the contrarian point made earlier in the report.
By treating the Oracle line as a band, not a point, and by funding the work that holds the band low. A flat Oracle budget against a moving Oracle bill is a budget that will be missed.
A defensible 2026 Oracle plan carries a base case at the prior year line plus an uplift, a high case that assumes one open audit settles in the period, and a low case that assumes the support scrub and options cleanup close before renewal.
The band gives finance the room to absorb a settlement without a fire drill, and the discipline to release the contingency when the work that holds the low case actually closes. A single point estimate offers neither.
The cheapest way to lower the realized Oracle line is to fund the preparation that produces it. The baseline, the options report, the Java active user file, and the support scrub all pay back many times their cost in a single year for most estates.
Treat these as funded projects with named owners and quarterly milestones, not as side work the SAM team does between renewals. The status of these projects is the leading indicator of next year's Oracle bill.
2027 will look like 2026 in shape, with the same five lines, but the OCI commit line will likely grow as more estates close their first OCI cycle. Buyers should carry the OCI line as a separate budget item from the on premise base, with its own band.
One accountable owner, not a committee. The renewal calendar fails as an ownership problem more often than as a negotiation problem. When no one owns the Oracle file end to end, every cycle arrives late and is handled under time pressure.
SAM is the natural home for the baseline, the options usage report, the Java telemetry, and the support file. SAM holds the discovery data and the contractual entitlements together in one place, which is where the defensible position is built.
The risk is treating SAM as a reporting function rather than an accountable owner. The role works when SAM has a target, a budget, and an authority to act, not just a dashboard.
Procurement runs the renewal conversation and the negotiation, but it depends entirely on what SAM has prepared. The most damaging pattern is procurement engaging Oracle without the SAM file in hand.
The fix is a standing 12 month Oracle calendar that brings procurement and SAM into the same room a year before each major contract. Both teams arrive at the negotiation with the same evidence and the same target.
Finance owns the budget band the Oracle line sits inside, and the contingency for an audit settlement. The role is to set those bands deliberately, with a scenario for the high case and a discipline that holds the low case when negotiations close below the ceiling.
A single point budget is the wrong instrument for Oracle cost. A band, with named scenarios and a recorded decision on which one applies, is the right instrument and the only one that survives an actual audit.
An independent advisor brings the benchmark and the cross client view that no internal team sees enough Oracle deals to hold. The highest return engagement point is before the first response to Oracle, when the position is still open and the cost of a different path is smallest.
The five line pattern is universal. Where the lines sit in the order changes by sector, and that shapes which projects pay back fastest for a given buyer.
Database is usually the largest line in financial services estates, driven by transaction systems and the long tail of trading and risk applications that built up on Oracle. Options usage tends to be the biggest single recoverable, and a quarterly audit usually pays for itself in the first cycle.
Java is a strong second line because most large banks ran Java heavy estates for decades. An active user baseline against the per employee proposal usually shows a recoverable gap of 70 percent or more.
Manufacturing estates often carry the heaviest support shelfware burden. Legacy plants, retired ERP modules, and inherited acquisitions accumulate as Oracle support lines that no longer earn their fee. An annual support scrub is the highest return Oracle project in this sector.
ULA exits are the second priority because manufacturing rarely renews ULAs cleanly. The certification file is the leverage, and starting it 12 months ahead pays back across the next contract life.
Public sector estates carry long lived contracts and structurally lower switching freedom. The dominant overspend is metric expansion and audit settlement premium, because procurement cycles slow the response to vendor moves.
The buyer side discipline is a written sub capacity policy, a documented user count source for Java, and an audit defense file prepared independently of the next renewal. These are slow to build and durable once in place.
Technology firms have the most options to migrate and therefore the most leverage. They are also most exposed to OCI commit underuse because their cloud adoption curves shift faster than the commit cycle. Quarterly burn reviews are essential.
A handful of signals reliably flag an Oracle audit that will open high. Most are visible a year or more before the LMS letter arrives.
VMware estates without a written sub capacity policy are the single largest audit risk in our engagement file. Cloud migrations that move workloads off the original on premise license without retiring it run a close second.
The defense is paperwork. A signed sub capacity policy, a documented BYOL plan, and a clean retirement log for any decommissioned workload remove most of the audit surface before it can grow.
Oracle audits cluster around renewals that lapsed, were extended on a short term basis, or closed without a clean entitlement document. The audit is the path Oracle takes when the renewal conversation broke down.
A deliberate, well prepared renewal is the strongest single audit defense, because the audit motive falls away when the relationship is current and the entitlement is documented.
Both sides of a corporate event create audit signals. The acquirer inherits an unknown estate; the divested unit may carry licenses without a clear path. Either situation produces over deployment that an Oracle audit will price.
Enterprises overpay across five separately defensible lines: Database over deployment, the Java per employee count, ULA exit gaps, support shelfware, and the audit settlement premium.
The bill that arrives at renewal blends these into a single figure. The disciplined buyer pulls them apart, baselines each, and brings line by line evidence rather than a single counter.
It happens between renewals through options and packs invoked by default, VMware sub capacity drift, and metric expansion the contract never catches.
Partitioning, Advanced Compression, Diagnostics Pack, and Tuning Pack are common culprits. They are installed by default in many Enterprise Edition builds and become licensable at first use. A quarterly options report and a written sub capacity policy remove most of the exposure.
Because the unit is the whole organization, including part time and temporary staff. In our engagement file the employee count overstates the genuine active Java user base by a factor of 3 to 8.
The defensible position pays for active users with telemetry to support the count. The alternative is to migrate the bulk of workloads to OpenJDK and pay only for residual Oracle Java use.
Capacity that existed during the term but was not in the certified count. Decommissioned hosts, virtual capacity that moved before the snapshot, and options invoked once and removed. The certification file should be built 9 to 12 months before the window closes, supported by configuration management evidence across the full term, not a 30 day snapshot.
Treat the finding as a claim, not a verdict. The defensible position usually lands at 40 to 60 percent of the opening figure when the buyer arrives prepared.
Preparation means a clean baseline, a written sub capacity policy, options usage data, and Java telemetry. The wedge between the finding and the defensible position is the settlement premium that disciplined buyers do not pay.
Start with an annual support scrub, an options and packs cleanup, and a Java active user baseline. These three projects together recover a material share of the annual Oracle line in most estates without requiring a renewal conversation. The renewal then locks in the new base rather than rolling the old shelfware forward.
Support is invoiced as a percentage of the original net licensed cost, lifted by an annual uplift. A shelfware line keeps collecting the uplift indefinitely. Removing the line saves this year and removes a permanent uplift base from every renewal that follows. A clean support file is one of the highest return projects in the SAM portfolio.
Build a continuous estate baseline that is older than any audit letter you will ever receive. Most other moves depend on it. Without a baseline, the buyer reacts to Oracle's numbers. With one, the buyer arrives at the audit and the renewal with defensible figures and the conversation changes immediately.
Yes, with caveats. Third party support is viable for stable Database and middleware lines that do not depend on new releases or active vendor updates. OpenJDK is viable for the majority of standard Java workloads. Both are real leverage at renewal even when not adopted, and both deserve a costed, sequenced plan that the Oracle account team can see.
Nine to twelve months before expiry on any material contract. Lead time is leverage because it creates the space to baseline, build a credible alternative, and let Oracle see both. Renewals opened inside 60 days carry the highest settlement premium because the time to use any defense has already been lost.
The five line stack, the band midpoints by category, the active user evidence pack for Java, the options usage script set for Database, and the ULA exit certification timeline that protects deployed capacity.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement, SAM, and finance leaders running the next Oracle cycle.
The Oracle bill is not a renewal problem. It is an evidence problem, solved one quarter at a time.
