Oracle License Management Services does not invent a number. It builds one, step by step, from the data you provide, the population it assumes, the deployment it infers, and the rate it applies. Each step is a place where assumption can creep in, and each step is a place where a prepared buyer can hold the process to fact. Understanding how LMS constructs a claim is the foundation of dismantling an inflated one.
It is part of the playbook in the Java Audit Survival Guide.
Step one: the data request
LMS opens with a broad data request, often arriving as a soft audit email rather than a formal notice. It asks for deployment data, download history, and population figures, and it asks for them quickly and widely. The breadth is deliberate, because the more raw data flows in, the more material there is to build a claim from. The buyer side discipline begins here, by providing only what the contract obliges. For how to handle that first contact, read how to respond to an Oracle Java soft audit email.
Step two: the population figure
The largest input LMS needs is the counted population, because the claim is roughly employee count times list rate times discount. The metric counts every full time and part time employee, every contractor, and every temporary worker, regardless of who uses Java. LMS will reach for the broadest available figure, typically a raw global headcount, and treat it as the population unless you provide a verified, deduplicated count that reflects the contracting entity only.
Step three: the deployment assumption
LMS then assumes a deployment footprint. In the absence of clear evidence, it assumes that Java means Oracle Java SE and that it runs broadly across the estate. Download history from Oracle’s own systems is often used as a proxy, even though a download is not the same as a licensable deployment. Your runtime inventory, showing where a free OpenJDK distribution runs instead, is what corrects this assumption.
| LMS step | Default assumption | Buyer side correction |
|---|---|---|
| Population | Raw global headcount | Verified count, contracting entity only |
| Deployment | All Java is Oracle Java SE | Runtime inventory showing free distributions |
| Period | Continuous over three years | Dated history of changes and removals |
| Rate | List price, modest discount | Volume band rate, negotiated discount |
Step four: the rate and the period
LMS applies a list rate from the 5.25 to 15.00 dollars per employee per month range, with smaller estates near the 15.00 ceiling and the largest near the 5.25 floor. It then extends the figure across the three year lookback. Both the rate and the period are inputs a buyer can move: the rate through the correct volume band and negotiation, the period through dated evidence of what actually ran. The mechanics of that extension are covered in the three year lookback in Oracle Java audits.
Step five: the discount and the quote
Finally LMS presents a discount against the assembled figure. The discount feels like the concession, but it is the input Oracle controls and the one that moves the number least. A generous discount on a broad, unverified claim still produces a large number. The real reductions come earlier, from correcting the population and the deployment, not from the discount applied at the end.
Indicative worked example. An insurer received an LMS claim built on a raw headcount of roughly eight thousand, all Java assumed to be Oracle Java SE, priced across three years at a list rate with a headline discount. Once the population was verified down to the contracting entity, the runtime inventory showed most servers on a free distribution, and the period reflected a documented migration, the assembled claim fell by a large multiple before the discount was even discussed. Figures are indicative.
Where the claim is most fragile
The claim is most fragile at its inputs, not its conclusion. Every figure rests on an assumption, and an assumption that meets verified evidence gives way. Population is the most fragile input because it moves the number most. Deployment is next, because the Oracle Java SE distinction is so often wrong. Period is third, because history is rarely continuous. Attack the inputs, and the conclusion contracts on its own.
Why understanding the build matters
Buyers who treat the claim as a single fixed number negotiate only the discount, which is the weakest lever. Buyers who understand how the claim was built can dismantle it input by input, and that is where the large reductions come from. The number LMS presents is the end of a process, and every step in that process is contestable with the right evidence.
Hold each step to the facts
The defense is methodical. For each step LMS takes, return the corresponding evidence: the verified population for the headcount, the runtime inventory for the deployment, the dated history for the period, the volume band for the rate. A claim that meets evidence at every step has nowhere to inflate, and what remains is a small, defensible figure. For how to press that contraction, read how to challenge an inflated Java audit finding.
From claim to settlement
Once the claim is reduced to its evidenced base, the conversation turns to settlement and to the contract traps that travel with it: a minimum annual floor, an annual true up, and a renewal escalator. Strip the inflation from the claim first, then negotiate the residual and the terms together, and the outcome reflects the estate you actually run rather than the one LMS assumed.
How LMS uses download records
One of the most important things to understand about an LMS claim is how heavily it can lean on Oracle’s own download records. A download from Oracle’s systems is treated as a signal of deployment, even though downloading is not the same as running a licensable installation in production. Buyers who understand this can separate downloads from deployments in their own evidence, showing where a downloaded runtime was never deployed commercially or was later replaced by a free distribution. The download record is a starting assumption, not a proven fact.
How LMS frames the conversation
LMS often frames the engagement as a routine verification rather than an adversarial audit, which encourages cooperation and the free flow of data. The framing is not hostile, but it serves the claim, because the more data arrives unprompted, the more material there is to build from. A buyer can be entirely professional while still routing every response through a single channel and providing only what the contract obliges. Courtesy and discipline are not in tension. For the first contact, read how to respond to an Oracle Java soft audit email.
Where the discount really comes from
The discount LMS offers can look generous, but it is calculated against the assembled figure, so a large discount on an inflated base still leaves a large number. Understanding the build shows why the discount is the weakest lever: it is applied last, to whatever survived the earlier steps. The reductions that matter come from correcting the population and the deployment before the discount is ever discussed. The full arithmetic is set out in the audit claim formula.
The role of the data request letter
The formal data request letter is the instrument through which LMS gathers its inputs. It tends to ask broadly, across entities, populations, and time, and it sets the tone for the exchange. Reading it against your contract’s audit clause, and responding only to what the clause obliges, keeps the inputs to the claim under your control. A broad letter does not create a broad obligation. The obligation is defined by the agreement, not by the request.
Why understanding the build is leverage
When you understand that the claim is assembled step by step, you stop treating the final number as fixed and start treating it as a sequence of contestable inputs. That shift is the difference between negotiating a discount and dismantling a claim. Each input you correct compounds with the next, and the conclusion contracts on its own. The buyer who sees the build sees exactly where the money is, and it is almost never in the discount.
Each input has a different sensitivity
Not every input in the claim carries equal weight, and understanding the difference tells you where to spend your effort. The population is a raw multiplier on the whole figure, so correcting it has the largest effect. The deployment determines whether the obligation attaches at all, so the Oracle Java SE distinction can remove entire tiers. The period multiplies the annual figure across the lookback. The rate moves within a defined band, and the discount, applied last, moves the number least. Spend your evidence where the sensitivity is highest, and the claim contracts fastest. The full arithmetic is in the audit claim formula.
The claim is a position, not a verdict
It helps to remember what the LMS claim actually is: an opening position assembled from assumptions, not a verdict you must accept. Every figure in it was chosen to favour the claim, and every figure can be met with evidence. Buyers who treat the claim as final negotiate only at the margins. Buyers who treat it as a position to be tested, input by input, recover the large reductions. The number you are handed is where the conversation starts, not where it ends.
Next step. Download the Oracle Java Audit Survival Guide for the step by step claim breakdown and the input correction worksheets we use. We work on a Fixed Fee from $18,000 or a Gainshare share of verified savings or avoided exposure, with zero retainer and no risk to you.