Oracle EBS Licensing Audit: Preparation and Defense

How Oracle EBS Audits Are Initiated

Oracle EBS licensing audits are conducted by Oracle's License Management Services (LMS) team — a dedicated group within Oracle whose function is to identify and monetize customer license compliance gaps. An EBS audit is initiated in one of two primary ways: through Oracle's contractual audit rights (most Oracle contracts grant Oracle the right to audit with 45 days' written notice) or through Oracle's "Compliance Review" program, which is positioned as a voluntary self-assessment but carries implicit pressure to participate.

When Oracle sends an audit notification, the letter typically requests that the customer provide technical data about their EBS deployment within a defined timeframe. This data collection is performed using Oracle-provided scripts. What you provide in response to that data collection request substantially shapes the scope and findings of the audit — which is why engaging independent expertise at notification is critical, not after Oracle has already generated its findings.

Oracle's audit rights are broad. Most Oracle contracts allow Oracle to audit on 45 days' notice, and many contracts allow repeat audits annually. There is no contractual protection against being audited repeatedly, though Oracle typically targets accounts where it estimates the largest gap between licensed and deployed use.

Oracle LMS Scripts: What They Collect

Oracle's License Management Services data collection scripts are SQL-based queries run against your EBS application database and server infrastructure. They are designed to extract the precise data Oracle needs to build a compliance assessment. Understanding what the scripts capture — and what they don't — is essential for preparing an effective response.

User and Access Data

The LMS scripts extract:

• All EBS user accounts (FND_USER table), including active and inactive users
• User-to-responsibility mappings (FND_USER_RESP_GROUPS), showing which application responsibilities each user has access to
• Last logon dates — used to identify "active" vs. dormant users, though Oracle's contract often doesn't recognize dormant accounts as unlicensed
• User counts by application module, derived from the responsibilities assigned

Module Access Data

The scripts map Oracle responsibilities to product licenses. Each EBS responsibility is associated with a product — and if users have responsibilities linked to a module your organization hasn't licensed, that creates a finding. The scripts also capture:

• Which Oracle application modules are installed and activated in your environment
• Navigation menu access patterns that may indicate usage of unlicensed modules
• Concurrent manager job history showing which executable programs have been run — evidence of functional module use even without direct user navigation

Server and Infrastructure Data

For Processor metric licensing assessments, LMS scripts capture:

• Server hardware configuration — number of physical processors and cores per processor
• Virtualization configuration — whether VMware, Hyper-V, or other hypervisors are in use
• Operating system details — used to identify which Core Factor Table multiplier applies
• Cluster and high-availability configurations — used to determine whether HA nodes require separate licenses

The Most Common EBS Audit Findings

Based on extensive experience with Oracle EBS audits, the following findings appear most consistently across organizations of all sizes and industries:

1. Unlicensed Self-Service Users

The single most common EBS audit finding is self-service users who have not been counted in the license position. Employees who access EBS through portals — submitting expense reports via iExpenses, submitting timesheets through Time and Labor, requesting HR changes through Self Service HR — require Named User Plus licenses. An organization that has 500 licensed EBS users but deployed self-service access to 5,000 employees is carrying a 4,500-user shortfall that Oracle's LMS scripts will surface immediately through the FND_USER table.

2. Unlicensed Modules

Organizations frequently run EBS modules that were not formally licensed. This typically happens when implementation consultants activate modules as part of standard EBS configuration, or when business users gain access to adjacent modules through their workflow without IT being aware. Oracle's responsibility-to-product mapping in the LMS scripts will identify users with access to modules not in your Oracle license order.

3. Processor Undercounting Due to Virtualization

Organizations running EBS on VMware typically count only the vCPUs allocated to their EBS virtual machine when calculating Processor license requirements. Oracle's position — consistently enforced in audit findings — is that all physical cores on the VMware host must be licensed under the Processor metric when soft partitioning is used. A VMware host with 64 physical cores running a VM with 8 vCPUs allocated to EBS requires 32 Processor licenses (64 cores × 0.5 Core Factor), not 4 (8 vCPUs × 0.5).

4. Indirect Access Through Third-Party Applications

When a third-party application — a BI tool, an ETL platform, a custom application — queries EBS data, Oracle has historically argued that the users of the third-party application require EBS licenses. The indirect access doctrine is legally contested and contract-language-specific, but it remains a standard Oracle LMS audit play, particularly in EBS environments with extensive data integration.

5. Dormant User Accounts

EBS accounts for employees who have left the organization — or changed roles that no longer require EBS access — remain in the FND_USER table unless actively disabled and removed. Oracle's LMS scripts typically capture all accounts regardless of last logon date, and Oracle's position is that any account with access constitutes a license requirement regardless of usage frequency.

Finding Type	Frequency	Typical Exposure
Self-service user undercount	Very High	High — scales with employee population
Unlicensed modules	High	Medium to High
VMware Processor undercount	High	Very High — multiplied by hardware config
Indirect access (3rd party)	Medium	High — contested but costly to litigate
Dormant user accounts	Very High	Low to Medium

EBS Audit Preparation: Steps to Take Before Oracle Arrives

The most effective Oracle EBS audit defense is one that begins before you receive Oracle's notification. Organizations that conduct regular internal license reviews — and remediate findings before Oracle identifies them — consistently achieve better outcomes than those who first learn their position when Oracle presents its findings.

Step 1: User Account Hygiene

Conduct a complete review of your FND_USER table. Disable accounts for terminated employees, contractors, and consultants. Remove responsibilities from users whose roles have changed. This is the single highest-return preparation activity because dormant accounts represent an indefensible finding that Oracle will count against you while adding zero business value.

Step 2: Module Access Inventory

Map every active EBS responsibility in your environment to the Oracle product license it requires. Compare this map against your Oracle license order to identify any responsibilities linked to unlicensed products. This exercise frequently surfaces modules activated during implementation that were never formally licensed. Remediating these gaps before audit — either by licensing the module or removing access — is substantially less costly than resolving them in an audit context.

Step 3: Virtualization Position

If EBS runs on VMware or Hyper-V, document your physical host configuration and calculate Oracle's audit position on Processor licensing. Understand the gap between your current license count and what Oracle would calculate under its soft partitioning rules. This analysis informs both your defense strategy and any remediation options — including migration to Oracle VM or physical server consolidation — that might reduce your exposure before an audit.

Step 4: Contract Review

Pull your Oracle license order documents and read the definitions. What exactly does your contract say about Named User Plus? Does it include any carve-outs for self-service users? What does it say about indirect access? Older Oracle contracts sometimes contain more favorable language than current Oracle policy would suggest — the contract, not Oracle's current published policies, governs your licensing obligations.

Responding to an Oracle EBS Audit Notification

When Oracle sends an audit notification, your response in the first two weeks materially affects the outcome. The most important actions:

1. Engage independent expertise immediately. Oracle LMS auditors are experienced, well-prepared, and focused on identifying findings that generate revenue. Having former Oracle LMS professionals on your side before you respond to Oracle's initial data request is essential. Our Oracle audit defense service provides exactly this support.
2. Do not run Oracle LMS scripts without review. The scripts Oracle provides are designed to collect maximum data. Review them independently — some scripts collect data beyond what is strictly necessary for license compliance assessment. You have the right to negotiate the scope of data collection.
3. Document your position before responding. Know your own user counts, module access, and infrastructure configuration before Oracle does. Your response to LMS data requests should be accurate but should not volunteer information beyond what is requested.
4. Treat the process as a negotiation, not an investigation. An Oracle audit is fundamentally a revenue recovery exercise. Oracle's initial findings are often overstated and subject to negotiation. Every finding should be reviewed critically, challenged where appropriate, and resolved through negotiation rather than acceptance.

For comprehensive guidance on the full Oracle audit process — including contractual rights, LMS script review, and settlement negotiation — see our Oracle Audit Defense Guide and our detailed analysis in Oracle Licensing White Papers.

Negotiating EBS Audit Findings

Oracle's initial audit findings are rarely the final settlement position. Common negotiation levers include:

• Challenging the user count methodology. Oracle's LMS scripts may overcount users by including accounts that meet a contractual exemption — embedded software users, non-human accounts, service accounts — or by miscategorizing user types. Every count deserves scrutiny.
• Contesting indirect access findings. The indirect access doctrine is not absolute, and its application depends on your specific contract language. Many indirect access findings can be reduced or eliminated through contract interpretation arguments supported by legal counsel.
• Negotiating through Oracle's commercial teams. Once Oracle LMS has presented findings, the negotiation often moves to Oracle's sales team. This creates an opportunity to resolve audit findings as part of a broader commercial negotiation — potentially converting a compliance liability into favorable terms on a renewal or cloud migration deal. Understanding Oracle's commercial motivations is essential here.

For detailed case studies of EBS audit outcomes, see our client case studies. Our team of former Oracle insiders — not affiliated with Oracle Corporation — has successfully defended EBS audit findings on behalf of organizations across all industries and geographies. See also our related guide: Oracle EBS Licensing Overview and our Oracle EBS Module Licensing guide.