Oracle E-Business Suite (EBS) is a comprehensive suite of enterprise applications, including ERP, CRM, SCM, and more, with a modular licensing model. Unlike Oracle Database, which is licensed based on technical metrics, EBS is licensed based on business metrics, such as users or employees, often on a per-module basis.
Understanding EBS licensing involves knowing key metrics, such as application user vs. employee vs. transaction-based metrics, and the concept of restricted-use licenses for technology components.
This section breaks down how EBS modules are licensed and highlights important considerations, such as the included Oracle Database and middleware rights, as well as their limitations.
Modular Licensing and Key Metrics
Oracle EBS consists of multiple modules, including General Ledger, Accounts Payable, Order Management, HR, Payroll, and others. You license each module separately according to its usage.
Common licensing metrics in EBS include:
- Application User – This is essentially a named user license for a specific EBS module. It counts each person authorized to use that module. If a person needs access to multiple modules, they must have a license for each one. For example, if Alice uses both Oracle Payables and Oracle Purchasing, she counts as one user for Payables and one for Purchasing, totaling two licenses. Application users are the most common metric for many EBS modules, especially financials, manufacturing, and CRM modules.
- Employee – This metric licenses a module based on the number of employees in the organization or a specific subset. It’s typically used for HR and self-service modules that involve the entire workforce. Oracle’s definition of “employee” for licensing includes full-time, part-time, and temporary workers, as well as contractors or agents who are tracked in the system. If a module is licensed per Employee, you count everyone that module touches, not just who logs in. For instance, Oracle HR or Self-Service HR is often Employee-based. Suppose you have 1,000 employees in your company, and you license Oracle Human Resources. In that case, you need 1,000 Employee licenses, even if only HR staff directly use the system, because all employees’ data is managed.
- Concurrent User – An older metric (largely legacy) where licenses are based on the maximum number of simultaneous users logged in. Oracle used this in the past, referring to it as the “Professional User” or “Concurrent User” metric. It’s less common in modern EBS pricing, but some customers are grandfathered on this metric. In a concurrent model, 100 concurrent user licenses might cover, say, 200 named individuals if only up to 100 are ever on at once. However, Oracle nowadays prefers Named User (Application User) or Employee metrics.
- Records/Transactions Metrics – Some modules use a business volume metric. For example, Oracle Internet Expenses can be licensed for several expense reports per year. Oracle Order Management may be licensed based on the number of order lines processed annually. Oracle Procurement could have a metric, such as the total procurement spend or the number of contracts. These metrics tie cost to actual transaction volume. For instance, “10,000 Expense Reports per year” could be a licensing band you purchase for Expenses. If you exceed that, you’d need to move up to a higher band.
- Custom Suite or Enterprise Metrics – Oracle can license EBS in aggregate for very large customers, such as an Enterprise Site License based on a metric like revenue or total employees for the entire suite. This is less a standard offering and more a result of negotiations (or ULAs). However, as a baseline, most will license modules one by one.
Example metric distinctions:
- Application Users often use Oracle Financials modules, such as GL, AP, and AR. You count each finance user per module.
- Oracle Self-Service HR is often an Employee metric (covering the entire org) because potentially every employee might use self-service (or at least their data is stored).
- Oracle Payroll may be licensed based on the number of employees paid (another form of employee metric).
- Oracle Order Management might allow licensing by Application User or by Order Lines annually – the customer chooses the more suitable model.
- Some CRM modules might have user metrics for internal users and “Employee” or “Partner” metrics for external usage.
The key is that Oracle’s price list defines a metric for each module. You choose how many units of that metric to buy (and sometimes there’s a minimum).
Counting Users and Minimums
Under the Application User metric, it’s important to count “authorized users,” not concurrent usage. Anyone with an active account on the module counts as one license. Shared accounts are not allowed to reduce license counts; Oracle expects each person to have their login. So, if 10 people share one generic login, Oracle would still require 10 licenses.
Oracle often imposes minimum license quantities for certain modules. For example, Oracle Financials might require a minimum of 10 Application User licenses even if a small company has fewer users. These minimums ensure a baseline revenue for Oracle.
Also, if modules are integrated, Oracle had a concept that a user of one module might need to be licensed for related modules they indirectly use. But nowadays, it’s mostly modular – you license what you use.
Restricted-Use Database and Middleware included
When you purchase E-Business Suite application modules, Oracle includes the underlying technology licenses needed to run EBS itself. Specifically:
- Oracle Database: EBS comes with a restricted-use Oracle Database Enterprise Edition license. This allows you to run the Oracle Database only to host the EBS schemas. You do not have to separately purchase database licenses for your EBS instance. However, the restriction is that you cannot use that database for anything other than EBS. For example, you can’t create non-EBS schemas or use that database as a general data store for other applications. If you do, you’d need a full DB license. In essence, Oracle provides the DB license for free, but it is tied to EBS usage only.
- Oracle Application Server/WebLogic: Similarly, EBS includes the necessary Oracle Fusion Middleware components, which are used under restricted conditions. Oracle EBS 12 uses Oracle WebLogic Server for its middle tier (in earlier versions, it was Oracle Containers for J2EE). Oracle grants a restricted WebLogic (or whatever app server) license to run the EBS application tier. Again, you can’t use WebLogic to deploy custom unrelated apps. It’s solely for EBS.
- Other Tech Components: EBS might include Oracle Reports and Oracle Discoverer (older versions), if these are part of EBS functionality. These would also be restricted to use with EBS.
This bundling is hugely important: it means if EBS is the only Oracle product you use, you don’t need to buy separate DB or middleware licenses for it – your EBS licenses cover the full stack.
Many organizations run EBS’s database on a server without any Database license in their LMS audit report, and that’s correct if only EBS data is there.
Implications of restricted use: If your DBAs or developers create another schema or use the EBS database to store data for a custom application (such as a reporting database or an interface with additional tables), this could violate the license. It’s a gray area – generally, small extensions within the EBS schema (such as custom tables that integrate with EBS) are allowed as part of EBS usage, but a completely separate application’s schema would not be.
A rule of thumb: if it’s data and functionality that extend EBS (using EBS APIs, part of EBS workflows), it’s under EBS usage. If you plop an unrelated app’s data schema there, that’s not covered. In such a case, you’d be expected to purchase a full Oracle DB license for that server or segregate that usage to another database.
Always segregate your EBS database for EBS use only. If you want to build custom non-EBS applications, use a different database instance (with proper licensing).
Examples of Module Licensing
Let’s illustrate licensing with a hypothetical company:
- They want to use Oracle Financials (General Ledger, AP, AR), Oracle Purchasing, and Oracle HR (Core HR and Self-Service HR). They have 50 finance users, 10 procurement users, 5 HR staff members, and a total of 500 employees.
- Financials (GL/AP/AR): Suppose these are Application User metrics. They would need to license 50 users for GL, 50 for AP, and 50 for AR (assuming the same 50 people use all three – that’s 150 licenses, but practically, Oracle might allow a “Financials suite” bundle, or they might count distinct users per module). If each module is separate, indeed, the same person counts in each license. Historically, Oracle had a “bundled financials user” metric, but it is likely separate now.
- Purchasing: 10 users (procurement department). License 10 Application Users for Purchasing.
- HR: Core HR might be a key employee metric. They have 500 employees, so they need 500 Employee licenses for Oracle HR. Self-Service HR might also be licensed per Employee (covering all 500). If they have a Payroll module, that might also be $500 per employee.
- So, the total licenses might be: 50 GL users, 50 AP users, 50 AR users, 10 Purchasing users, 500 HR employees, and 500 self-service employees.
- Note: Oracle often sells as bundles. For example, Oracle “E-Business Suite Limited Use” or “Professional User” licenses that cover a bundle of core modules for a percentage of employees. But that gets into custom deals.
- Minimums: If Oracle requires a minimum of 20 users for a module and we only have 10, we still have to buy 10. Always check the price list for footnotes on minimums.
License Management Best Practices in EBS
- User Management: Because the Application User metric counts every named user, it’s crucial to manage the user accounts in EBS. Remove or end-date accounts of people who leave or no longer need access. In audits, Oracle may request a list of active users for each module. Inactive accounts count if they are not disabled. So a periodic cleanup is necessary.
- No Sharing of Logins: As mentioned, ensure each user has a unique login. If any generic accounts exist, try to eliminate them or at least determine how many people use them. Oracle will likely count each person using a generic login as a separate license if discovered.
- Module Usage Tracking: Know which users have access to which modules. Often, EBS responsibilities can be mapped to modules. You should be able to report, for example, how many distinct users entered AP transactions (that’s your AP user count). Align that to the licenses purchased. Oracle’s audit scripts for EBS can pull user lists by module responsibility.
- Consider Enterprise Metrics for Broad Usage: If you find that many modules will be used by almost everyone (for example, if you plan to roll out Self-Service to all employees and they will all use iProcurement to make requests), it might make more sense to negotiate an enterprise metric. Oracle sometimes offers an “EBS Enterprise License,” where you pay based on a metric, such as employee count or revenue, for broad use. That can simplify licensing when user counting is too cumbersome. This is typically through an Unlimited License Agreement (ULA) or a license for a legacy application suite.
- Be Aware of Customization Impact: If you heavily customize EBS, it doesn’t change licensing directly (users are still users). However, if you integrate EBS with other systems, ensure that those other systems’ users aren’t indirectly using EBS without licenses. For example, suppose you create a custom web portal that enables employees to query EBS data using an API. In that case, those employees might need to be licensed EBS users (if they aren’t already, based on the employee metric).
- Understand Legacy Metrics: Some older EBS contracts might have metrics like “Bundle XYZ – Professional User,” which allowed one user to access a suite of modules. Oracle moved away from that, but if you have it, cherish it (it could be cost-effective). During upgrades or expansions, Oracle may try to migrate you to the new metrics. Do the math to ensure you don’t lose a good deal.
Recommendations
- Align Licenses with Actual Usage: Review which EBS modules you have deployed and who uses them. Ensure you have purchased sufficient licenses for each module’s metric. If you’ve turned on a module only for a subset of employees, consider using an Application User metric instead of Employee, if available – it could save costs if not everyone needs it. Conversely, if a module potentially touches everyone (like self-service or basic HR), an Employee metric provides complete coverage and simpler management.
- Maintain an Accurate User Count by Module: Use EBS’s user management reports to keep track of how many users are set up for each licensed module. If someone moves to a different department and no longer needs a certain module, revoke their responsibility. This is not only good security practice but also keeps your licensable user count in check. During an Oracle audit, you can then provide lists of users per module that cleanly match your entitlements.
- Plan for Growth or Contraction: Licensing is often tied to the number of employees or users. If your company’s size changes (due to growth, layoffs, or M&A), reassess your EBS licenses. Oracle typically doesn’t automatically adjust for you; you must negotiate adjustments. It’s better to proactively address it (especially growth, to procure additional licenses to stay compliant). Some contracts have a “growth clause” where, if employees increase by X%, you need to true up. Know if yours does.
- Leverage Oracle’s Module Minimums: When budgeting, be aware of Oracle’s minimum purchase requirements. If a module has a minimum of 100 users, but you have only 60 users, you’ll still pay for 100. In that case, see if those extra 40 can be utilized – maybe by giving access to more users who could benefit, since you’re paying for them. Or negotiate if Oracle will accept the lower count; sometimes, if you have multiple modules, they might waive some minimums.
- Consider Suite Licensing if You Use Many Modules: Oracle offers options like “E-Business Suite Module Suite” or “Custom Applications Suite (CAS)” licensing. For example, CAS allows you to bundle multiple modules under a single, custom-named user metric if you plan to deploy a broad swath of EBS.
- Consider Suite or Enterprise Licensing: If you plan to deploy a broad set of EBS modules to a large user base, talk to Oracle about Custom Application Suite (CAS) or enterprise metrics licensing. CAS allows bundling multiple modules under a single user-based metric. For example, rather than licensing Financials, Procurement, and Projects separately by module, Oracle could offer a combined “EBS Suite” user license covering all. This can simplify compliance, as one license covers multiple modules for a user, and sometimes reduces costs if users overlap across modules. Similarly, an enterprise metric, such as licensing EBS based on total employee count or revenue, might be negotiated for organization-wide use. These options typically arise in larger deals, but it’s worth evaluating if module-by-module licensing gets too complex.
- Document Your License Entitlements: Keep copies of Oracle’s price list and your ordering documents that show the metrics and quantities you’ve licensed. Also, maintain documentation of the restricted-use license provisions for the database and middleware. In an audit, if an Oracle auditor unfamiliar with EBS questions your lack of a DB license, you can point to the contract clause or Oracle’s documentation that EBS includes the DB for that use. Having these details readily available will help resolve misunderstandings quickly.
- Avoid License Creeping with Customizations: Use the EBS tech stack only for EBS. If you need to build custom applications or add-ons, consider licensing additional technology or using non-EBS environments for that purpose. Don’t piggyback a custom app’s schema on the EBS database or use the EBS WebLogic server for a non-EBS application. Not only can that violate licenses, but it can also complicate future upgrades and audits. Keep EBS environments dedicated to EBS.
- Audit Internally: Regularly perform internal license audits for EBS. For each module in use, cross-check active users against purchased licenses. Also, verify your employee counts if you have employee-based licenses. If your company has grown, you may need to true up your licenses to remain compliant. Oracle audits often find issues like too many users on a module or an extra module enabled without a license; catching those internally allows you to address them (by reducing access or buying additional licenses) before Oracle’s official audit.
By understanding EBS’s licensing metrics and diligently managing user access and entitlements, you can ensure your organization remains compliant and optimize what you pay for. E-Business Suite’s licensing may seem complex, but with good governance, you can align licenses to actual usage and avoid common pitfalls.
