Oracle EBS Usage Analysis Guide

Why EBS Usage Analysis Matters

Oracle E-Business Suite (EBS) is one of the most heavily audited Oracle products. According to our analysis of Oracle Licence Management Services (LMS) findings, approximately 70% of Oracle EBS customers face some form of non-compliance risk, with the average exposure measured at $1.2 million. The stakes are high: a single EBS audit can result in millions in additional licence costs if usage patterns do not align with contracted metrics.

Oracle LMS audits typically start with EBS module usage analysis because this is where the largest gaps emerge. The number-one finding in almost every EBS audit is inflated user counts. Customers frequently maintain user access to modules they no longer actively use, granted responsibilities for legacy processes, or provision users for business continuity that never materialises. When Oracle runs their collection tool against your database, they count every authorised user—not just active users—as a licence obligation.

Annual usage analysis is not optional for organisations running EBS at scale. It serves multiple critical functions: it identifies over-provisioned users and unused module responsibilities; it uncovers licence metric mismatches where users are assigned to modules your contract does not cover; and it prevents audit surprises by forcing you to confront your actual position before Oracle arrives. Organisations that conduct proactive, disciplined usage reviews often discover cost-reduction opportunities worth hundreds of thousands of pounds—savings that go straight to the bottom line or can be redirected to strategic investments.

The cost of analysis is trivial compared to the risk. A comprehensive EBS usage review conducted internally or with an independent advisor takes 30 to 90 days and costs a fraction of a single audit remediation. The alternative—waiting for Oracle to contact you—leaves you reactive, pressured, and negotiating from a weak position.

Oracle EBS Licence Metrics and What to Measure

Understanding the metrics you are actually licensed for is the foundation of any compliance analysis. Oracle has changed EBS licence metrics multiple times over the past decade, and many organisations hold legacy contracts with outdated terms. It is essential to know exactly which metrics govern your EBS deployment.

Application User Metric

The primary EBS licence metric is the Application User. Under this metric, a user is an individual authorised to use a specific EBS module regardless of whether they actually log in. Oracle defines an Application User as a named individual who has access to a specific module through a responsibility or role assignment. Critically, this includes users who have not logged in for months or even years. If a responsibility assignment is active (END_DATE is null or in the future), the user counts as licensed, period.

Many organisations are shocked to discover their true Application User count when the LMS tool runs. A user might have been granted a responsibility years ago during a project, no longer need it, and forgotten to have it removed. From Oracle's perspective, that user is licensed and must be counted.

Named User Plus vs Application User

Older EBS contracts may reference Named User Plus (NUP) rather than Application User. These are effectively equivalent in modern audits, though the definition has evolved. Named User Plus historically implied a named individual rather than a concurrent user or shared account. When comparing your contract to Oracle's interpretation, ensure you understand whether your contract uses "Named User Plus" or "Application User" terminology—they may be used interchangeably in Oracle's audit documents even if your signed contract uses different language.

Processor Metric

Some organisations licence EBS under the Processor metric instead of user-based metrics. Under Processor licensing, you pay based on the total number of processor cores running the EBS application tier servers, multiplied by an Oracle Core Factor based on the processor type. Oracle publishes a Core Factor Table that assigns a multiplier to each processor family. For example, an Intel Xeon processor might have a Core Factor of 1.0, while an older processor might have 1.5. If you run EBS on a 16-core processor with a Core Factor of 1.0, your licence requirement is 16 cores.

Processor licensing is typically more economical for large, multi-tenant EBS deployments or when you have high numbers of external users (such as suppliers or customers accessing a self-service portal). During your analysis, if you are licensed on Processor cores, verify that your current application server configuration matches what you contracted and what Oracle's Core Factor Table currently specifies.

Legacy and Enterprise Metrics

Concurrent User metrics are no longer available for new EBS purchases but remain in many legacy contracts. If your agreement references Concurrent Users, be aware that Oracle interprets this as the peak number of simultaneous sessions at any point in time, not the number of named users. Concurrent User audits are particularly aggressive because Oracle will often point to a single peak moment captured in database logs—even if that peak lasted seconds—to justify a licence increase.

Certain HR and payroll modules may also be licensed under Enterprise metrics based on employee headcount or revenue. These are less common but extremely important to identify correctly. If your HR module licence is based on employee count, you must ensure that the count Oracle audits matches your actual employee population (or contracted employee population, if there is a defined cap).

Oracle Licence Definitions Document

Oracle publishes an official Licence Definitions and Restrictions document that governs how all licence metrics are interpreted. As of March 2025, this is the authoritative reference for how Oracle will interpret your licence obligations. If you are unsure about any aspect of your metrics, consult this document or have an independent licensing advisor review it against your contract.

The Oracle LMS Collection Tool for EBS

Oracle's LMS team uses a specific, SQL-based collection script to gather EBS usage data during audits. Understanding what this tool collects, how it works, and how to run it proactively is essential to understanding your actual compliance position.

What the LMS Collection Tool Gathers

The Oracle LMS script connects directly to your EBS database and queries several critical tables: FND_USER (the user master table), FND_USER_RESP_GROUPS (user-to-responsibility assignments), and FND_RESPONSIBILITY (the responsibility registry). From these tables, the tool extracts the following:

• User counts by module: How many unique users have been granted at least one responsibility in each EBS module (HR, Financials, Projects, Inventory, etc.).
• Responsibility assignments: Detailed lists showing which users hold which responsibilities and when those assignments became active and inactive.
• Last login dates: The most recent login timestamp for each user, allowing Oracle to distinguish active from dormant users (though this is secondary to the responsibility-based count).
• Concurrent session peaks: The maximum number of simultaneous sessions recorded over a specified period, useful for Concurrent User licensing audits.
• Inactive users: Users whose END_DATE has passed or whose accounts are disabled.

The output is typically a set of CSV or Excel files that lay bare your actual usage footprint. This data is what Oracle will reference if they audit you. If you run this tool yourself before an audit, you will see exactly what Oracle sees.

How to Run the LMS Collection Tool

The LMS script requires DBA-level database access to your EBS instance. Oracle provides the script directly, but independent advisors like Redress Compliance also maintain equivalent versions that produce comparable output. Running the tool is straightforward but time-consuming on large databases:

• Execute the SQL script against your EBS production database (or a recent clone if you want to avoid production impact).
• The script typically takes 30 to 90 minutes depending on database size and the number of users and responsibilities in your system.
• Output is generated as CSV files in a designated directory.
• Review the output carefully. Do not share the raw output with Oracle unless requested as part of an official audit, as it contains sensitive user information.

Many organisations run this tool quarterly or semi-annually as part of a broader licence management governance program. The cost of DBA time to run the script is negligible compared to the value of understanding your position.

How to Interpret LMS Collection Data

Raw LMS output can be confusing, especially for organisations new to licence compliance. Here are the key interpretation principles that will guide your analysis.

Module Activation and Responsibility Grants

A user is considered licensed for a module if they have been granted at least one responsibility that grants access to that module—even if they have never actually logged in or do not use the functionality. The responsibility assignment itself creates the licence obligation. This is critical: intent does not matter. A user granted a responsibility two years ago and never used is still licensed. A user who received a responsibility during a failed implementation project is still licensed unless the responsibility is explicitly removed.

Active vs. Inactive User Distinction

The LMS tool will flag users as active or inactive based on END_DATE and last login. However, Oracle's primary counting mechanism is based on active responsibility assignments, not login activity. A user with an active responsibility but no login in the past two years is still counted as a licensed user. The login data is useful for justifying why certain users should be deactivated, but absence of login is not itself sufficient to reduce your licence count.

Responsibility Cluster Analysis

One of the most important insights from LMS analysis is identifying responsibilities that grant access to multiple modules. A single user may hold three or four responsibilities, each of which unlocks access to different modules. If a user holds responsibilities that grant access to HR, Financials, and Inventory modules, that user must be licensed for all three modules. Your analysis must account for this cumulative requirement.

Create a responsibility-to-module mapping matrix early in your analysis. Identify "heavy responsibility" assignments that grant access to many modules at once. These are often administrator or super-user responsibilities, and organisations frequently over-grant them to users who need only narrow functional access.

Shared and Batch Processing Accounts

EBS deployments typically include shared accounts for batch processing, system integration, and report generation. Oracle treats these as licensed users, each requiring a named Application User licence. If you have 20 batch processing accounts running overnight jobs, you need 20 Application User licences for those accounts. Some organisations try to argue that batch accounts should not count as users, but this argument fails under Oracle's definitions. You cannot avoid licensing these accounts; you can only minimise the number you maintain.

Read-Only User Reclassification

One legitimate pathway to reducing your user count is reclassifying users as "read-only." Under Oracle's licence rules, if a user has access only to reports, dashboards, and inquiries with absolutely no transactional capability, they may qualify for a lower-cost read-only user licence (such as Oracle Analytics or BI consumer licence) rather than a full Application User licence. However, this reclassification requires careful analysis: a user must have zero transactional access across all modules. If the responsibility profile contains a single transactional action (such as the ability to modify a field, post a journal entry, or approve a requisition), the user cannot be classified as read-only. The bar is very high. Most organisations find that very few users genuinely qualify for read-only status.

Step-by-Step EBS Usage Analysis Process

Conducting a disciplined EBS usage analysis follows a structured methodology. Here is the process we recommend, broken into actionable steps.

Step 1: Extract User and Responsibility Data

Run the Oracle LMS Collection Tool or equivalent custom SQL queries against your EBS database. Target the FND_USER, FND_RESPONSIBILITY, and FND_USER_RESP_GROUPS tables. Export the results as CSV. Filter the data to include only active users (where END_DATE is null or in the future). This gives you the raw population you are actually licensing. At this stage, you might discover you have 800 active users when you thought you had 500. This is not uncommon.

Step 2: Map Responsibilities to Licence Categories

Create a responsibility-to-module mapping matrix. For each responsibility in your system, document which modules it grants access to. Many organisations inherit this data from their EBS implementation documentation; others must reverse-engineer it from the application metadata. Identify responsibilities that are obsolete, unused, or granted for legacy reasons. For each user in your population, determine which modules they can access based on their responsibility assignments.

Step 3: Identify Over-Provisioned Users

Segment your user population to find candidates for deprovisioning or re-assignment:

• Users with multiple module responsibilities: Identify users whose responsibilities grant access to modules they do not use or no longer need. Are they actually performing work across all those modules?
• Inactive users with active responsibilities: Flag users who have not logged in for 90+ days but retain active responsibility assignments. These are prime candidates for deactivation.
• Test and training accounts in production: Many organisations leave test and training accounts active in the production database. These should be deactivated or moved to non-production instances.
• Shared accounts with excessive permissions: Review batch, integration, and generic system accounts. Do they need access to all the modules currently granted?

Step 4: Calculate Your Licence Requirement

Sum the active users per module, accounting for cross-module responsibility assignments. If you are licensed on a Processor metric, verify your current application tier server configuration against your contract and the current Oracle Core Factor Table. Document your calculated licence requirement clearly. This is your "what we actually owe" number.

Step 5: Identify Gaps and Remediation Actions

Compare your calculated requirement to your contracted licences. Identify under-licensed modules and over-licensed modules. Develop a remediation roadmap:

• Remove unused responsibilities: Work with business stakeholders to identify responsibilities that are no longer needed and remove them from active users.
• Deactivate stale accounts: End-date user accounts that have been inactive for more than 90 days (with business approval). This is one of the quickest ways to reduce your user count.
• Reclassify read-only users: If any users genuinely qualify as read-only, reclassify them to a lower-cost licence tier.
• Consolidate shared accounts: Reduce the number of batch and integration accounts where feasible by consolidating their functions.

Step 6: Document and Maintain the Analysis

Create a formal evidence file documenting your analysis, assumptions, and remediation actions. Store this file securely; it will become your defence document if Oracle audits you. Set calendar reminders for quarterly or semi-annual re-analysis. Licence compliance is not a one-time exercise; it is an ongoing governance responsibility. As your organisation adds or removes users, the analysis must be updated.

Common Compliance Findings in EBS Audits

Oracle's audit teams follow a consistent playbook. Understanding the common findings helps you anticipate what Oracle will focus on and ensures your analysis covers the same ground.

Under-Licensed Modules

This is the most frequent finding: a user's responsibility assignments grant access to a module that is not in your licence agreement. For example, you may have contracted for Financials and HR licences but not Projects. If a user has a responsibility that grants access to Projects (such as a project controller responsibility), you are under-licensed for that module. Oracle will bill you for every such user they discover.

Self-Service Module Over-Use

Oracle HR Self-Service, iProcurement, iExpenses, and similar self-service modules are frequently the source of under-licensing. These modules grant access not only to the EBS team but often to large populations of business users (employees, managers, suppliers). Many organisations do not realise they need to licence these populations. Oracle's analysis will count every employee who has a self-service responsibility as a licensed user.

Interface-Driven Users

Batch jobs, middleware integrations, and external system feeds often create "users" in EBS to authenticate and run transactions. A customer portal integration might create 100 external user accounts. A middleware solution might use a generic service account. Oracle counts all of these as users and requires licences for them.

Read-Only User Misclassification

Organisations sometimes claim that certain users should be classified as read-only when Oracle's analysis shows they have transactional access. Oracle audit teams scrutinise these claims carefully. If a user can execute even a single transactional function (e.g., modify a field, approve a requisition), they cannot be classified as read-only. Misclassification is often discovered and challenged by Oracle during audit remediation.

Oracle Portal and OAF Custom Pages

EBS deployments often include custom web pages built in Oracle Portal or Oracle Application Framework (OAF) that expose EBS data or functionality through APIs. If these custom pages grant access to EBS transactions or data, users accessing them may require EBS licences. Oracle occasionally challenges organisations on whether custom portal access creates additional licence obligations.

Tools and Techniques for Ongoing Analysis

After your initial analysis, maintaining your licence position requires ongoing discipline and the right tools.

Oracle UMX (User Management Extension)

Oracle's UMX framework provides centralised access control for EBS. Configuring UMX properly helps you restrict responsibility assignments to only those roles and users that genuinely need them. Using UMX as part of your access governance reduces the risk of accidental over-provisioning.

Role-Based Access Control (RBAC)

Implement and enforce RBAC policies in EBS to cluster responsibilities and control the scope of access. Instead of granting individual responsibilities, grant roles that represent job functions. This makes it easier to audit who has access to what and to remove access in bulk when a role is no longer needed.

Third-Party SAM Tools

Software Asset Management (SAM) platforms such as Flexera, Snow, and ServiceNow ITOM can integrate with EBS through Oracle's Software Asset Management Pack (SMAP) to collect usage data automatically on an ongoing basis. These tools generate periodic reports that make it easy to spot user growth trends, identify inactive accounts, and validate your licence position without running manual collection scripts.

Oracle EBS Audit Framework

EBS includes built-in audit logging that tracks user access changes, responsibility assignments, and transaction activity. Configure the audit framework to capture user provisioning and deprovisioning events. Review audit logs monthly to catch unusual access patterns or unexpected responsibility grants.

Scheduled Quarterly Reviews

Establish a quarterly or semi-annual rhythm of automated reports from the FND tables showing current user activity. Assign responsibility for reviewing these reports to a single business owner (often in IT or Finance). Use the reports to trigger timely deprovisioning of inactive users and to validate your overall licence count.

Optimising Your Licence Position Post-Analysis

Analysis is only useful if it leads to action. Once you have identified gaps and over-provisioning, the next step is optimisation—restructuring your licence position to reduce costs and exposure.

Module Licence Rationalisation

Remove unused or decommissioned module licences from your Customer Support Identifier (CSI) at your next Oracle support renewal. If you no longer run the Projects module, do not renew licences for it. Oracle's support fees increase by 8% per year, so retaining unnecessary licences compounds your costs annually.

User Count Reduction

Reduce your contracted Application User counts to match your actual authorised user population (plus a small buffer for planned growth, typically 5-10%). This is the most immediate way to reduce your annual support costs and future audit exposure.

Processor Licence Negotiation

If you have high volumes of external-facing or self-service module usage, Processor licensing may be significantly cheaper than user-based licensing at scale. Use your usage analysis to model the cost-benefit of switching from Application User to Processor licensing. If Processor licensing is more favourable, negotiate this change with Oracle during your next renewal.

Decommissioning Documentation

If you are fully decommissioning an EBS module (e.g., moving from Oracle Financials to a modern accounting platform), document the decommissioning process carefully. Maintain evidence that the module is no longer in use and that you have removed all related user access. This evidence protects you if Oracle later questions why you removed licences for that module.

Renewal Negotiation Leverage

Use your usage analysis as leverage during Oracle support renewal negotiations. If your analysis shows that you are over-licensed for certain modules or that your user count has decreased due to organisational changes, present this data to Oracle. This gives you a factual basis for negotiating lower renewal fees.

Preparing for an Oracle EBS Audit

Proactive analysis is your best defence if Oracle contacts you about an audit. Here is how to prepare.

Timeline and Triggers

Oracle audits can be triggered by a support renewal, a customer complaint, a random compliance review, or a system migration. Most customers receive 30 days' notice before an audit begins. If you suspect an audit may be coming (e.g., your last audit was 3-4 years ago), run your usage analysis 90 days in advance so you have time to remediate any obvious issues.

Engage Independent Advisors Early

Before engaging directly with Oracle's LMS team, engage an independent licensing advisor to review your position. The advisor can run the same collection tools Oracle will use, give you an unbiased assessment of your exposure, and help you develop a remediation strategy. This step is critical: it prevents you from walking into a meeting with Oracle without understanding your actual position.

Legal and Contractual Review

Do not run the Oracle LMS tool on behalf of Oracle without legal review of the audit agreement or terms. Understand your contractual rights regarding audit frequency (most agreements limit audits to once per year), data protection, and remediation timelines. A contract attorney should review these terms before you share any data with Oracle's auditors.

Remediate Before Audit Scope Confirmation

If you identify compliance gaps in your pre-audit analysis, remediate them before Oracle's audit team confirms their audit scope. Removing unnecessary user accounts, deleting obsolete responsibilities, and documenting decommissioning actions all happen before the audit officially starts. Once the audit scope is confirmed, Oracle will benchmark your position as of that date—you cannot retroactively remove users or licences.

Prepare a Clean Position Document

Develop a formal document that describes your current licence position, supported by evidence from your analysis. Document the number of Application Users per module, the basis for any read-only user claims, and any decommissioning actions you have taken. Present this document to Oracle's audit team upfront. It establishes your good-faith understanding of your position and prevents Oracle from treating you as uncooperative.

How Redress Compliance Supports EBS Usage Analysis

EBS usage analysis is complex, and the stakes are high. Many organisations benefit from independent expertise to ensure their analysis is thorough and defensible.

Equivalent Collection Methodology

Redress uses the same LMS collection methods and equivalent SQL scripts that Oracle's auditors use. This means our analysis shows you exactly what Oracle will see when they audit you—no surprises. We run the collection tool in your environment (with appropriate security controls) and generate the same output reports Oracle would produce.

Gap and Over-Compliance Identification

Our analysis identifies both gaps (where you are under-licensed) and over-compliance (where you have paid for licences you do not need). We quantify both the risk and the opportunity. This balanced perspective helps you decide where to focus remediation efforts and where you can negotiate cost savings.

Audit Defence Preparation

If Oracle audits you after we have conducted our analysis, we provide audit defence support. We supply the evidence files, usage reports, and expert testimony that help you defend your position. Our team has 20+ years of Oracle LMS experience and understands how Oracle interprets usage data, contractual language, and compliance positions.

Remediation Planning and Implementation Support

Beyond analysis, we help you develop and execute a remediation roadmap. This includes user deprovisioning strategies, responsibility re-assignment planning, documentation of decommissioning actions, and licence count optimisation. We work alongside your IT and business teams to ensure remediation happens cleanly and on schedule.

Ongoing Licence Governance

Our engagement often extends beyond a single audit cycle. We help organisations establish ongoing licence governance practices: quarterly usage reviews, access control improvements, SAM tool implementation, and periodic re-baseline analyses. This transforms licence compliance from a crisis-driven activity into a structured, ongoing discipline.