Soft audit vs formal audit: the Java edition.

Oracle has two ways to ask whether you owe it money for Java, and they look nothing alike. One arrives as a contractual notice with legal weight behind it. The other arrives as a friendly email from someone whose job title mentions “advisory” or “review.” For Oracle Java specifically, the friendly email is by far the more common opening move — and treating it as harmless is the single most expensive mistake an organisation can make. This guide explains how the soft audit and the formal audit differ, why Oracle leans on the soft route for Java, and how your response should change depending on which one you are in.

Two kinds of Oracle review

Every Oracle customer relationship sits on top of a contract — usually the Oracle Master Agreement (OMA) or its predecessor, the Oracle License and Services Agreement (OLSA). Buried in that contract is an audit clause that gives Oracle the right to verify your usage, typically with 45 days' written notice and no more than once a year. That clause is the legal engine of a formal audit.

A soft audit uses none of it. It is a commercial conversation dressed as a courtesy — an email, a phone call, a “licensing review” — that asks you to volunteer information Oracle has no contractual right to demand. Both routes lead to the same place: a number Oracle wants you to pay. They simply take very different roads to get there, and the road you are on dictates your rights, your obligations, and your best response.

What a soft audit looks like

A soft audit rarely announces itself as an audit. It arrives as something that sounds helpful. The common openings:

• An email from an Oracle “License Management” or “Global Licensing and Advisory Services” contact offering to help you review your Java estate.
• A note stating that “our records show downloads of Oracle Java from your organisation” and asking you to confirm your deployment.
• An invitation to a “Java licensing health check” or webinar, followed by a request for an inventory.
• A friendly call from your account manager mentioning that “a lot of customers are getting their Java position in order this year.”

The defining features are consistent: no contractual clause is cited, no formal notice period is given, the tone is consultative rather than adversarial, and — crucially — you are being asked to supply data, not ordered to. The soft audit's entire power comes from what you choose to hand over.

What a formal audit looks like

A formal audit is unmistakable. It arrives as a letter or email that explicitly invokes the audit or verification clause of your Oracle agreement. It names the contract, cites the clause, sets a start date, and usually gives the 45 days' notice the contract requires. It names Oracle's audit team — historically License Management Services (LMS), now operating as Global Licensing and Advisory Services (GLAS) — and it asks you to run Oracle's scripts or measurement tooling and return the output by a deadline.

The language is procedural and firm. There is a defined scope, a defined process, and a defined endpoint: an audit report stating a licence shortfall and a financial demand. A formal audit carries real obligations — but because the rules are written down, it is in some ways more predictable than the soft audit that has no rules at all.

Why Oracle prefers the soft route for Java

For Java specifically, Oracle opens far more soft reviews than formal audits, and the commercial logic is clear. A formal audit of an entire Java estate is slow and resource-heavy for Oracle, too. The soft audit shifts that work onto you: if Oracle can get you to self-report, it never has to run the audit machinery at all. The soft audit also carries no notice period and no fixed scope, so Oracle keeps maximum flexibility.

Most important of all, the soft audit relies on something you may not realise Oracle holds: its download records. Every time someone in your organisation downloaded Oracle JDK from oracle.com using an Oracle account, that download was logged against your company. Oracle often already has a list of your downloads before it emails you. The soft audit is an invitation to confirm what Oracle suspects — and ideally to over-disclose. The employee-based metric does the rest: because Java SE is priced on total headcount, even a modest confirmed footprint can be converted into an organisation-wide claim.

Soft vs formal: side by side

Dimension	Soft audit	Formal audit
Trigger	A commercial email, call or “review” offer	A formal notice citing the audit clause
Contractual basis	None invoked	Audit / verification clause of the OMA or OLSA
Notice period	None	Typically 45 days' written notice
Who runs it	Sales or a GLAS advisory contact	The GLAS / LMS audit team
Your obligation	None — participation is voluntary	Contractual cooperation, within a defined scope
Data flow	You are asked to volunteer an inventory	Oracle scripts and formal data requests
Tone	Consultative, helpful	Procedural, firm
Endpoint	A quote or commercial proposal	An audit report with a stated shortfall
Best first move	Control disclosure; confirm nothing prematurely	Confirm scope; engage advisors; manage the process

Responding to a soft audit

The instinct on receiving a friendly licensing email is to be helpful — reply quickly, attach an inventory, “get ahead of it.” That instinct is exactly what the soft audit is designed to exploit. The correct posture is courteous but disciplined:

• Do not volunteer data. You have no obligation to share an inventory, run scripts, or confirm download records in a soft audit. Anything you send becomes the basis of a claim.
• Acknowledge politely, commit to nothing. A short reply confirming receipt is fine. Do not agree to timelines, screen-shared calls, or “quick” data requests.
• Establish the facts internally first. Before any conversation with Oracle, find out what you actually run — which Oracle JDK versions, which update levels, on how many machines, under which licence (BCL, OTN or NFTC). You cannot negotiate a position you do not understand.
• Treat it as the early stage of an audit, because it is. The soft audit is a negotiation that has already started. Bring in independent advisors now, not after you have disclosed.
• Keep it in writing. Move the conversation to email so there is a record and so you control the pace.

Responding to a formal audit

A formal audit cannot be ignored — the contract obliges you to cooperate — but cooperation is not the same as complying with every request exactly as written. The priorities:

• Confirm and narrow the scope. The audit clause defines what Oracle may examine. Hold Oracle to it; do not let the audit expand into products or legal entities outside the named scope.
• Control the data. You, not Oracle, should run discovery and review the output before anything leaves the building. Oracle's scripts and self-declaration spreadsheets are framed to maximise the count.
• Run a parallel internal assessment. Establish your own defensible licence position before you see Oracle's. The gap between the two numbers is the negotiation.
• Engage independent advisors and, where the numbers warrant it, legal counsel. Former Oracle audit staff know exactly how the report is built and where it overstates.
• Manage the timeline. Audits drift, and deadlines are negotiable far more often than Oracle implies. A measured pace favours the customer.

When a soft audit turns formal

The two routes are connected. A soft audit that does not get Oracle what it wants — either disclosure or a deal — can be escalated into a formal audit. This is the implicit leverage behind the friendly email: work with us now, or we do this the hard way.

In practice, escalation is less automatic than Oracle implies. Formal audits cost Oracle time and goodwill, and Oracle would generally rather close a soft review with a signed subscription than open a formal process. The threat of escalation is real, but it is also a negotiating tactic. Knowing that lets you respond to a soft audit from a position of calm rather than fear: you are not obliged to disclose, and the formal route is not the catastrophe it is made to sound.

Mistakes that escalate a review

Certain moves reliably make either kind of review worse: replying to a soft audit with a full inventory before you understand your own position; joining an unstructured call where Oracle leads the questions; running Oracle's scripts without reviewing what they capture; treating a soft audit as “not a real audit” and ignoring it until it hardens; conceding the employee metric or a headcount figure casually in conversation; and missing the licence nuances — BCL versus OTN versus NFTC — that often mean far less is licensable than Oracle's opening number assumes. Every one of these hands Oracle leverage that is very hard to claw back.

Frequently asked questions

Is an Oracle Java soft audit legally binding?

No. A soft audit invokes no contractual clause and creates no obligation to share data, run scripts, or attend meetings. Its power comes entirely from what you choose to disclose, which is why disciplined, minimal engagement is the right response.

Can I ignore an Oracle Java soft audit?

Ignoring it entirely is risky, because an unanswered soft audit can be escalated to a formal one. The better approach is to respond courteously, confirm receipt, commit to nothing, and use the time to establish your real licence position before engaging further.

How much notice does a formal Oracle audit require?

Oracle's standard audit clause typically requires 45 days' written notice and limits audits to once a year. The exact terms are in your Oracle Master Agreement or OLSA, which should be the first document you read when a formal notice arrives.

Does Oracle really track Java downloads?

Yes. Downloads of Oracle JDK from oracle.com made with an Oracle account are logged against the organisation. Oracle frequently has download records in hand before it sends a soft-audit email, which is why those emails ask you to confirm rather than report.

Should I run Oracle's audit scripts?

Not without review. In a soft or a formal audit, you should run discovery yourself, review exactly what the output contains, and understand your licence position before any data reaches Oracle. Oracle's tooling is built to maximise the measured count.

Conclusion

The most dangerous thing about an Oracle Java soft audit is that it does not feel dangerous. It arrives as help, not as a threat, and the natural, courteous response — sending an inventory, hopping on a call, confirming the download records — is exactly the response that builds Oracle's claim. A formal audit, for all its legal weight, is in some ways easier: the rules are written down. Whichever one lands in your inbox, the principles hold — understand your own licence position before you disclose anything, hold Oracle to the contract, control the data and the timeline, and treat the review as the negotiation it already is. Do that, and the difference between a soft audit and a formal one becomes a matter of process, not of outcome.