Run the methodology with a senior advisor.
A senior Admodum advisor will walk the audit-defence methodology through with your CIO, CFO, sourcing or SAM team on a private call. Engagements run as fixed fee, contingency or annual retainer.
Twenty pages on the audit notification, single point of contact, scope contestation, evidence protocol, partitioning treatment, settlement negotiation and the closing letter.
An Oracle LMS audit begins with a letter. The letter looks procedural and is in fact the publisher's opening anchor. What the letter says, what it does not say, and what the buyer says in return decide the next eighteen months of the engagement.
The notification typically asserts a contractual right to verify the buyer's deployment posture under the audit clause of the Oracle Master Agreement, names the in-scope product family in broad terms (Database, Middleware, Applications, Java), proposes a timeline, requests an opening data submission and offers (in a non-committal way) the use of an Oracle-supplied script.
The buyer's first response is a process letter, signed by a named single point of contact, that acknowledges receipt, asks for the audit scope to be set out in writing with the specific clause cited, requests the protocol for evidence collection and the timeline for each step, and confirms the buyer's intent to cooperate inside the contracted terms. The first response does not contain deployment data, inventory output or any indication of estate composition.
Every audit needs a named single point of contact (SPOC). The SPOC is the only authorised communication channel for LMS inbound and outbound. The protocol is set out in writing in the buyer's first response and is enforced by communication discipline.
The SPOC is typically the SAM lead, the head of Procurement or external counsel. The choice is operational. The SAM lead carries the deployment knowledge. The head of Procurement carries the contractual authority. External counsel carries the privileged-communications boundary. In most engagements the SPOC is the SAM lead with external counsel on copy for any communication that touches contractual interpretation.
The SPOC protocol forbids three behaviours inside the buyer's organisation. Application owners do not respond to LMS inbound. IT operations does not run Oracle's discovery scripts without SPOC authorisation. The deployment data is not shared with Oracle in advance of the scope and protocol being agreed in writing.
The audit scope Oracle's notification asserts is rarely the scope the contract supports. The buyer's scope contestation rests on five boundaries: the licensing entity, the corporate-group boundary, the product list, the geographic scope and the time window.
Most Oracle agreements are signed by a single legal entity. The audit clause grants the verification right against that entity. The publisher's notification often extends to the corporate group, the parent, subsidiaries, joint ventures and recent acquisitions. The buyer's contestation distinguishes the licensing entity from the corporate group and asserts the contractual reading.
Oracle's notification frequently names a product family ("Database and Database Options") that maps to dozens of distinct programme licences. The buyer's contestation asks Oracle to specify the exact ordered products in scope, with the SKU, the metric and the contract reference. Products not on the buyer's order documents are not in scope.
Where the buyer operates across multiple jurisdictions under separate Oracle agreements, the audit scope is bound to the jurisdictions covered by the cited agreement. The buyer's contestation asks Oracle to confirm the jurisdictional boundary and the entity-by-entity scope.
The evidence the buyer shares with Oracle is the evidence the buyer has tested for accuracy. The evidence the buyer does not share is the evidence Oracle is contractually entitled to compel, which is narrower than the opening request. The four-pass evidence reconciliation precedes any submission.
The first pass is the CMDB pass. The asset inventory is reconciled against the Oracle product map. Hosts running Oracle products are identified. Hosts that have been retired, sold or decommissioned are documented as out of scope.
The second pass is the deployment pass. Active deployment is verified by host-level inventory. Inactive installations (binaries present but never run) are documented and prepared for removal if they are not contractually required to be licensed.
The third pass is the metric pass. The deployment count is computed against the licensing metric: Processor for unrestricted user-base deployments, Named User Plus for restricted deployments, Application User for application-bound deployments. The metric reading is documented and supported by the contract.
The fourth pass is the option pass. Database Enterprise Edition with Diagnostic Pack, Tuning Pack, Partitioning, Real Application Clusters, Active Data Guard and other options must be counted at the option level. The deployment posture is reconciled against the option entitlement on the order documents.
Partitioning is the single largest source of variance between Oracle's deployment view and the buyer's. The Oracle Partitioning Policy is not a contractual document; it is a guidance document Oracle issues. The policy categorises partitioning technologies into "hard" (narrow, accepted as limiting licensable processor count) and "soft" (broad, asserted as unrestricted).
VMware, in every version, is read by Oracle as soft partitioning. The Oracle position extends the licensable perimeter to the cluster boundary, the vCenter administrative boundary or (in some readings) the underlying storage and network topology. The buyer's counter-position rests on the architectural intent of the cluster boundary, the operational record of workload mobility, the contractual reading of the Oracle agreement (which does not, in most agreements, incorporate the Partitioning Policy) and any concessions Oracle has previously granted in writing.
The counter-position is not built at the audit window. It is built two years earlier, in the deployment architecture, the cluster configuration, the documented workload mobility boundary and the operational change-control record. The audit defence then presents the documented architectural intent and the operational record.
Once the deployment evidence is assembled, the metric and product reconciliation closes the buyer's position. The reconciliation runs against Database Enterprise Edition, options, packs, Middleware (WebLogic, Internet Application Server, GoldenGate, SOA Suite), Applications (E-Business Suite, JD Edwards, PeopleSoft, Siebel) and Java SE.
The settlement is the commercial exit from the audit. It is rarely a cash payment for non-compliance; it is more typically a forward purchase, a renewal extension or a ULA conversion offer that absorbs the audit finding inside a multi-year commercial envelope.
The buyer's BATNA at the settlement window is the residual ability to litigate, to remediate the deployment to compliance, to terminate Oracle products from the estate, or to migrate workloads to alternative platforms. The publisher's BATNA is the ability to enforce the audit clause and to escalate to legal action. Neither side typically reaches the BATNA. The settlement closes inside a forward purchase, a renewal extension or a ULA conversion.
The commercial envelope around the settlement is the buyer's leverage. A settlement priced inside a ULA conversion absorbs the audit finding inside a three-year unlimited-deployment construct. A settlement priced inside an OCI commitment absorbs the audit finding inside a cloud spend the buyer was going to make anyway. A settlement priced as a standalone forward purchase is the most expensive option.
The closing letter records the agreed compliance position, the residual-rights statement, the audit moratorium and any concessions Oracle has granted in writing. Every clause is read.
The compliance position confirms that, as of the audit close date, the buyer's deployment posture is compliant with the order documents. The language must be specific to the products, options and metrics. Generic language ("the buyer is compliant with its Oracle agreements") leaves the residual position ambiguous.
The residual-rights statement confirms the buyer's perpetual rights position against Oracle for the products in scope. The audit moratorium is the clause the buyer most frequently overlooks: a negotiated twelve- to twenty-four-month moratorium on further LMS verification activity is a routine concession Oracle will grant where the buyer asks for it.
The closing letter is the document that protects the buyer for the rest of the agreement. It must be specific, written, signed and held in the contract repository alongside the order documents.
The LMS audit paper sits inside the Oracle four-paper reading list. The companion papers extend the methodology to adjacent Oracle commercial mechanics:
The methodology in this paper is the methodology Admodum has applied across sixty-three Oracle audit engagements inside the firm's history. Each engagement is structured as fixed fee, contingency / gainshare or annual retainer, depending on the buyer's posture at notification.
A senior Admodum advisor will walk the audit-defence methodology through with your CIO, CFO, sourcing or SAM team on a private call. Engagements run as fixed fee, contingency or annual retainer.