Oracle Audit & LMS Glossary: 56 Audit Terms Defined for the Buyer-Side

Oracle's historical compliance audit team — responsible for issuing audit notices, running data collection, calculating findings, and presenting back-licence claims. LMS is the function name that appears in many older OMAs and is still in widespread industry use. The LMS team's mandate is revenue protection, not customer service; every LMS engagement must be approached on that footing.

Oracle's rebrand of the LMS function, positioning the team as "advisory" rather than audit. The mandate is unchanged — revenue protection through compliance findings — but the language softens the engagement framing. GLAS appears in current OMAs, audit notices, and pre-engagement communications. Buyer-side discipline: treat any GLAS engagement with the same audit-defence rigour applied to a formal LMS audit, regardless of the "advisory" framing.

The formal letter from Oracle initiating a compliance audit under the OMA's audit-rights clause. The Audit Notice cites the specific clause, names the audit scope (programs, time period, entities), and sets the engagement timeline. The Audit Notice is the single document on which the buyer-side defence pivots — every subsequent engagement step must be measured against what the Audit Notice contractually permits, not against what Oracle's LMS team subsequently requests.

An informal Oracle engagement that is framed as a "review", "advisory", or "best-practice assessment" but functions as a compliance audit in substance. Soft Audits typically begin with a request to run a data-collection script "to support optimisation". The data collected is the same data Oracle would collect under a formal audit, with the same exposure to findings. Buyer-side discipline: treat every Soft Audit as a formal audit from the moment the data request appears, and run the same defence playbook.

The contractual notice period Oracle must provide before commencing an audit. Standard OMA: 45 days. Negotiated OMAs sometimes extend to 90 days. The notice period is the buyer-side preparation window — the time available to build the Deployment Snapshot, run the internal counting exercise, identify defensible reductions, and engage external audit defence specialists before LMS's data-collection clock starts.

The defined boundary of the audit — which Oracle programs, which legal entities, which deployment environments, and which time period are inside the engagement. Audit Scope is set by the Audit Notice and is contractually fixed by the OMA's audit-rights clause. Buyer-side discipline: enforce the audit scope rigorously — every LMS data request that ventures outside the stated scope must be challenged, and scope expansion mid-audit must be refused absent a new Audit Notice.

The historical time period the audit examines — typically two to three years backward from the Audit Notice date. The Audit Window determines how far back compliance findings can attach. Buyer-side discipline: the Audit Window must be confirmed in the Audit Notice and not silently expanded during the engagement; LMS will sometimes pull data older than the stated window and use it to colour the findings narrative.

The senior LMS individual responsible for the audit outcome. The Audit Director's mandate is to maximise the recovery against the customer, calibrated against the customer's likely strategic-deal trajectory with Oracle. Buyer-side discipline: the Audit Director is the appropriate escalation point for procedural challenges and for settlement framing; engaging at the right level matters for the negotiated close.

The opening engagement meeting where LMS introduces the audit team, presents the data-collection plan, and seeks agreement on the engagement timeline. The Kick-Off Meeting is where Oracle anchors the audit framing — buyer-side discipline is to attend with experienced audit defence counsel, refuse to commit to data-collection scope beyond what the Audit Notice permits, and clarify the engagement governance before agreeing to next steps.

The document LMS may propose to formalise the audit scope, timeline, and data-collection process. The Engagement Letter is not a contractual requirement — the OMA audit-rights clause is the contract — and Engagement Letters often expand Oracle's data-collection rights beyond OMA boundaries. Buyer-side discipline: review any Engagement Letter line-by-line, and refuse provisions that expand audit scope or grant Oracle rights the OMA does not.

Oracle's database measurement script — the SQL-based collection routine that audits installed Oracle Database deployments and the options enabled on each. USMM (sometimes called the Oracle Server Worksheet) extracts data about Database edition, options usage (Partitioning, Advanced Security, In-Memory, Active Data Guard, Real Application Clusters), management pack usage, and the CPU/core configuration of the underlying host. The USMM output is the primary evidence base for Database audit findings.

Oracle's lightweight assessment script, positioned as a "quick check" or "self-assessment" tool. Reviewlite collects substantively the same data as USMM, framed as informal review. Customers who run Reviewlite voluntarily before any formal audit notice often discover the script output becoming the evidence base for a subsequent Audit Notice. Buyer-side discipline: do not run Reviewlite or USMM scripts unless contractually required, and never run them outside a formal audit defence framework.

BMC's data-centre discovery platform, which Oracle has historically relied on for environment-wide visibility during audits. Tideway data shows every host, every Oracle binary, every operating system, and every network connection inside the audited environment. Where the customer runs Tideway internally for IT asset management, LMS will request access to the Tideway data; buyer-side discipline is to provide only the subset of Tideway data that maps to the contractually defined audit scope.

The audit examination of which Oracle Database options (Partitioning, Advanced Security, Diagnostics Pack, Tuning Pack, Active Data Guard, etc.) have been used on each Database instance during the audit window. Options Drill-Down is where Database audits most commonly produce material findings — option usage that the DBA team did not realise was happening, often triggered by a single feature use that the option licensing covers. Every Database instance where any option flag has ever been touched is a finding candidate.

The Oracle Database internal view that records every feature touched during the database's life, including options and management packs. LMS uses DBA_FEATURE_USAGE_STATISTICS as the primary evidence for option-usage findings. Buyer-side discipline: review the view contents proactively before any audit, document every usage event, and prepare the contractual justification for each option flag that has been touched.

Oracle's Java SE measurement script — collects installed Java versions, deployment counts, OTN-licence indicator data, and process-tree data showing Java SE in production use. The Java Audit Script output is the primary evidence base for Java SE Universal Subscription back-licence claims. Buyer-side discipline: the Java audit script must not be run unless mandated by formal audit notice, and the resulting data must be reviewed before LMS sees it.

The customer-led measurement and disclosure of Oracle deployments, often requested by LMS as a "cooperative" alternative to formal audit. Self-Audit is a real defence option when applied with discipline — running the measurement internally with experienced audit defence counsel before LMS sees the data lets the customer correct counting errors and present a defended position. Self-Audit conducted without external defence counsel typically produces a worse outcome than a formal audit defended by counsel.

Third-party software asset management platforms that produce Oracle licence-position estimates from the customer's own data. SAM tool output is useful as an internal baseline but is not authoritative against Oracle's interpretation of the contract — SAM tool counting often differs materially from Oracle's LMS counting on partitioning, options usage, and virtualisation. Buyer-side discipline: SAM tool output is a starting point for internal analysis, not a defended position against LMS.

The LMS data extract showing all support invoices and entitlement records tied to a Cost Account (CSI). LMS uses CSI data to map the customer's entitled position against the discovered deployment position. CSI Data Pull discrepancies — entitlement records that do not match the contracted position — are common because CSI structure changes over time through M&A, contract renewals, and program rebrands.

Oracle's framing for the data-trust standard the customer must meet under audit — the customer's deployment data must be verifiable, complete, and not selectively edited. The Verifiable Trust standard is the framing LMS uses to refuse partial data delivery or to expand a data request. Buyer-side discipline: comply with the OMA's audit-data requirements precisely, and refuse any LMS framing that requires more than the contract specifies.

The Oracle licence metric where one Processor licence is required for each "Processor" of the host running the Oracle program. Processor is defined by the Core Factor Table — total physical cores multiplied by the Core Factor for the underlying chip architecture. Processor Metric is the standard server-side licence for Oracle Database EE and most Middleware programs in production deployments.

Oracle's published table mapping each supported processor architecture (Intel x86, AMD EPYC, IBM POWER, SPARC, etc.) to a Core Factor multiplier — typically 0.5 for x86, 0.75 for SPARC, 1.0 for POWER. The Core Factor is multiplied by the total physical core count to determine the Processor licence requirement. The Core Factor Table is published by Oracle and changes infrequently, but is the foundational input to every Processor-metric finding.

The user-based Oracle licence metric — one NUP licence is required for each named individual or device that accesses the Oracle program, with minimums applied. Standard NUP minimum: 25 NUP per Processor for Database EE. NUP is the right answer for low-density deployments (development, test, niche production); it becomes expensive at scale, where Processor licensing typically wins. NUP audits focus on whether the deployed user count exceeds the licensed quantity, and whether the per-Processor minimum is met.

The contractual rule that NUP licensing on a server must meet a per-Processor minimum (25 NUP per Processor for Database EE, 10 for Standard Edition 2). The Minimum NUP Rule is the most common NUP audit finding — customers who deployed at a small user count assumed they only needed to license the actual users, missing the per-Processor minimum. The rule applies even where the actual user count is below the minimum.

The user-based licence metric for certain Oracle Application programs (E-Business Suite, PeopleSoft, JD Edwards, Siebel). Application User counts include both employees and non-employees who access the applications, with batch-process and integration-user nuances. Application User audits focus on the broad definition of "user" — any individual who accesses application data, directly or indirectly, counts.

A user-based metric used by certain Oracle programs (some Middleware lines, some legacy products). Authorized User typically counts everyone who has been granted access rights, not just active users. The Authorized User definition extends beyond direct human interaction to indirect access through automated processes and integrations.

The Java SE Universal Subscription metric introduced in 2023 — the licence count is the customer's total employee count (full-time, part-time, contractors, agency staff), regardless of how many employees actually run Java SE. Employee Metric is the most economically punishing Oracle licence metric for customers with broad workforces and narrow Java SE deployment; it converts a workload-specific licence question into an enterprise-wide licence position. Java SE Employee Metric audits typically produce 5–20× the finding magnitude of the predecessor per-Processor and per-NUP metrics.

A device-based licence metric used by some Oracle Middleware programs — one licence per device concurrently connected. Concurrent Device counting is technically complex; audits frequently challenge the customer's deployed concurrency definition. The metric is uncommon in modern Oracle deployments but persists in legacy enterprise systems.

Oracle's current Java SE licensing programme — annual subscription billed against the Employee Metric. The Universal Subscription replaces all predecessor Java SE licence structures and is the only Oracle-supported commercial path for Java SE production use. Universal Subscription pricing is published per employee per year and is non-negotiable on rate; the only variables are Employee count (the customer's defended position) and term length.

The Oracle Technology Network developer licence — historically the free-to-download Java SE licence permitting use only for "Personal Use, Development Use, Oracle Approved Product Use". OTN licence covers no production use; every production Java SE deployment downloaded under OTN terms is a compliance finding under the Universal Subscription audit. The OTN licence is the single most common Java SE finding pattern — internal developers downloaded Java SE under OTN terms and the runtime then propagated into production.

The class of CPU-limiting technologies Oracle does not recognise as licence-reducing — VMware vSphere, Microsoft Hyper-V, Solaris Containers (zones, in certain configurations), KVM, OpenStack, Docker, Kubernetes, and most cloud-vendor hypervisors. Under soft partitioning, Oracle's audit position is that the full physical core count of the underlying host must be licensed regardless of the CPU limit applied to the Oracle VM. Soft Partitioning is the foundational tactical exposure of virtualised Oracle environments.

The Oracle-approved list of partitioning technologies that do reduce the licensable core count — Oracle VM Server (with specific configuration), IBM LPAR, Solaris Containers (configured per Oracle's policy), Solaris LDOMs, Fujitsu PPAR, and a handful of cloud-vendor configurations. Hard Partitioning is documented in Oracle's "Partitioning Policy" white paper, which is a policy document not contractually binding; the buyer-side defence on partitioning relies on the contract text, not on the partitioning policy.

The VMware vSphere cluster configuration — multiple ESXi hosts running a shared workload pool. Under Oracle's soft-partitioning position, the entire cluster's physical core count must be licensed regardless of which hosts actually run Oracle VMs, because VMware vMotion can theoretically migrate the VM to any host. The VMware Cluster position is the single largest source of unexpected Oracle Database findings in virtualised environments.

The VMware vCenter management boundary — defines which clusters and hosts are technically reachable by vMotion. Oracle's audit position from approximately 2016 onward extended the soft-partitioning licensing position to the entire vCenter-managed environment, not just the cluster. Buyer-side defence: the vCenter boundary licensing position is contestable from the contract text; the OMA does not specifically mandate vCenter-wide licensing.

VMware's Distributed Resource Scheduler and vMotion features — the live-migration capability that enables a running VM to move between physical hosts. DRS/vMotion is the technical basis for Oracle's "VMware cluster-wide licensing" audit position. Disabling DRS or restricting vMotion to a defined host subset can technically support a narrower licensing position, but Oracle does not contractually recognise these restrictions absent the Hard Partitioning policy.

VMware host-affinity rules that pin a VM to a defined subset of cluster hosts. Affinity rules technically restrict where the Oracle VM can run, but Oracle does not contractually recognise affinity rules as a licence-reducing mechanism. The Affinity Rules question is a frequent audit dispute — the contract text says one thing, Oracle's policy says another, and the defence relies on the contract.

The Oracle Database deployment running on a standby host for failover. Oracle's standard position: a standby instance must be fully licensed unless it qualifies for the "10-day rule" (production failover for up to 10 days per year without licence), or unless covered by Active Data Guard licensing. DR licensing is one of the most commonly under-licensed configurations and a frequent audit finding.

Oracle's policy permitting a standby Oracle Database instance to run unlicensed for up to 10 separate 24-hour periods per calendar year, specifically for production failover testing. The 10-Day Rule is narrowly drawn — it does not cover continuous standby operation, does not cover read-only Data Guard standby, and does not cover any standby use beyond failover testing. The 10-Day Rule is frequently invoked by customers in defence of DR deployments that do not actually meet its terms.

The specific licence shortfall identified during the audit — a deployment quantity that exceeds the entitled quantity for a defined Oracle program. Findings are itemised in the audit report by program, by deployment site, by metric, and by quantity. Buyer-side defence: every finding must be challenged on its evidence base, its contract interpretation, and its calculation methodology — each of the three is independently contestable.

The numeric difference between deployed quantity and entitled quantity. The Compliance Gap is what LMS converts into a back-licence claim. Buyer-side discipline: the Compliance Gap calculation must be challenged on every input — the deployed quantity (Oracle's measurement), the entitled quantity (CSI data accuracy), and the metric applied (Processor vs NUP vs Application User).

Oracle's demand for the retrospective purchase of licences covering the Compliance Gap, typically priced at list and with back-dated support. Back-Licence Claim is the standard commercial output of an audit and the line where the largest single negotiation lever exists — list pricing is anchored high to give Oracle room to discount toward the negotiated settlement. Defending the deployed quantity, the entitlement record, and the metric applied is the precondition for negotiating the claim downward.

The retrospective support fee LMS adds to the Back-Licence Claim — typically 22% of the back-dated licence value per year of the alleged compliance gap. Back-Support Charge can equal or exceed the back-licence value itself in long-tail findings. Buyer-side defence: the back-support calculation is independently challengeable on the support-rate basis, on the years applied, and on the underlying licence-value figure.

The implicit cost increase Oracle applies to back-licence pricing relative to negotiated forward-pricing — typically resolved through list pricing, no discount applied, with back-support added. The Penalty Multiplier is the cost differential between settling the compliance gap and purchasing the same licences forward at a negotiated discount. Buyer-side defence reduces the Penalty Multiplier by negotiating settlement on equivalent forward-purchase terms.

The formal document LMS issues at the conclusion of the data-collection phase, itemising the findings, the alleged compliance gap, and the calculated back-licence claim. The Audit Report is the document the buyer-side defence rebuts line-by-line. Every finding cited in the Audit Report must be contested where contestable, conceded where indefensible, and the rebuttal documented in writing.

The negotiated commercial conclusion to the audit. Documented Oracle audit settlements typically close at 30–60% of the initial Audit Report claim — a function of contestable findings, evidence rebuttals, and the forward-deal context (settlements often include forward-licence purchase or cloud migration commitment). The Settlement is where the audit defence converts into commercial outcome.

The standard close to a contested Oracle audit — a commercial settlement that does not include any customer admission of non-compliance. Settlement Without Admission framing is essential because the audit data is otherwise reusable in future audits or in regulatory contexts. Buyer-side discipline: every audit settlement must be framed without admission, must include a mutual release of related claims, and must restrict Oracle's use of the audit data in future engagements.

The commercial mechanism by which the Compliance Gap is converted into a forward-purchase commitment rather than a back-licence claim — the customer commits to buying the missing licences forward, at negotiated terms. True-Up is the customer-favourable outcome to most audits because it converts a punitive Back-Licence Claim into a forward-deal that includes negotiated discount, cloud migration, and renewable terms.

The threshold at which audit findings are considered material to the audit conclusion. Material Non-Compliance is the framing Oracle uses to argue that the customer must bear audit costs and that the audit findings have contractual consequences beyond the back-licence settlement. Buyer-side defence: the material-non-compliance threshold must be defined in the OMA itself, not invoked by LMS unilaterally.

The senior buyer-side function — typically external counsel or specialist advisory — that owns the audit defence strategy, controls all communications with LMS, runs the data-collection oversight, and drafts the formal rebuttal of the Audit Report. The Audit Defence Lead is the single point of contact LMS engages with; internal teams must route every LMS communication through the Audit Defence Lead to maintain the defence position.

The buyer-side discipline of independently measuring the deployed Oracle estate under the same metrics LMS applies — but defended against the contract text, with documented methodology, and ready to challenge LMS's count line-by-line. Counter-Counting is the technical core of audit defence; an unprepared customer accepts LMS counts by default, while a Counter-Counted customer challenges them.

The discipline of defending every disputed finding with forensic evidence — log files, system configuration records, DBA documentation, contract text, change-management records. Evidence-Based Defence is the standard LMS expects when challenged credibly; without evidence, every dispute resolves in Oracle's favour. Buyer-side discipline: maintain audit-grade evidence on every Oracle deployment, not just when audit is imminent.

The buyer-side discipline of holding the audit to the contractually defined scope, refusing scope expansion, and requiring fresh Audit Notice for material new scope. Scope Containment is the precondition for an efficient audit defence; without it, LMS expands the engagement opportunistically and the cost of defence multiplies.

The discipline of providing LMS exactly the data the OMA's audit-rights clause requires — no more, no less. Data Minimisation is the buyer-side counter to LMS's natural tendency toward maximum data demand. Over-disclosure is the most common buyer-side audit error; data that exceeds the OMA's scope provides LMS with evidence for findings outside the audit window.

The buyer-side discipline of structuring audit-related communications and analysis under attorney-client privilege where applicable, protecting the customer's internal analysis from LMS discovery. Privilege framing is jurisdiction-dependent and requires the audit defence to involve qualified counsel; the protective effect is real where properly structured.

The buyer-side tactic of converting an audit-defence engagement into a forward-deal negotiation — using the audit context to motivate Oracle's account team toward a strategic renewal, cloud migration or ULA. Forward-Deal Framing is the path through which audits most commonly close on customer-favourable terms; Oracle's account team has stronger incentives to close a strategic deal than to recover the maximum back-licence claim.

The internal procurement governance figure that caps the maximum settlement the customer will pay without further executive approval. The Audit Settlement Cap is the buyer-side analogue to LMS's internal recovery target — it forces the negotiation to converge inside a defined commercial range. Customers without a defined Audit Settlement Cap negotiate toward whatever number LMS lands on.