The annual true up reconciles your Oracle Java count in one direction only, upward. A negotiated cap converts that open ended risk into a worst case you can budget, and a two way true up lets the count fall as well as rise.
Here is the short answer. The standard Oracle Java true up reconciles your employee count upward at each anniversary with no ceiling, so ordinary growth lifts your bill year after year. The defense is a negotiated cap, ideally a percentage or absolute limit on the annual increase, paired with a two way true up that lets the count fall, a verified basis for the count, and a floor that steps down. Negotiate the cap early and make it survive renewal.
The annual true up is the quiet engine of an Oracle Java bill. Under the per employee Universal Subscription introduced in January 2023, your count is reconciled at each anniversary, and the standard order document reconciles it in one direction only, upward. A growing headcount, a reclassified contractor population, or a generous reading of the employee definition can lift your bill year after year with no ceiling. The defense is a negotiated cap. This article explains what a true up cap is, why you need one, and how to win it. The full picture sits in our Oracle Java licensing guide for 2026.
A true up is a reconciliation. At each anniversary Oracle compares the count you paid for against the count it believes you should pay for, and bills the difference. The trap is structural. The standard order document allows the count to rise but provides no path for it to fall. If your employee number grows, you pay more. If it shrinks, you keep paying the higher number until the term ends. The metric makes this worse because it counts every full time and part time employee, every contractor, and every temporary worker, regardless of who actually uses Java. A wave of seasonal hires or a single acquisition can move the count sharply, and the uncapped true up turns that movement directly into cost.
A true up cap is contract language that limits how far your count, and therefore your bill, can rise in a single period. It can take several forms, and the strongest agreements combine more than one.
| Cap type | What it limits | Buyer benefit |
|---|---|---|
| Percentage cap | Annual count increase to a fixed percent | Predictable worst case, protects against spikes |
| Absolute cap | The count to a stated maximum number | A hard ceiling regardless of growth |
| Price cap | The dollar increase rather than the count | Budget certainty even if the count moves |
| Two way true up | Allows the count to fall as well as rise | Pay for what you actually have |
| Verification requirement | Requires a verified count, not an estimate | Stops inflated reconciliations |
If you win nothing else, win a percentage cap. A clause that limits the annual count increase to a small fixed percent converts an open ended risk into a known worst case you can budget. Without it, a single reorganization can produce a true up bill that dwarfs the original subscription. With it, your finance team can model the maximum, and Oracle loses the ability to use ordinary business growth as a pricing event. Pair the percentage cap with a price hold on the rate so that the cap is not undone by an escalator. The relationship between these clauses is laid out in annual true up triggers in Java contracts.
The single most valuable concession is a true up that runs in both directions. If your count can fall as well as rise, then every workload you move to a free OpenJDK distribution, every contractor population you reclassify, and every reduction in force flows through to a lower bill. The standard order document deliberately omits this. Oracle's position is that you committed to a number, and you pay it. Your position is that you are paying for a metric, and the metric should reflect reality in both directions. Press for it, because it changes the subscription from a fixed obligation into a true measure of use.
Watch the interaction with the floor. A true up cap is only as good as the floor beneath it. If your minimum annual floor is set at 50K or 100K dollars, a two way true up still cannot take you below that number. Negotiate the floor and the cap together, and seek a floor that steps down if your estate shrinks. A cap that lets the count fall to a floor you can never escape is only half a win. See the minimum annual floor in Java agreements.
Even a capped true up can be inflated if Oracle controls the count. Insist that any reconciliation be based on a count you verify, drawn from your own records, rather than on an estimate or an assumption about your population. The employee definition is broad enough that small interpretive choices, such as whether short term contractors or recently departed staff are counted, move real money. A verification requirement puts the burden on documented fact and gives you a clear basis to dispute a number you did not produce.
Bring the cap to the table early and frame it as a condition of the deal, not a request for a favor. Quantify your exposure first so you can speak in concrete numbers. Model the bill under a plausible growth scenario with no cap and show Oracle the figure you are unwilling to sign up to. Offer a longer commitment in exchange for the cap, since term length is something Oracle values and is often willing to trade for. Put the agreed cap in a side letter if the standard order form will not hold it. Require that the cap survive renewal, because a cap that lapses at the end of the term simply moves the risk one year out.
Consider an organization billed for 9,000 employees that grows to 11,000 over a year through hiring and a small acquisition. Under an uncapped upward true up, the entire increase reconciles into the bill at the contracted rate. Under a percentage cap set low, only a small slice of that growth flows through in the year, and the rest is deferred or negotiated at the next renewal. The difference between those two outcomes, on a per employee rate that runs between 5.25 and 15.00 dollars per employee per month, is a material annual sum. These figures are indicative and depend on your band and your negotiated rate, but the shape holds in every estate we have defended.
True up disputes rarely start with a disagreement about the rate. They start with a disagreement about the count, and the count turns on definitions and timing. Did a population of short term contractors count for the full year or only the weeks they were engaged. Were employees of a newly acquired entity in scope from the closing date or from the next anniversary. Did departed staff drop out of the count promptly or linger because the records were not updated. Each of these is an interpretation, and under an uncapped true up every interpretation that favors a higher number flows straight into your bill.
This is why a cap and a verification requirement work together. The cap limits the damage any single interpretation can do, and the verification requirement forces the count back onto documented fact that you control. Without verification, a cap on a number you cannot check is a cap on the vendor's estimate, which is a weaker protection than it looks.
A cap that protects only the current term moves the risk one year out rather than removing it. At renewal the count resets, the cap lapses, and the reconciliation that you deferred can arrive in full. The fix is to write the cap so that it survives into the renewal term, and to pair it with a price hold so the rate cannot rise to undo the benefit. Think of the two as a single protection. The cap holds the count, the price hold holds the rate, and together they hold the bill.
| Protection | Without it | With it |
|---|---|---|
| True up cap | Count rises without limit | Annual increase bounded to a known figure |
| Price hold | Rate climbs at renewal | Rate fixed or capped for the next term |
| Survival clause | Both lapse at renewal | Both carry into the renewal term |
| Two way true up | Reductions never reach the bill | Count and bill fall when you shrink |
Even buyers who win a cap sometimes weaken it by accident. A percentage cap with no absolute backstop can still produce a large bill on a large base. A cap that applies to the count but not the rate leaves the escalator free to lift the cost anyway. A cap that lacks a downward path locks in every increase permanently, so a single bad year sets a new floor you can never leave. And a cap agreed verbally but never written into a side letter is no cap at all. Write the cap down, give it a downward path, tie it to a price hold, and make it survive renewal.
Caps are won with leverage, and leverage comes from a credible alternative. The buyer side approach is to sweep the estate, isolate Oracle Java to the workloads that truly need it, and migrate the rest to a free OpenJDK distribution. When you can show Oracle a smaller, defensible employee envelope and a real plan to walk away from the surplus, a cap stops looking like a concession and starts looking like the price of keeping your business. The smaller your committed population, the less an uncapped true up can ever cost you, which strengthens your hand on the cap itself. Quantify the exposure first, decide what you are willing to commit to, and negotiate the cap from that position rather than from the number Oracle proposes.
Take an organization that commits to a count of 12,000 employees and then goes through a reduction in force that takes the real population to 9,500 over the term. Under the standard order document the true up runs upward only, so the reduction never reaches the bill. The organization keeps paying for 12,000 people it no longer employs until the term ends, and possibly into the renewal if the count resets at the committed number rather than the actual one. A two way true up changes this entirely. The count follows reality down, the bill falls with it, and the saving from the reduction flows to the business that made the hard decision rather than to the vendor.
The same logic applies to migration. As the organization sweeps its estate and moves workloads to a free OpenJDK distribution, the population that genuinely needs Oracle Java shrinks. Without a two way true up, that effort produces no contractual saving, because the committed count is frozen. With one, every migrated workload and every reduction in the counted population shows up as a lower bill. These figures are indicative and depend on the band and the negotiated rate, but the shape is consistent. A true up that only moves up rewards growth and punishes discipline. A true up that moves both ways aligns the bill with what you actually run.
Whatever cap you win, keep your own clean record of the counted population, refreshed at each anniversary, so that you enter every true up and every audit with a number you can stand behind. With LMS audits intensified in 2026 and a three year lookback in play, the organization that can produce a documented, defensible count negotiates from strength, while the one that relies on the vendor's estimate negotiates from doubt. The cap limits the damage, the verification requirement forces the count onto fact, and your own records are what make the verification real.
A true up cap turns the most dangerous line in the Oracle Java contract into a known quantity. As your buyer side advisory we negotiate these caps as standard, and we pair them with floor step downs and price holds so the protection holds across the term. Our clients have cut an average of 68 percent off Oracle's opening number, with more than $120M in Java exposure defended across more than 300 audits and more than 20 years of combined experience. We work on a Fixed Fee from $18,000, or on Gainshare, a share of verified savings or avoided exposure, with zero retainer and no risk to you. Before you accept an uncapped true up, model what it could cost and put a ceiling on it.
We model your Oracle Java true up exposure and negotiate the caps that hold it down. Two ways to engage. Fixed Fee from $18,000, or Gainshare, a share of verified savings or avoided exposure, with zero retainer and no risk to you.
Book a Strategy Call Get a QuoteFixed Fee from $18,000 or Gainshare, a share of verified savings or avoided exposure with zero retainer and no risk to you. We sit between you and Oracle and we never take vendor money.
Get a QuoteWeekly intelligence on Oracle Java licensing moves and the buyer side defenses that work.