Oracle EBS Licensing

Oracle E-Business Suite Usage Analysis Guide (Using Oracle LMS Collection Tool)

A practical guide for SAM managers and Oracle licensing specialists. Learn how to use LMS script output to assess EBS application usage — mapping responsibilities to modules, counting active users, identifying compliance red flags, and documenting findings for Oracle's Application User metric.

Technical GuideOracle EBS & LMS ScriptsFredrik FilipssonJune 2025
FND_USERCore Table for All EBS User Accounts
APPLICATION_IDLinks Responsibilities to EBS Modules
Active ≠ UsedOracle Counts Access Rights, Not Activity
Per ModuleEach Module Requires Separate User Count

📑 In This Guide

  1. Data Collection with the Oracle LMS Script
  2. Key Output Files and Data Extracted
  3. Mapping Responsibilities to EBS Modules
  4. Interpreting the Data: Active Users per Module
  5. Active vs. Inactive Users and Usage
  6. Red Flags to Watch For in Usage Data
  7. Best Practices for Organising and Presenting Findings
📋 Scope Note

This guide focuses exclusively on the EBS application layer — users, responsibilities/roles, and modules. It excludes database or WebLogic/middleware analysis. For middleware analysis, see Analysing Oracle Middleware with the LMS Collection Tool.

📥

Section 1 — Data Collection with the Oracle LMS Script

Oracle E-Business Suite licensing is typically based on the number of Application Users — named users authorised to access each EBS module. Oracle provides a License Management Services (LMS) Collection Tool (script) to gather data from the EBS application layer for audit and analysis.

When run (typically by an Apps DBA using APPS schema credentials), the script queries the core Oracle EBS application tables and writes results to output files. It focuses on who has access to what within EBS.

Key Data Collected by the LMS Script

Data

Users — FND_USER Table

+
A complete list of EBS application user accounts from FND_USER. Shows every user who can log in to EBS — with creation date, end (deactivation) date, last login date, and status (active/inactive). This is the foundation for counting licences because each active user potentially consumes a licence.
Data

Responsibilities/Roles — FND_RESPONSIBILITY

+
All responsibilities defined in the system from FND_RESPONSIBILITY (with names in FND_RESPONSIBILITY_TL). In EBS, a responsibility is a role that grants users access to a specific set of menus, forms, and data related to one or more functional modules. The script extracts all responsibilities (IDs, internal keys, descriptions) and their association with an application/module via APPLICATION_ID.
Data

User-Responsibility Assignments — FND_USER_RESP_GROUPS

+
The mapping of which users have which responsibilities — the most crucial data for determining actual usage. Comes from FND_USER_RESP_GROUPS (or equivalent role-based views) linking FND_USER and FND_RESPONSIBILITY. Each assignment includes a start date and (optionally) an end date. This allows analysis of who has access to what and when that access was active.
Data

Installed Modules — FND_PRODUCT_INSTALLATIONS

+
Information about which EBS product modules are installed, from FND_PRODUCT_INSTALLATIONS. Each module has a status flag: "I" (Installed) — module components are present and active; "S" (Shared) — included as part of another suite or shared installation, not separately licensed; "N" (Not Installed) — not present. If a module is Installed or Shared and users have responsibilities for it, it should be counted toward usage.
Note: The LMS script for EBS does not directly assess database options or WebLogic servers — it targets the EBS application layer data only.
📄

Section 2 — Key Output Files and Data Extracted

After running the LMS collection script, you'll receive a set of output files (typically CSV or TXT). Each corresponds to a specific data set. The exact filenames vary, but commonly they are named after the tables or data they contain.

📁 FND_USER.csv

Lists all EBS application user accounts. Fields include: USER_NAME (login), USER_ID, employee/person link, creation date, last login date, end date (if end-dated), and active status.

How to use: Filter to active users only (no end date or end date in the future). Inactive/end-dated accounts can typically be excluded from licence counts. Caution: if an account is not end-dated and only "not used," Oracle may still consider it licensable.
📁 FND_RESPONSIBILITY.csv

Definitions of all responsibilities in the EBS system. Fields include: RESPONSIBILITY_NAME, RESPONSIBILITY_KEY, RESPONSIBILITY_ID, APPLICATION_ID (ties responsibility to a specific module), description, and end date.

How to use: Focus on responsibilities assigned to users (the rest may be unused). Pay attention to APPLICATION_ID or the associated application name — this indicates the module the responsibility belongs to.
📁 USER_RESPONSIBILITIES.csv (User-Responsibility Mapping)

May come as a separate file or part of a combined report. Lists each user paired with their responsibility, including assignment effective start and end dates. Pulled from FND_USER_RESP_GROUPS.

How to use: This is the core for usage analysis. Filter to active users and active responsibilities (current date between start/end dates, neither user nor responsibility end-dated). The result: all active user-responsibility pairs = every active user's current access rights.
📁 FND_PRODUCT_INSTALLATIONS.csv

Lists all EBS applications (modules) with a status flag: "I" (Installed), "S" (Shared), "N" (Not Installed). Includes APPLICATION_ID and full application name.

How to use: Filters analysis to relevant modules. Generally consider "Installed" or "Shared" modules as ones that could be in use. "Not Installed" modules should have no responsibilities in use.
⚠️ Important

Always retain all raw data files — they back up your analysis. The LMS tool may output additional files (Application Server, WebLogic, database options), but for EBS application layer analysis, concentrate on the four files above.

🔗

Section 3 — Mapping Responsibilities to EBS Modules

Understanding which module a given responsibility belongs to is critical. Each responsibility in FND_RESPONSIBILITY has an APPLICATION_ID that links to FND_APPLICATION. Two approaches:

Method

Approach 1: Naming Conventions

+
Oracle's seeded responsibilities usually include the module name or acronym. "Payables Manager" clearly relates to Oracle Payables; "General Ledger Super User" relates to Oracle General Ledger. This approach is quick but relies on familiarity with Oracle's naming conventions and won't work for custom responsibilities.
Method

Approach 2: Join to FND_APPLICATION (Recommended)

+
Join the responsibility's APPLICATION_ID to FND_APPLICATION_TL to get the full application name. For example, a responsibility with APPLICATION_ID for "SQLAP" (Payables) maps to "Oracle Payables." The LMS script may already show an APPLICATION_NAME field. If not, manually map using a reference list. This is the more reliable method and essential for custom responsibilities.
Best practice: Create a lookup table/spreadsheet tab listing all unique responsibility names from LMS data with a column for the corresponding module. This enables quick module-level aggregation.

Common EBS Responsibilities → Module Mapping

Responsibility NameModule (EBS Application)
General Ledger Super UserOracle General Ledger (Financials)
Payables ManagerOracle Payables (Financials – AP)
Receivables ManagerOracle Receivables (Financials – AR)
HRMS ManagerOracle Human Resources (HRMS)
Order Management Super UserOracle Order Management
Inventory Super UserOracle Inventory
Purchasing BuyerOracle Purchasing (Procurement)
Projects Costing Super UserOracle Projects (Costing/Billing)
Fixed Assets ManagerOracle Assets (FA)
System AdministratorSystem Administration (Foundation — AOL)

Note: Some responsibilities (System Administrator, Application Developer) pertain to the EBS foundation layer. Users with these still count as EBS users, but they are not tied to a business module licence — they need at least one module licence in the suite. See Complete Oracle EBS Application Module List for comprehensive mapping.

📊

Section 4 — Interpreting the Data: Active Users per Module

Once you have the user-responsibility assignment data and know which module each responsibility belongs to, you can calculate usage per module. Oracle's Application User licences are counted per module — every unique user with access to a given module should count toward that module's licence count.

Step-by-Step: Calculating Active Users per Module

Filter to Active Assignments

Exclude end-dated responsibilities and end-dated users. Consider only users who are currently active and have at least one active responsibility (today's date is between start and end date in FND_USER_RESP_GROUPS, and the user account is not expired).

Map Each Assignment to a Module

Translate each user-responsibility pair into a user-module pair using the responsibility-to-module mapping. Example: UserA has "Payables Manager" and "Purchasing Buyer" → UserA → Oracle Payables + Oracle Purchasing.

Group by Module, Count Unique Users

For each module, aggregate the list of users. Count unique user IDs per module to avoid double-counting (a user with two responsibilities in the same module = one licence). SQL: COUNT(DISTINCT user_id) GROUP BY application_module.

Handle "Shared" Modules

If users have responsibilities under a "Shared" module, still count them — but understand licensing implications. "Shared" modules are often required components of licensed suites and may not need a separate licence. Check your licence bundle definition.

Example: Module Usage Summary Output

EBS Module (Application Name)StatusActive Users
Advanced Product CatalogInstalled4,342
Oracle AssetsInstalled10
Bills of MaterialInstalled287
Oracle General LedgerInstalled156
Oracle PayablesInstalled89
Oracle PurchasingInstalled203
Oracle ReceivablesInstalled45
Oracle Human ResourcesShared1,240

Each row shows the distinct active user count with at least one responsibility for that module. This is what you compare against your purchased entitlements.

👤

Section 5 — Active vs. Inactive Users and Usage

Be mindful of what constitutes an "active user" in licensing. Oracle's policy is that anyone authorised to use the software counts as a named user, whether or not they are actively logging in.

Even if a user hasn't logged in recently, as long as their account is active and they have access, they should be counted. A best practice is to regularly end-date or disable accounts for people who have left or no longer need access.

🔑 Oracle's Licensing Rule

Access = Licence. Oracle does not accept the argument that a user "didn't use" the module. If they can use it (active account + active responsibility), they count. The only reliable way to exclude a user from the count is to end-date or disable their account, or remove the responsibility.

You can cross-verify user activity (sign-on audit, last login info in FND_USER) to distinguish active usage versus just active authorisation. While licensing is based on access, this information helps prioritise which accounts to disable if not truly needed. But for the counting exercise, stick to the rule: if they are enabled with responsibilities, count them.

🚩

Section 6 — Red Flags to Watch For in Usage Data

While analysing the LMS script output, certain findings should raise concern. These red flags indicate compliance issues or inefficiencies in access management.

Red Flag

Users with Responsibilities for Unlicensed Modules

+
The top concern. If data shows users assigned to a module your organisation has not purchased, it's a compliance gap. Even if they haven't used the module yet, having the responsibility is enough to trigger a finding — Oracle's stance is that any user who can access a module requires a licence.
Action: Identify why those responsibilities were assigned (mistake, leftover from testing). Remove or replace with appropriate, licensed responsibilities immediately. Document the removal.
Red Flag

Inactive Users Still Enabled

+
Accounts of former employees or contractors still active in EBS with responsibilities. As long as an account is provisioned, Oracle can and will count it as a licensable user — even if the person has left. This inflates your required licence count unnecessarily.
Action: Work with IT to end-date or lock such accounts. Implement a process to disable EBS accounts immediately when personnel leave or roles change.
Red Flag

Generic or Shared Accounts

+
Generic logins (e.g. "APCLERK1" used by multiple people) or shared accounts don't reduce licence requirements. Each individual must be licensed; sharing a login doesn't fool Oracle's audit — they will ask how many individuals use each account. Shared accounts also appear as anomalies (unusually high responsibility counts, simultaneous logins from different machines).
Action: Eliminate shared accounts. Create individual accounts for each user with appropriate responsibilities.
Red Flag

Responsibilities That Don't Match Job Function

+
Users with responsibilities outside their role (e.g. HR user with Purchasing access) indicate over-provisioning. This leads to licensing users for modules they don't need. Also check for the System Administrator responsibility assigned to too many people — while SysAdmin itself may not be separately licensed, it means broad access that Oracle will scrutinise.
Action: Apply principle of least privilege. Ensure users only have responsibilities necessary for their role. Remove extraneous access to reduce licence footprint.
Red Flag

Custom Responsibilities Covering Multiple Modules

+
Custom responsibilities that include functions from multiple modules are especially dangerous. A single custom responsibility could provide access to forms in both Payables and Purchasing — requiring the user to be licensed for both modules. The LMS script may show the responsibility under only one module (depending on which APPLICATION_ID it was created under), potentially underestimating multi-module access.
Action: Identify custom responsibilities and analyse their menus. If they include functions from other modules, treat those users as accessing all included modules. Consider splitting such responsibilities.
Red Flag

Unexpectedly High User Counts in Certain Modules

+
A module showing a very large user count you didn't anticipate warrants investigation. Sometimes a self-service or indirect responsibility is widely given (e.g. "Expenses User" under Internet Expenses assigned to all employees). If that module wasn't licensed for all employees, it's a compliance overrun.
Check: Verify if your licence metrics for such modules differ — some modules (iExpenses, iProcurement) might be licensed by employee count or corporate metric rather than individual user. Review your contract.
✅

Section 7 — Best Practices for Organising and Presenting Findings

Analysing the raw data is only half the battle — the other half is documenting results clearly so you can take action and demonstrate compliance (or gaps) to stakeholders or auditors.

Practice

Create a Module-by-Module Compliance Summary

+
Build a summary table listing each EBS module alongside: active users from LMS data, licensed users (entitlement), and status/observations. This makes it easy to see where you are compliant and where you are not:
EBS ModuleActive UsersLicensed UsersStatus
Oracle Payables (AP)30255 Over Deployed ⚠️
Oracle Receivables (AR)12153 Spare ✓
Oracle Purchasing1820OK (within limits) ✓
Oracle Projects00OK ✓
Oracle Human Resources5050Maxed out ⚡
Oracle Inventory5Not LicensedUnlicensed Usage 🚨
In this example: Payables has more users than licences (needs reduction or purchase of 5). Inventory has 5 users but no licence (urgent investigation required). HR is maxed out (no room for growth).
Practice

Maintain Detailed User Listings per Module

+
In addition to the summary, keep breakdowns listing which specific users are counted for each module (as appendix or separate worksheets). This is useful for remediation — if you need to remove users from a module, you know who they are. Oracle may also request this during an audit to verify your counts.
Practice

Map and Document Everything (Including Assumptions)

+
Maintain a clear mapping of responsibilities to modules. Document any assumptions — if a responsibility name didn't map clearly, note how you determined its module (via APPLICATION_ID or menu content). This is important if questioned by Oracle's audit team. Also note any indirect or hidden usage — e.g. users counted under a module only because of a technical responsibility (like a workflow responsibility).
Practice

Align with Oracle's Definitions

+
Use Oracle's terminology in your documentation. Oracle calls the metric "Application User" — use that term. Note that Application User licensing is based on access rights, not actual usage. Your findings should reflect this principle. Don't argue a user shouldn't count because they "didn't use" the module — Oracle doesn't accept that. If they can use it, they count.

Ongoing Governance Checklist

✔
Run LMS Scripts Internally (Bi-annually)

Catch issues early — run before Oracle ever asks. Address red flags: remove needless responsibilities, end-date stale users, true-up licences.

✔
Implement Access Control Processes

New provisioning requests should check against licensed modules. If no capacity, trigger a licence purchase or limited access.

✔
Conduct Annual Access Reviews

Management reviews who has access to what — at least annually. This helps security and keeps licensing in check.

✔
Maintain an Audit Trail

Keep LMS output files, queries, and spreadsheets. Oracle's auditors may run the same script and compare results — show you used the official script unaltered.

✔
Cross-Reference with Contracts

Check for special metrics — some modules may be licensed by processor, enterprise metric, or employee count rather than Application User.

✔
Proactively Address Gaps

If under-licensed for a module, plan remediation (purchase or reduce usage) before an official audit. Proactive purchases avoid back-support fees.

Need help interpreting Oracle LMS script output or preparing for an EBS audit?

Oracle Audit Defence →
💡 Key Takeaway

Systematically analysing LMS script output helps ensure compliance with Oracle's licensing policies and often reveals opportunities to optimise — identifying unused accounts or modules not actually needed can allow you to reduce licence counts or reallocate them where needed. Treat this as a periodic discipline, not a one-time exercise.

Frequently Asked Questions

What is the Oracle LMS Collection Tool for EBS?+
It's a script (or set of scripts) provided by Oracle's Global Licensing team to extract usage data from your EBS instance. When run by an Apps DBA using APPS schema credentials, it queries core EBS application tables (FND_USER, FND_RESPONSIBILITY, FND_USER_RESP_GROUPS, FND_PRODUCT_INSTALLATIONS) and writes results to CSV/TXT output files. It's used during audits and should also be run proactively for internal compliance reviews.
Does an inactive user who hasn't logged in still require a licence?+
Yes, if the account is active (not end-dated) and has active responsibilities assigned, Oracle counts them as a licensable user regardless of whether they've logged in. Oracle's licensing is based on access rights, not activity. The only way to exclude a user is to end-date/disable their account or remove all their responsibilities.
How do I handle custom responsibilities that span multiple modules?+
Custom responsibilities created under one APPLICATION_ID may include menu items and forms from other modules. The LMS script may only classify the responsibility under its creation module — potentially underestimating multi-module access. You should analyse the menu structure of custom responsibilities and count those users against all modules accessed. Consider splitting such responsibilities to simplify compliance tracking.
What does "Shared" status mean in FND_PRODUCT_INSTALLATIONS?+
"Shared" indicates a module included as part of another suite or shared installation — it's present in the system but not separately licensed in isolation. Technical/common modules often have this status. If users have responsibilities for a "Shared" module, those users should still be counted. However, the licensing implications depend on your specific licence bundle — the module may already be covered under a suite licence you hold. Check your Oracle contract for clarification.
How can Redress Compliance help with EBS licensing analysis?+
Redress Compliance provides independent Oracle advisory services including EBS licence assessments, LMS script output interpretation, audit defence, and compliance remediation. We run the LMS scripts on your behalf, map responsibilities to modules, identify red flags, calculate compliance positions, and present findings in audit-ready format. Our specialists have extensive experience with Oracle's audit process and can negotiate on your behalf if compliance gaps are found.

Our Oracle Advisory Services

🛡️

Audit Defence

Learn more →
📊

Licence Management

Learn more →
🤝

Contract Negotiation

Learn more →
📋

ULA Optimisation

Learn more →

📥 Oracle White Papers

Download our independent guides on Oracle licensing, audit defence, EBS compliance, and contract negotiation

Download White Papers

Facing an Oracle EBS Audit or Licence Review?

Share your LMS script output and contract details. We'll provide an independent compliance assessment, red flag identification, and remediation plan — typically within 48 hours.

Oracle Audit DefenceBook a Consultation

Related Oracle EBS & LMS Resources

LMS Scripts

Oracle LMS Collection Tool — Audit Risks and Best Practices for CIOs
Middleware

Analysing Oracle Middleware with the LMS Collection Tool
Reference

Complete Oracle EBS Application Module List
Licensing

Oracle E-Business Suite (EBS) Licensing Guide for 2025
Licensing

Oracle E-Business Suite Licensing Guide — 2026 Edition
Compliance

Customised Database Technology — Oracle EBS: Identifying Full-Use Licence Triggers
Tools

Best Oracle Licence Management Tools for 2025
Review

What Tools to Use in an Oracle Licence Review
FF

Fredrik Filipsson

Co-Founder @ Redress Compliance

Fredrik Filipsson brings over 20 years of enterprise software licensing experience, including tenures at IBM, SAP, and Oracle. For the past 11 years, he has worked as an independent consultant, advising Fortune 500 companies on complex Oracle EBS licensing, LMS script analysis, audit defence, contract negotiation, and vendor management across Oracle, Microsoft, SAP, IBM, and Salesforce.