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

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

Oracle E-Business Suite (EBS) licensing is typically based on the number of Application Users – i.e., the named users authorized to access each EBS module​. To ensure compliance, Software Asset Management (SAM) managers and Oracle licensing specialists must regularly analyze EBS usage and compare it to licensed quantities.

Oracle provides a License Management Services (LMS) Collection Tool (script) to gather data from the EBS application layer for audit and analysis​. This guide offers a practical approach to using the LMS script output to assess EBS application usage, focusing exclusively on the EBS application layer (users, responsibilities/roles, and modules) and excluding database or WebLogic data.

We will explain how the LMS script collects EBS-specific data (such as users, roles/responsibilities, and the modules they can access), describe the key output files it produces, and show how to interpret that data. Crucially, we’ll demonstrate how to map responsibilities to the EBS modules they correspond to (e.g., identifying that a “Payables Manager” responsibility means access to Oracle Payables) and how to calculate the count of active users per module.

We’ll also highlight common red flags (like users with access to unlicensed modules or inactive accounts that are still enabled) and provide best practices to document findings in alignment with Oracle’s user-based licensing (Application User metric).

Data Collection with the Oracle LMS Script (EBS Application Layer)

Oracle’s LMS Collection Tool for EBS is a script (or set of scripts) provided by Oracle’s Global Licensing team to extract usage data from your EBS instance.

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

• Users – A complete list of EBS application user accounts, as stored in the FND_USER table. This shows every user who can log in to EBS details like creation date, end (deactivation) date, and status (active/inactive).
• Responsibilities/Roles – All responsibilities defined in the system (FND_RESPONSIBILITY table, 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 LMS script extracts all responsibilities (with their IDs, internal keys, descriptions, etc.) and often their association with an application/module.
• User-Responsibility Assignments – The mapping of which users have which responsibilities. This is crucial for determining actual usage. The data comes from tables like FND_USER_RESP_GROUPS (or the equivalent user-roles views) which link FND_USER and FND_RESPONSIBILITY. Each assignment typically has a start date and (optionally) an end date, indicating the period the responsibility was active for that user. The script output will list all such mappings, allowing analysis of who has access to what.
• Installed Modules – Information about which EBS product modules are installed in the environment, usually from FND_PRODUCT_INSTALLATIONS. Each module (application) has a status flag indicating if it’s installed, shared, or Not Installed​. (A status of “Installed” or “Shared” generally means the module’s components are present; “Shared” indicates a module that is included as part of another suite or shared installation, not separately licensed in isolation.) This helps identify the scope of modules that could be in use.

Note: The LMS script for EBS does not directly assess database options or WebLogic servers – it targets the EBS application layer data only (as requested, we exclude database and middleware analysis here).

By collecting the above information, the script essentially provides the raw data needed to list all users and the exact EBS applications/modules those users can access via their responsibilities​. The next step is for SAM/licensing specialists to interpret this data to understand module usage versus entitlements.

Read Analyzing Oracle Middleware with the LMS Collection Tool.

Key Output Files and Data Extracted

After running the LMS collection script for EBS, you will typically receive a set of output files (often in CSV or TXT format). Each file corresponds to a specific data set.

The exact filenames can vary, but commonly they are named after the tables or data they contain.

Below are the key output files and what they include:

• FND_USER.csv – Lists all EBS application users. For each user, it usually includes fields such as: USER_NAME (the login), USER_ID, employee/person link (if integrated with HR), creation date, last login date, end date (if the account is end-dated), and whether the account is currently active. This file lets you identify how many total users exist and which are active versus disabled. It’s the foundation for counting licenses because each active user potentially consumes a license.
  • How to use it: Filter this list to active users only (for example, those with no end date or with an end date in the future). Inactive or end-dated accounts can typically be excluded from license counts (but be cautious: if an account is not end-dated and only “not used,” Oracle may still consider it licensable​).
• FND_RESPONSIBILITY.csv – Contains definitions of all responsibility in the EBS system. Important fields include RESPONSIBILITY_NAME (the display name), RESPONSIBILITY_KEY (a unique short name), and RESPONSIBILITY_ID, and the APPLICATION_ID that ties the responsibility to a specific EBS application (module). There may also be a description and end date if a responsibility was deactivated. This file essentially catalogues what roles exist in the system and to which functional area each role belongs​.
  • How to use it: This list is useful for understanding the universe of responsibilities. Not every responsibility is relevant in licensing terms, so focus on those assigned to users (the rest might be unused). Also, pay attention to the APPLICATION_ID or the associated application name for each responsibility, as this indicates the module (more on mapping this in the next section).
• User-Responsibility Mapping – Depending on the script version, this may come as a separate file or as part of a combined report. It might be named USER_RESPONSIBILITIES.csv or be embedded in a larger “LMS Detail” output. Essentially, it’s a list of each user and their responsibility, often including that assignment’s effective start and end dates. This data is pulled from FND_USER_RESP_GROUPS (or the newer role-based equivalents)​. Each record shows a user ID (or name) paired with a responsibility ID (or name).
  • How to use it: This is the core for usage analysis. By filtering this mapping to active users and active responsibilities (where the current date is between the start and end dates, and neither the user nor responsibility is end-dated), you get all active user-responsibility pairs – i.e., every active user’s current access rights. From here, you can derive which modules each user can use.
• FND_PRODUCT_INSTALLATIONS.csv (Modules Inventory) – Lists all EBS applications (modules) in the system, with a status flag (e.g. “I” for Installed, “S” for Shared, “N” for Not Installed)​. It also typically provides the APPLICATION_ID and the application’s name (like “Oracle General Ledger”, “Oracle Payables”, etc.). This file effectively shows which modules are present in the environment.
  • How to use it: It helps filter the analysis into relevant modules. Generally, you consider modules that are “Installed” or “Shared” as ones that could be used. If a module is Not Installed (N), you likely won’t have any responsibilities for it in use. The status “Shared” indicates certain modules (especially some technical or common ones) that are automatically included (for example, some infrastructure components or modules provided as part of a suite). For license compliance, if a module is “Installed” or “Shared” and users have responsibilities for it, it should be counted toward usage.

Other files: The LMS tool might output additional files (for example, data on Oracle Application Server or WebLogic if it were included, database options usage, etc.), but for our purposes, we concentrate on the files above.

Also, summary reports may combine some of the info (such as an “Active Users and Responsibilities” report in EBS or a summary count by module). Always retain all raw data files, as they back up your analysis.

Mapping Responsibilities to EBS Application Modules

Understanding which module a given responsibility belongs to is critical. In Oracle EBS, responsibilities are defined under a specific application (which corresponds to an EBS module or product).

Each responsibility in FND_RESPONSIBILITY has an APPLICATION_ID That links to FND_APPLICATION (the table of all modules).

Thus, you can determine the module by either:

• Looking at the name of the responsibility, Oracle’s seeded responsibilities usually include the module name or acronym. For example, “Payables Manager” clearly relates to Oracle Payables (Accounts Payable module), and “General Ledger Super User” relates to Oracle General Ledger. This approach is quick but relies on familiarity with naming conventions.
• Joining to FND_APPLICATION – A more reliable method is to join the responsibility’s APPLICATION_ID to the FND_APPLICATION_TL table to get the full application name. For instance, a responsibility with APPLICATION_ID corresponding to “SQLAP” (Payables) will map to the “Oracle Payables” application name. The LMS script may have already done this join in its output, showing an “APPLICATION_NAME” field for each responsibility or each assignment​. If not, you can manually map using a reference list of application IDs.

In practice, Oracle LMS specialists map each responsibility to its module as part of the analysis​. This allows you to say “User X has responsibility Y, which means they have access to module Z (and therefore need a license for Z).”

Read Complete Oracle EBS Application Module List.

Below are examples of common EBS responsibilities and the module each one is associated with:

Table: Examples of standard EBS responsibilities and their corresponding application module. Each responsibility grants access to the menus and functions of its module. For example, a user with Payables Manager can use the Oracle Payables module, and a General Ledger Super User can use Oracle General Ledger.

Note that some responsibilities (like System Administrator, Application Developer, etc.) pertain to the EBS foundation layer (they belong to the Application Object Library or similar) – these are typically needed for administrative tasks and would usually be held by a subset of users (they still count as EBS users, but they are not tied to a business module license except that any user with such a responsibility would need to be licensed for at least one module in the suite).

When reviewing LMS output, determine the module for each responsibility assigned to users. It may help to create a lookup table or spreadsheet tab where you list all unique responsibility names from the LMS data and add a column for the corresponding module. This mapping will aggregate users by module in the next step.

Interpreting the Data: Active Users per Module

Once you have the user-responsibility assignment data and know which module each responsibility is related to, you can calculate usage per module.

Oracle’s Application User licenses are counted per module – every unique user with access to a given module should count toward that module’s license count​. The following steps outline how to interpret the LMS data to get active user counts for each module:

1. Filter to Active Assignments: Exclude any responsibilities that are end-dated or any users that are end-dated. In other words, consider only users who are currently active and have at least one active responsibility. (An “active” responsibility assignment means today’s date is between the start and end date FND_USER_RESP_GROUPS for that user responsibility, and the user’s account is not expired.) This ensures you’re counting actual current usage.
2. Map Each Assignment to a Module: Translate each user-responsibility pair into a user-module pair using the responsibility-to-module mapping. For example, if UserA has the “Payables Manager” and “Purchasing Buyer” responsibilities, you map that to UserA -> Oracle Payables, and UserA -> Oracle Purchasing.
3. Group by Module and Count Unique Users: For each module, aggregate the list of users with any responsibility. It’s important to count unique user IDs per module (to avoid double-counting a user with multiple responsibilities in the same module). For instance, if UserA has two responsibilities in Oracle Payables, that user should be counted once for Payables. SQL-wise, this is a COUNT(DISTINCT user_id) grouped by application module​. The result will be like: General Ledger – 25 users; Payables – 30 users; Purchasing – 18 users; etc.
4. Identify Roles of “Shared” Modules: Some modules might be marked as “Shared” in the installations list. If users have responsibilities under a “Shared” module, you should still count those users; however, you’ll need to understand licensing implications (often “Shared” modules are technically required components of licensed suites and may not require a separate license, but any user accessing them is usually already counted under a primary module license – see Oracle’s definition of your license bundle for clarity).

By performing the above, you essentially get the number of active users for each EBS module. This is the key output needed to compare against your purchased licenses (usually, you have X number of licenses for each module). Here is an Example output of an EBS usage analysis, showing each module (Application Name) with its status and active user count.

The LMS script data can generate a report like the above, which lists each installed application and how many active users can access it. In this sample, each row is an EBS module (e.g. Advanced Product Catalog, Assets, Bills of Material), the Status indicates it’s installed, and Active_User_Count is the number of distinct active users with responsibilities in that module.

For instance, “Advanced Product Catalog” has 4342 active users in this environment, meaning 4,342 unique user accounts have at least one responsibility related to the Advanced Product Catalog module. Similarly, “Assets” (Oracle Assets) has 10 active users.

This kind of summary is exactly what you need to match against entitlements: if you had only licensed five users for Assets but 10 are found with access, you’d be out of compliance. On the other hand, modules with zero users (not shown above) or that are not installed can be noted as not currently in use.

Active vs. Inactive Users and Usage

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

This means that 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 the company or no longer need access​.

Suppose the LMS script output shows several users with no recent activity but still active accounts. In that case, they will appear in the counts – you should flag these and consider them in your cleanup plan (they represent potential license savings if removed or a compliance risk if left enabled without licenses).

One can also cross-verify user activity (for example, using the sign-on audit or last login info in FND_USER) to distinguish active usage versus just active authorization. While licensing is based on access, such information can help prioritize which accounts to disable if they are not truly needed. But for the counting exercise, stick to the rule: if they are enabled with responsibilities, count them.

Red Flags to Watch For in the Usage Data

While analyzing the LMS script output, certain findings should raise concern. These “red flags” might indicate compliance issues or inefficiencies in how access is managed:

• Users with Responsibilities for Unlicensed Modules: This is the top concern – if the data shows users assigned to a module that your organization has not purchased or licensed, it’s a compliance gap. For example, if you see five users with “Inventory Super User” but your company didn’t license Oracle Inventory, those users are effectively using (or capable of using) an unlicensed product. In Oracle’s view, any user who can access a module requires a license​, so even if they haven’t used it yet, just having the responsibility is enough to trigger a finding. Action: Identify why those responsibilities were assigned. Sometimes, it’s a mistake or leftover from testing. Remove or replace them immediately with appropriate, licensed responsibilities and document the removal.
• Inactive Users Still Enabled: Compare the user list with HR records or last login timestamps. If you find accounts of former employees or contractors still active in EBS with responsibilities, this is a problem. As long as an account is provisioned, Oracle can and will count it as a licensable user​, even if the person has left the company. This inflates your required license count unnecessarily. Action: Work with IT to end-date or lock such accounts. It’s good practice to have a process to disable EBS accounts immediately when personnel leave or roles change.
• Generic or Shared Accounts: Sometimes, organizations create generic logins (e.g., “APCLERK1” used by multiple people) or share one account among several users to save licenses. This is not compliant with Oracle’s Application User licensing. 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 (for example, if one account has an unusually high number of responsibilities across many modules, or if audit logs show simultaneous usage from different machines). Action: Eliminate shared accounts. Create individual accounts for each user and assign them appropriate responsibilities. If you truly have a “concurrent user” license model (rare in modern Oracle licensing), that’s different, but most licenses are named user, so shared accounts are a red flag.
• Responsibilities That Seem Out of Place: Look for any user with responsibilities that don’t match their job function or department, which can indicate over-provisioning. For example, an HR user with a Purchasing responsibility might signal that a generic role was over-assigned. This can lead to licensing a user for modules they don’t need. Also, check for powerful responsibilities like the System Administrator assigned to too many people. While SysAdmin itself might not be licensed separately, it could mean those users have broad access, and Oracle will scrutinize if all are necessary. Action: Principle of least privilege – ensure users only have responsibilities (hence module access) necessary for their role. Remove any extraneous responsibilities to potentially reduce the license footprint.
• Custom Responsibilities Covering Multiple Modules: Be very careful if your organization created custom responsibilities (common in EBS) that include functions from multiple modules. A single responsibility could theoretically provide access to forms in, say, both Payables and Purchasing. In such cases, that one responsibility would require the user to have licenses for both modules. The LMS script might show the responsibility under one module (depending on the APPLICATION_ID under which it was created), potentially underestimating multi-module access. Action: Identify custom responsibilities and analyze their menus. If they include functions from other modules, treat those users as accessing all included modules. It might be wiser to split such responsibilities or at least account for the multi-module access in your license counts.
• Inactive Responsibilities Still Assigned: Similar to inactive users, if a responsibility was end-dated (perhaps to stop its use) but still shows up on user accounts without being removed, it could confuse analysis. Generally, an end-dated responsibility won’t allow the user to log in to that responsibility after the date, but it’s best practice to remove or replace it outright. This is more a data hygiene flag than a license one (since end-dated responsibilities shouldn’t count as access), but it is worth checking.
• High Number of Users in Certain Modules Unexpectedly: If a particular module shows a very large user count that you didn’t anticipate, investigate why. Sometimes, this happens because a self-service or indirect responsibility was widely given (for example, an “Expenses User” responsibility under the Internet Expenses module could be given to all employees). If that module wasn’t licensed for all employees, it’s a compliance overrun. Or if it was supposed to be licensed enterprise-wide, ensure the metric aligns (maybe it should have been licensed by an enterprise metric instead of named users). Action: Verify if your license metrics for such modules are different (some modules like iExpenses and iProcurement might be licensed by employee count or corporate metric rather than individual user – check your contract). If not, you may need to true-up the licenses or revoke access for some users.

In summary, use the LMS output to spot discrepancies between what is deployed/accessible and what is contractually allowed. Any responsibility assignment that doesn’t align with a purchased module or any excess of users over the licensed number for a module is a red flag. It’s better to catch these in an internal review than for Oracle to find them in an audit.

Best Practices for Organizing and Presenting Findings

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

Here are bthe est practices for organizing the findings from your EBS usage analysis:

• Map and Document Everything: Maintain a clear mapping of responsibilities to modules (perhaps in a spreadsheet tab, as mentioned). This serves as your reference. Document any assumptions in this mapping. For example, if a responsibility name didn’t map, note how you determined its module (via APPLICATION_ID or menu content). This will be important if questioned.
• Module-by-Module Summary: Create a summary table or report that lists each EBS module alongside key metrics: number of active users with access, number of licenses owned for that module, and any observations. This makes it easy to see where you are compliant and where you are not. For example: EBS ModuleActive Users (from LMS data)Licensed Users (entitlement)StatusOracle Payables (AP)30255 Over DeployedOracle Receivables (AR)12153 SpareOracle Purchasing1820OK (within limits)Oracle Projects00OKOracle Human Resources (HR)5050OK (maxed out)Oracle Inventory5Not LicensedUnlicensed Usage Table: Example compliance summary by module. Such a table highlights where action is needed. In this example, Payables has more users than licenses (needs reduction or purchase of 5), and Inventory has 5 users but no license (urgent investigation required).
• Detailed User Listings for Each Module: In addition to the summary, keep a breakdown (possibly as an appendix or separate worksheets) listing which specific users are counted for each module. This is useful for remediation – e.g., if you need to remove some users from a module, you know who they are. It’s also something Oracle may request during an audit (to prove how you counted users).
• Identify Indirect Usage: Make notes on any indirect or hidden usage. For instance, call that out if a user is counted under a module only because of some technical responsibility (like a workflow responsibility that touches that module). You may need to discuss with Oracle whether those users truly require a full license or if there’s an exception. Oracle’s stance is typically strict (access = license), but it’s worth documenting the nuances.
• Align with Oracle’s Definitions: Use Oracle’s own terminology in your documentation. For example, Oracle calls the metric “Application User” – use that term. Note that Application User licensing is based on access rights, not actual usage of features. Your findings should reflect that principle (e.g., don’t try to argue a user shouldn’t count because they “didn’t use” the module yet – Oracle doesn’t accept that; if they can use it, they count).
• Regular Audits and Clean-up: Treat this as a periodic exercise, not a one-time. One best practice is to run the LMS script internally before Oracle ever asks, perhaps twice a year, to catch issues early​. After each run, address the red flags: remove needless responsibilities, end-date stale users, and true-up licenses if necessary. Document the changes made (this can demonstrate a proactive compliance posture).
• Access Control Processes: Implement controls so new user provisioning doesn’t create new compliance issues. For example, if someone requests a certain responsibility, have a check against a list of licensed modules to ensure you have the capacity. If not, that request should trigger a license purchase or an alternative solution (like giving more limited access). Regular access reviews (management should review who has access to what, at least annually) are advisable​. This not only helps with security but also keeps licensing in check.
• Use of Reporting Tools: Consider augmenting the analysis with any available EBS reports or third-party tools. Oracle EBS has an “Active Users and Responsibilities” standard report that lists the number of users per responsibility, etc. Tools like Oracle Enterprise Manager or third-party SAM tools might also integrate LMS outputs to produce dashboards. Ensure the data is consistent with your LMS script findings. If there are discrepancies, investigate them.
• Communication with Oracle: If you find during internal analysis that you are under-licensed for a module, plan how to address it. This may involve purchasing additional licenses or reducing usage. Document the gap and the plan. It’s often better to proactively purchase the needed licenses (or remove access) before an official audit, as penalties or back-support fees can apply if Oracle finds you out of compliance.
• Audit Trail: Keep the output files from the LMS script and any queries or spreadsheets you used to create your analysis. Oracle’s auditors might run the same script and compare the results in an audit. You want to show that you used the official script and didn’t alter the data (except to filter out truly inactive accounts appropriately). An audit trail of how you went from raw data to final counts builds credibility.

Finally, always cross-reference your findings with your Oracle EBS license contracts. Pay attention to special licensing metrics (some modules might be licensed by processor, by enterprise metrics like revenue or employee count, or have user minimums).

For most EBS modules, the “Application User” metric is the norm, and the approach above applies. Systematically analyzing LMS script output and following these best practices will create a clear picture of your EBS usage.

This helps ensure compliance with Oracle’s licensing policies and often reveals opportunities to optimize – for example, identifying unused accounts or modules not actually needed can allow you to reduce license counts or reallocate them where needed.

Do you want to know more about our Oracle Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit