The single largest advantage in any Oracle audit belongs to the party that knows the number first. For most enterprises that party is Oracle, because the vendor arrives with collection scripts, a core factor table, and a view of deployment the customer has never assembled for itself. The position can be reversed. A standing internal view of the Oracle estate, maintained and reconciled before any letter arrives, means the buyer meets a finding already knowing where it is solid, where it is exposed, and what the defensible figure looks like. That knowledge is the foundation of compliance, and it is entirely within the buyer's control to build.
Why know your Oracle license position before an audit?
You should know your Oracle license position before an audit because a finding then becomes a number you set rather than one Oracle imposes, since the preliminary finding arrives inflated at list price and a line by line review typically cuts it 60 to 80 percent. When the audit letter lands, the buyer who has already reconciled deployment against entitlement is not learning the shape of the estate under deadline pressure. The exposures are known, the documentation exists, and the inflated portions of any finding can be challenged immediately rather than discovered in panic. The buyer who has done none of this is forced to react to Oracle's version of the truth, and reaction is the weakest posture in a negotiation that was always going to turn on who controlled the facts.
What goes into an internal Oracle license position?
An internal Oracle license position reconciles what is deployed against what is entitled, across every metric Oracle uses to count. That means processor counts measured against the core factor table, Named User Plus counts checked against per processor minimums, options and management packs reconciled against what is genuinely in use rather than merely installed, and Java reconciled against the per employee Universal Subscription metric. Each of these is a place where exposure hides. A single Enterprise Manager click can enable Diagnostics or Tuning Pack, many options install by default, and the gap between installed and used is exactly where an inflated finding grows. The position is the document that closes those gaps before Oracle can open them.
| Area | Deployment view | Entitlement view |
|---|---|---|
| Database processors | Cores in scope | Licences against the core factor table |
| Named User Plus | Users counted | Counts against per processor minimums |
| Options and packs | Features in use | Options actually licensed |
| Java | Employees and contractors | Universal Subscription scope |
How often should you review your Oracle position?
You should review your Oracle position at least quarterly and after any material change, because exposure can shift between reviews faster than most teams expect. Options can be enabled with a single Enterprise Manager click, a virtualization or cloud migration can move workloads across hosts in ways that change the licensable footprint, and an acquisition can bring a new estate inside the same agreement overnight. A position reconciled once a year is stale by the time it is read. A quarterly cadence, with an extra review triggered by any significant change to the estate, keeps the internal view honest and means the gap between what the buyer believes and what is actually deployed never grows large enough to surprise anyone.
A mid sized enterprise reconciled its Oracle estate quarterly and found that a management pack had been enabled during routine database administration, creating a small but real exposure. Because the review caught it within the quarter, the team could decide deliberately whether to license the pack or disable the feature, rather than discovering it inside an audit finding priced at list. When an audit letter did arrive months later, the management pack question was already settled, documented, and off the table. The standing position turned what would have been an inflated line item into a non issue.
What is the difference between installed and used?
The difference between installed and used is the single most valuable distinction in an Oracle position, and it is contract dependent in how it is measured. Oracle's collection scripts often report features as installed when they have never been used in production, and an inflated finding leans heavily on counting installation as consumption. The internal position separates the two: it records what is genuinely running, against what is merely present by default, and keeps the evidence that supports the distinction. Whether a particular usage signal counts as licensable consumption can turn on the wording of the agreement, so the position flags those questions as contract dependent and resolves them against the signed terms rather than against Oracle's policy documents, because contract language beats policy.
What is the buyer move?
The buyer move is to build the internal position now, before any letter arrives, and to keep it current on a quarterly cadence. Reconcile deployment against entitlement across processors, Named User Plus, options, and Java, separate installed from used with evidence to support it, and resolve every contract dependent question against the signed agreement. Hold that position as a living document, refreshed after any material change to the estate. When Oracle eventually counts, the buyer who already knows the number meets the finding from strength, and the gap between the opening figure and the defensible one is theirs to close, not Oracle's to exploit.
For the records that make the position defensible under scrutiny, see entitlement records that hold up. For turning the position into something leadership can act on, see compliance metrics for the board. The full method sits in the Oracle license compliance guide.