Oracle E-Business Suite Licensing FAQ
General Licensing Questions
Q1: What does “Oracle E-Business Suite perpetual licensing” mean?
A: Perpetual licensing for Oracle E-Business Suite (EBS) means you purchase a one-time, permanent license to use the software indefinitely (on-premises), rather than a subscription. You pay an upfront fee for each module or user license and can use the EBS software version you purchased forever. Companies typically pay an annual support fee (about 22% of the license price) for ongoing updates and support. In short, a perpetual license does not expire, though support and updates require continuous maintenance payments.
Q2: How does Oracle EBS perpetual licensing differ from Oracle Cloud (Fusion) SaaS?
A: Oracle EBS licensing is for on-premises deployment: you buy licenses and install the software on your servers. In contrast, Oracle Fusion Cloud Applications (SaaS) are subscription-based services hosted by Oracle. With EBS perpetual licenses, you have a capital expense (one-time license purchase + optional support), full control of the environment, and responsibility for maintenance. With SaaS, you have operational expenses (recurring fees), and Oracle manages the infrastructure. Also, EBS perpetual licenses are tied to specific modules and user counts, whereas SaaS generally allows using a cloud service for as long as you pay. In summary, EBS perpetual = buy and own the software, Cloud SaaS = rent the software as a service.
Q3: What are the main product families in Oracle E-Business Suite?
A: Oracle EBS is a comprehensive suite of enterprise applications. Its key product families include:
- Financials: e.g., General Ledger, Accounts Payable, Accounts Receivable, Fixed Assets, Cash Management, Internet Expenses, etc.
- Supply Chain Management (SCM): e.g., Inventory, Order Management, Warehouse Management, Advanced Supply Chain Planning, Logistics.
- Manufacturing: e.g., Bill of Materials, Work in Process, Discrete Manufacturing, Process Manufacturing, Quality, Cost Management.
- Human Capital Management (HCM): e.g., Core HR, Payroll, Self-Service HR, Time and Labor, iRecruitment, Learning Management.
- Customer Relationship Management (CRM): e.g. Oracle Sales, Marketing, Telesales, iStore (Internet Store), iSupport, Field Service.
- Procurement: e.g., Purchasing, iProcurement (self-service requisitioning), iSupplier Portal, Sourcing, Procurement Contracts.
Each family contains multiple modules, and organizations can implement only the modules they need.
Q4: Do we have to license the entire EBS suite, or can we license specific modules?
A: You can license Oracle EBS a la carte by module. There is no requirement to purchase the whole suite – you simply license the specific modules your business will use. For example, a company might license only financial modules (like general ledger and payables) without licensing manufacturing or CRM. Oracle sells each module separately (with its licensing metric and fee), allowing granular, module-by-module licensing. However, remember that you must license each if you use multiple modules. Oracle also offers custom bundles or suite licenses for broader use, but starting with individual modules and adding others over time is entirely acceptable.
Q5: If a user needs access to multiple EBS modules, do they need multiple licenses?
A: Yes. Under Oracle’s current model, licenses are typically per module per user. This means if one person uses three different modules, you need to own a license for that person for each module. For example, if an employee uses Oracle Financials, Purchasing, and Project Costing, that one individual would count as one licensed user for Financials, one for Purchasing, and one for Project Costing. In other words, the same user is counted separately against each module’s license entitlement. (Historically, Oracle had a “primary usage” licensing that counted a user only once across certain core modules, but today, each module is licensed independently per user.) It’s important to plan licenses for each module to which a person will have access.
Q6: Does an EBS perpetual license allow indefinite use, and does it include support?
A: A perpetual license grants indefinite usage rights – you can use the software version you licensed perpetually (forever). However, technical support and updates are not automatically included. Oracle charges a yearly support fee (typically ~22% of the license price) for access to patches, upgrades, and support services. If you maintain an active support contract, you can upgrade to newer releases of EBS at no additional license cost. If you choose not to pay support, you can still use your licensed software perpetually, but you won’t receive updates or fixes and may lose the right to upgrade to newer versions. The license never expires, but support (for upgrades and assistance) is a renewable annual cost.
EBS Licensing Metrics Explained
Q7: What licensing metrics are used for Oracle EBS (e.g., Application User, Employee)?
A: Oracle E-Business Suite uses several licensing metrics to measure pricing usage. The most common metrics for EBS are: Application User and Employee. An Application User license means each user authorized to use a module counts toward the license total. An Employee metric means your license is based on the number of employees in your organization (or in scope) rather than discrete users.
In addition, some modules use usage-based metrics (like number of transactions) instead of users. For example, Oracle Internet Expenses can be licensed by several expense reports per year, and Order Lines can license some Order Management functions.
Oracle historically also had metrics like Concurrent User (peak simultaneous users) and Professional User (a type of named user) in older contracts. Today’s perpetual EBS licenses will generally be based on either per-user (Application User) or an enterprise metric (Employee or similar), with a few modules offering alternative metrics for flexibility.
Q8: What is an Application User license in Oracle EBS?
A: Application User is the most common licensing metric for EBS. It is defined as an individual authorized by your company to use the specific Oracle EBS application module, regardless of whether they are actively using it at any given moment. In practice, this works like a named-user license: you must obtain a license for every person with login access to that EBS module.
Even if a user only uses the system occasionally, they count as an Application User if they have credentials/authorization. For example, 50 finance staff using Oracle Payables would require 50 Application User licenses for Payables.
If additional managers log in to approve invoices, they need to be licensed, too. Under this metric, every human user of a module needs a license—it’s tied to unique user identities, not concurrent usage.
Q9: What is the Employee licensing metric in Oracle EBS?
A: The Employee metric is an enterprise-based license metric that counts the total number of employees (and similar personnel) in your organization rather than individual named users. Oracle defines Employee for licensing purposes as “all of your full-time, part-time, temporary employees, plus all of your agents, contractors, and consultants who have access to, use, or are tracked by the program”. In other words, it covers the total population that the application might use or manage.
The number of licenses required is determined by the number of employees in scope, not how many log in. This metric is often used for HR/HCM modules – for example, if you license Oracle Human Resources on an Employee metric and have 1,000 employees, you pay for 1,000 Employee licenses, covering all those individuals.
Even if not everyone logs in, Oracle charges based on the total employee count. The Employee metric is useful for modules that inherently involve the whole workforce (like HR or Self-Service), providing a blanket licensing approach.
Q10: How do Application User and Employee licensing differ in practice?
A: Application User vs. Employee licensing differ in what you count: Application User counts actual users with access, whereas Employee counts all personnel in scope whether or not they all actively use the software. For example, an HR self-service module might be offered on an Employee metric – you count total employees (because potentially everyone will use or be tracked in HR).
In contrast, a financial module used only by accountants would be on Application User – you count just those specific users. Another key difference is that Employee metric licenses cover a broad base (often used when virtually everyone benefits from the system).
In contrast, Application User licenses are more granular (for defined user roles). The Employee metric doesn’t require tracking individual usage – you simply license a number equal to your employee headcount.
The Application User metric requires managing named user accounts to ensure each person is licensed. In summary, Application User licensing is best when you have a limited user group, whereas Employee-based licensing is suited for enterprise-wide deployments like core HR. (Note: Oracle may restrict which modules can use employee metrics commonly used for HCM and self-service applications.)
Q11: Does Oracle offer Concurrent User licenses for EBS?
A: Not anymore. Oracle used to offer “Concurrent User” or “Concurrent Device” licenses for E-Business Suite in the 1990s, but this model is no longer sold for E-Business Suite. Under concurrent licensing (legacy), you would license the peak number of users simultaneously accessing the system rather than every named user.
While some long-time Oracle customers still grandfather old concurrent user licenses (allowed under their original terms), new EBS licenses are based on named counts (Application User) or enterprise metrics. In other words, you cannot purchase new EBS licenses as concurrent users from Oracle today. All users must be counted individually as authorized users under modern agreements.
If you have legacy concurrent licenses, you must manage usage to ensure concurrent limits aren’t exceeded or consider migrating to the current model. But for new implementations, plan on per-user licensing (not concurrent).
Q12: Are any Oracle EBS modules licensed by transaction volume instead of by user?
A: Yes. Some EBS modules offer usage-based metrics as an alternative to user or employee licensing. For example, Oracle Internet Expenses (for employee expense reports) can be licensed by the number of Expense Reports processed per year. Instead of licensing every employee in the system, you might license a certain number of expense report transactions (e.g., X Expense Reports/year) to cover your usage, which can be cost-effective if not all employees file expenses. Another example: Oracle Order Management modules allow licensing of Electronic Order Lines – if orders are entered electronically (via EDI/XML or external sources), you must license those order lines in volume.
There are also metrics like $M Cost of Goods Sold for some manufacturing modules (e.g., Oracle Shop Floor Management can be licensed per million dollars of cost of goods sold). These transaction $$-or dollar-based metrics align licensing costs with business activity instead of user count.
They are typically used in specific scenarios to provide flexibility. In summary, while most core modules use user-based licensing, a handful (especially in Financials and SCM) can be licensed by transaction counts, dollar volume, or other usage metrics – you would choose whichever metric Oracle offers that best fits your usage pattern.
Q13: Do external users like suppliers or customers need Oracle EBS licenses?
A: Typically, external users (third parties like your suppliers, customers, or partners) do not require separate EBS user licenses if they are accessing the system through specific self-service modules designed for external parties. Oracle’s licensing rules generally distinguish internal versus external users.
For modules such as Oracle iSupplier Portal and Oracle Sourcing (used by suppliers to interact with your procurement system), the usage by external supplier users is included under your licensed internal users. You only need to license your internal employees who administer or use those modules; your suppliers can log in to submit bids or view POs without licensing each contact.
Similarly, customer-facing modules like Oracle iStore (an e-commerce web store) or Oracle iSupport (a customer support portal) are often licensed by a technical metric (like server processors or concurrent sessions) rather than by named users. This allows unlimited external customer access once you’ve licensed the module appropriately. In short, you do not pay per supplier or customer.
You license the module (usually counting internal users or using a processor metric), and Oracle permits unlimited external users to access the self-service interfaces. (Always check specific module terms, but Oracle’s standard policy is that external read/write access via things like iSupplier, iStore, etc., is covered by the internal licenses.)
EBS Module-Specific Licensing
Q14: How are Oracle EBS Financials modules licensed?
A: Oracle Financials modules (such as General Ledger, Accounts Payable, Accounts Receivable, Fixed Assets, Cash Management, etc.) are generally licensed using the Application User metric. You need one license for each person who will use each Financials module.
Typically, finance and accounting staff who transact in these modules are counted as Application Users. For instance, if 20 accountants use General Ledger, you’d need 20 user licenses for General Ledger. If those same 20 also use Accounts Payable, you’d need 20 licenses for Accounts Payable. Financial modules are usually purchased individually (you can license just the ones you need).
In some cases, Oracle may bundle core Financials modules, but each module is considered separately in modern licensing. An illustrative example from Oracle is a company that had to license all users who enter or approve invoices in the EBS Financials system as Application Users.
This confirms that even managers who only approve financial transactions must be licensed as users of the relevant Financials module. In summary, Financials = license per named user of each module. (There are a couple of exceptions: Oracle Internet Expenses is considered part of financials but is often licensed by expense reports. See the next Q&A.)
Q15: Can several expense reports instead of users license Oracle Internet Expenses?
A: Yes. Oracle Internet Expenses (iExpenses), a module in EBS Financials for employee expense management, can be licensed by standard user metrics or transaction volume metrics. Oracle provides an option to license iExpenses based on the number of Expense Reports processed annually. For example, instead of licensing every employee (or user) for expense entry, a company could license 10,000 expense reports/year.
This approach is useful if not all employees submit expenses or if you prefer to tie cost to actual usage. Oracle even allows customers to migrate from an Employee metric to an Expense Reports metric for iExpenses if that better fits their usage.
The advantage is that you don’t pay for users who never file an expense. If you choose this metric, you must ensure you do not exceed the purchase number of expense reports in 12 months. In summary, Oracle Internet Expenses is one module where you don’t have to license every potential user – you can license the volume of expense transactions, providing flexibility for enterprise-wide self-service deployment.
Q16: How are Oracle EBS Supply Chain Management (SCM) modules licensed?
A: SCM modules in EBS (like Inventory, Order Management, Warehouse Management, etc.) are predominantly licensed by the Application User metric. You count the users in roles such as supply chain planners, inventory controllers, order entry clerks, warehouse managers – anyone who logs into those modules. Each module (Inventory, Order Management, etc.) would require licenses for its respective users.
One nuance in Order Management: if orders come from external systems (like via EDI, XML, or a website) rather than being manually entered by a user, Oracle uses the Electronic Order Line metric to license those transactions. You’d buy a block of order lines to cover automated order input. But for regular internal use, e.g., staff manually entering or processing orders, those staff need Application User licenses for Order Management.
Other SCM-related products (like Advanced Supply Chain Planning, Procurement Contracts, etc.) are also usually user-based. In essence, license your core SCM users per module. If your implementation integrates with external sources (like a B2C website feeding orders), be aware of transaction metrics like Order Lines that need to be licensed in addition to user licenses.
Most standard Inventory and Fulfillment operations stick to user licensing, while high-volume automated processes may invoke volume-based licensing.
Q17: How are Oracle EBS Manufacturing modules licensed?
A: Oracle’s Manufacturing suite (which overlaps with SCM but focuses on production) is also typically licensed by Application User. Modules such as Discrete Manufacturing, Process Manufacturing, Bill of Materials (BOM), Work in Process (WIP), Cost Management, and so on, require a user license for each person (planner, engineer, production supervisor, etc.) who uses that module.
If one person uses multiple manufacturing modules, they need a license for each (unless you negotiated some kind of bundle).
In general, manufacturing plants have a defined number of users interacting with EBS (creating work orders and managing production schedules), and those would be the application users to count.
Oracle sometimes offers alternative metrics for manufacturing in large enterprises. For example, Oracle Shop Floor Management could be licensed by $ Millions of dollars in Cost of Goods Sold (COGS), which ties license cost to the scale of production rather than user count.
That metric might make sense if the user count is high or fluid, but the company can be measured by output value. However, such cases are special; the most common approach is still per-user licensing for manufacturing modules. So, license each manufacturing user per module.
Certain manufacturing modules may also require minimum user licenses (Oracle often has a minimum license purchase, e.g., 10 users for a module). Always check the price list or consult Oracle to see if an alternative enterprise metric or minimum applies in your manufacturing scenario.
Q18: How are Oracle EBS Human Capital Management (HCM) modules licensed?
A: Oracle HCM (HRMS) modules often use the Employee metric because these systems usually cover the entire workforce. For core HR modules like Oracle Human Resources and Self-Service HR, Oracle licenses are based on the total number of people (employees/contingent workers) managed in the system.
If you have 5,000 employees whose data is stored in Oracle HR, you would purchase 5,000 Employee licenses for that module. The Employee metric includes all workers (full-time, part-time, contractors) who are tracked. Some HCM modules, especially those used by HR staff only, might be licensed by the Application User.
For example, Oracle HR Professional (for HR specialists) or Oracle Payroll might count the HR and payroll users rather than every employee. But generally, Self-service functionalities (where every employee can, say, update their information or view paystubs) are licensed by the Employee. Oracle Advanced Benefits is another module typically licensed per covered person.
One important note: Oracle’s terms might require that if you use an Employee metric for HCM, you count all employees across the enterprise (you can’t exclude some using a different HR system)—the definition is comprehensive. In summary, expect to license core HCM by employee headcount.
If an HCM module is only used internally by HR staff (like Oracle Learning Management for admins or Oracle HR if used in a limited way), it could be Application User – but most HCM deployments license a broad base. Always confirm the metric with Oracle’s price list; the metric is usually indicated (e.g., “Person” or “Employee” metric for HR modules).
Q19: How are Oracle EBS Customer Relationship Management (CRM) modules licensed?
A: EBS includes some CRM modules (though Oracle’s primary CRM is Siebel or Fusion CRM, and EBS had modules for sales, service, and marketing). These EBS CRM modules are typically licensed by user for internal users and by other metrics for external-facing components.
For example, Oracle Sales (sales force automation) or Oracle Telesales would be licensed by Application User – each sales rep or telesales agent needs a user license. Oracle Marketing (if part of EBS) might also be by user or several marketing contacts, depending on the component. For customer self-service parts, Oracle iStore (online product catalog and shopping cart) is often licensed by Processor because it serves external customers on a web store.
That means you license the server capacity (e.g., processors running iStore) to allow unlimited customer shoppers. Similarly, Oracle iSupport (customer support portal) could be licensed by Processor or a special external user metric, allowing unlimited customer logins. Internal agents using iSupport (to manage service requests) would need Application User licenses for the Oracle Service module. Internal CRM users (salespeople, support agents, marketing staff) are usually counted as Application Users for modules like Sales, Service, and Marketing.
External users (customers and partners accessing your system) are covered via technical metrics (like processor or concurrent sessions), so you don’t license each. This dual approach ensures you only count your employees, not every end customer. Refer to Oracle’s module documentation to see the metric: e.g., Oracle iStore and iSupport are explicitly priced per Processor in the price list.
Q20: How are Oracle EBS Procurement modules (Purchasing, iProcurement, Sourcing) licensed?
A: Procurement modules span both internal procurement operations and external supplier collaboration.
Here’s a breakdown:
- Oracle Purchasing: Licensed by Application User. You count the buyers and procurement staff who use the Purchasing module. Each person creating purchase orders, approvals, etc., needs a license. Purchasing is a foundational module and often a prerequisite for others.
- Oracle iProcurement is the self-service requisition module for employees to request goods/services. If only a limited group uses it (e.g., just a department), you could license by Application User (count those requisitioners). If the intent is to deploy iProcurement to all employees for self-service, Oracle might offer an Employee metric or simply require you to license all those users. In practice, many organizations license iProcurement for all employees who might create requisitions (which could be company-wide, so sometimes an enterprise metric or high user count is involved). There isn’t a special “per requisition” metric, usually per user or employee.
- Oracle iSupplier Portal: Licensed for internal users by Application User, but external supplier users are included (no extra charge per supplier). You must license the internal folks managing supplier relationships or administering the portal. For example, if 5 procurement and 5 AP staff use iSupplier Portal to communicate with vendors, those 10 need licenses. All your suppliers logging in via iSupplier Portal do not need individual licenses – your licenses cover them.
- Oracle Sourcing: Licensed by Application User for the sourcing team (the people who create RFQs, auctions, etc.). Like iSupplier, the suppliers or bidders who respond in Sourcing are external and don’t require licenses. Note that Oracle Sourcing also requires Oracle Purchasing to be licensed (Purchasing is a prerequisite module). So you cannot just license sourcing alone; you must have purchasing in your portfolio.
- Procurement Contracts: Usually licensed by user (for those who author or manage contracts). Possibly an add-on module where the metric is Application User or could be included with Purchasing user licenses depending on Oracle’s packaging.
In summary, Procurement modules are mostly user-based for your internal procurement and supply chain users. Once you have the module, it allows unlimited external participation from suppliers. Ensure you license core purchasing first if you use related modules like Sourcing.
If employee-facing procurement (iProcurement) is deployed widely, budget for many user licenses or an enterprise metric to cover all requisitioners.
Q21: Do some Oracle EBS modules require other modules as prerequisites?
A: Yes. Oracle EBS modules often have functional dependencies that translate into licensing prerequisites. The rule is that if Module B relies on data/functions of Module A, Oracle expects you to license Module A as well.
A common example: Oracle Sourcing requires you to license Oracle Purchasing since Purchasing provides the foundational purchasing data and suppliers. Similarly, Oracle Services Procurement (a module for procuring contingent labor) requires purchasing.
Another example: iProcurement is essentially an extension of Purchasing (for self-service requisitions), so you wouldn’t use iProcurement without Purchasing. In Oracle’s price list footnotes, these prerequisites are often noted. Also, some advanced modules are technically “options” of base modules – e.g., Advanced Supply Chain Planning might require Oracle Inventory and Order Management to be licensed.
The rationale is that you can’t properly use an add-on without the base. From a licensing standpoint, failing to license the prerequisite is considered non-compliant usage. So, always verify the Oracle licensing guides or notes: if you plan to license a certain module, check if Oracle lists any prerequisite modules.
In summary, prerequisites exist (especially in Procurement and some Financials/Projects areas), and you must license the complete chain of required modules to stay within the terms.
EBS Licensing Best Practices and Other Tips
Q22: Does Oracle EBS licensing include the Oracle Database and other technology components?
A: Not fully – it’s important to understand the distinction. When you purchase E-Business Suite applications, you license the application modules themselves. Oracle does include a restricted-use license for the Oracle Database, Oracle Fusion Middleware (WebLogic), and other required tech stack components only to be used with EBS.
This means you can run the EBS database and application server without a separate purchase, but only to support EBS. If you use those same instances for custom applications or additional data, you might violate the restrictions.
For example, you can use the Oracle Database with EBS for EBS data, but you cannot build a custom non-EBS database schema for separate applications unless you have a full DB license. Oracle states that extending or customizing beyond the standard may require full-use licenses for the underlying technology. As a best practice, use the included DB and middleware only for the functionality of EBS modules.
If your team builds significant custom extensions (especially separate applications accessing the EBS database), consult your Oracle agreement. In such cases, you might be required to procure full-use licenses for the database or middleware.
In summary, EBS app licenses let you run the suite and its tech platform self-contained, but they are not a blanket license for all Oracle technology usage. Always adhere to the “restricted use” clauses to avoid compliance issues.
Q23: What are some best practices for managing Oracle EBS licenses in an on-premises deployment?
A: Managing EBS licenses can be complex, but a few best practices can help ensure you remain correctly licensed and cost-efficient:
- Maintain an Accurate User List: Track all individuals who have access to each module. When someone leaves or changes roles, promptly end-date or remove their EBS user account. This prevents “license creep” from inactive accounts that still count as authorized users.
- No Shared Accounts: Do not allow multiple people to share one login to save licenses. Oracle requires every user to be licensed, even if they log in with a generic account. For example, 10 people using one generic EBS login would still require 10 user licenses, not one. Shared accounts not only pose security risks but also violate licensing rules.
- Map Roles to Modules: Understand which modules each user is accessing. Ensure that you have sufficient licenses for every module a user touches. Use EBS’s user management and responsibility assignment to audit who has access to what and align that with your purchased licenses.
- Leverage Appropriate Metrics: Choose the licensing metric that fits your usage. The application user is fine if only a small team uses a module. An employee metric or unlimited license might be more practical if an application will be used enterprise-wide (e.g., self-service HR). For certain modules, consider whether a transaction metric (order lines, expense reports) could reduce costs based on your usage patterns.
- Be Aware of License Minimums: Oracle often imposes a minimum number of user licenses for a given module (e.g., you might have to buy at least 10 or 100 licenses even if you have fewer users). Plan for these minimums in your license count to avoid shortfalls.
- Monitor Usage vs Entitlements: Review how many users use each module and compare it to what you’ve licensed. This can help identify if you are over-licensed (unused licenses) or nearing your limits. Oracle doesn’t require formal usage reporting for perpetual licenses except in specific metrics, but internal monitoring helps optimize your spend.
- Stay Informed on Policies: Keep Oracle’s licensing documentation (price lists, metric definitions) handy. Oracle occasionally updates metrics or offers new licensing models. Understanding the official definitions (like what counts as an “Employee” or “Application User”) will help you manage licenses correctly.
- Training and Governance: Ensure your IT, procurement, and SAM (Software Asset Management) teams are educated on Oracle licensing. Have processes in place for when new modules are enabled or new users are onboarded to EBS so licensing is accounted for proactively.
By following these practices, enterprises can avoid common licensing pitfalls (like unnoticed excess users or mislicensed modules) and be prepared if Oracle ever reviews usage. Good governance of EBS licenses will maximize your ROI and minimize compliance risk.
Q24: If an employee leaves the company, can we reassign their EBS license to a new user?
A: Yes. Oracle EBS licenses are generally tied to the number of users, not specific named individuals, eternally. If one person leaves or no longer needs access, you can allocate that “spot” to another user, as long as you update the system. The practical step is to end-date or delete the former employee’s EBS user account (so they’re no longer counted), and then you can create a new account for the replacement employee under the same license count.
There’s no need to purchase an additional license for the new person if you stay within the originally licensed quantity. For example, if you have 50 financial user licenses and one user departs, you still have 50 entitlements – you can add a new user and remain at 50. The key is controlling the active authorized user list. Oracle’s policies allow reassignment in this manner because the license is for a maximum number of users at a time, not a named person’s identity.
Just ensure the former user can’t access the system anymore (remove their login) so you’re not accidentally over the count. In summary, licenses can be reallocated to new users internally; they are not one-time-use per named individual. (Do note, however, that you cannot “share” one license simultaneously between two people – see best practices above – but sequential reuse is fine.)
Q25: Is there a minimum number of licenses required to purchase for each EBS module?
A: Often, yes. Oracle’s price lists usually specify a minimum license quantity for each module, especially with user-based metrics. This means that even if you have only two people using a module, Oracle might require you to buy at least 10 licenses.
The minimum varies by module and metric. For example, historically, Oracle Human Resources required a minimum of 100 Person (Employee) licenses, and Self-Service HR also required a minimum of 100 people. Many smaller modules require a minimum of 5 or 10 Application Users. These minimums are in place presumably to cover Oracle’s cost structure and set a baseline value.
When planning your licensing, always check Oracle’s Global Price List or ask Oracle what the minimum price for that product is. You must purchase the minimum if your user count is below the stated minimum. (Of course, you can license more than the minimum if you need to.) Also note that if you use an enterprise metric like Employee, sometimes the contract might mandate a minimum percentage of your employees.
However, the price list generally explicitly lists a numeric minimum per module. Adhering to these minimums is important—if you only bought one license for something with a 10-user minimum, you would be under-licensed. So, budget for the minimum even if your actual usage is small.
Q26: Can we license Oracle EBS for only a subset of users or departments (not the whole company)?
A: Yes, you can license EBS modules for the users or departments needing them. Oracle does not force you to license all employees or an entire enterprise unless you choose an enterprise metric. For example, if only the finance department will use EBS Financials, you can license just those finance users as Application Users, and there’s no requirement to include other departments. Likewise, if you have a division that will use EBS and another division that will not, you only license the division using it.
The important caveat is to ensure that only the licensed subset has access. In an HR module licensed by Employee metric, typically all employees managed in that system are counted – but if, say, you were only using Oracle HR for a particular country’s employees, you might contractually limit the scope (though Oracle usually expects all employees if it’s core HR). Generally, you can start with a subset of users with Application User licensing. Just maintain proper access controls so that unlicensed users (outside the subset) aren’t given access inadvertently.
Many organizations phase their EBS rollout – e.g., implement for one business unit first – and license accordingly. You can always extend licenses to more users or departments later as needed. So yes, licensing can be scoped to the actual users of the system, not necessarily everyone in the company (unless you signed an enterprise-wide agreement deliberately).
Q27: Can Oracle EBS licenses be mixed and matched (some modules user-based, others employee-based)?
A: Absolutely. You can use different metrics for different modules based on what makes sense and what Oracle offers for those products. Sticking to a single metric across all your EBS licenses is not required. For instance, you might license your HR module on an Employee metric (covering your whole workforce) while licensing Financials and Procurement modules on an Application User basis (covering just the staff in those functions).
This kind of mix is common – each module’s licensing is independent. Oracle’s contract will list each product and the metric chosen for it. One thing to note is that you generally choose one metric within a single module. You wouldn’t mix metrics for the same product (e.g., you wouldn’t license some HR users by Employee and others by User – you pick one metric per product).
But across the suite, it’s fine: e.g,. Five hundred employees for Core HR, 50 application users for financials, and 10,000 expense reports for iExpenses are all in the same license agreement. Oracle’s flexibility here allows you to optimize cost module by module. Just be aware that some modules might only be offered under one metric.
But if Oracle offers a choice (like Employee vs User for an HR self-service module), you’d negotiate which metric to use. In summary, you can and should tailor the metric per module to your usage; mixing metrics in one EBS deployment is normal.
Q28: Can we change our licensing metric later (for example, switch from user-based to transaction-based)?
A: It is possible, but Oracle’s approval is required via a formal license migration. Oracle licenses are contractual, so you can’t unilaterally switch how you count licenses without amending the contract. However, Oracle often allows customers to migrate licenses from one metric to another to better suit their usage (sometimes called a conversion or migration).
For example, if you initially licensed Oracle Internet Expenses by Employee and later decide to license by number of Expense Reports, Oracle can facilitate converting those licenses. Typically, you would negotiate a conversion where your existing license investment is credited toward the new metric licenses. No additional license fees are required in a straightforward migration if the value is equivalent, though there might be adjustments if the metrics aren’t apples-to-apples. This process results in a new order document reflecting the new metric.
Remember that Oracle will only allow this if it makes business sense and both sides agree – it’s not an automatic right. Also, if the new metric results in a significantly lower cost for the same usage, Oracle might require you to true-up or meet some minimum (they won’t typically let you downgrade your spending). But from a practical standpoint, yes, companies change metrics (like Named User to Processor in tech licenses, Employee to Records, etc. in apps) via agreement with Oracle. It’s often done during renewals or when changes need to be made.
Always coordinate with your Oracle account manager for such changes. Oracle will issue a migration document and update support fees accordingly. In summary, metric changes are doable through negotiation—plan them carefully and ensure they’re formally documented.
Q29: Can we expand our Oracle EBS usage by adding more users or modules later?
A: One of the advantages of perpetual licensing is that you can grow your usage by purchasing additional licenses at any time. If you need to add more users to an already licensed module, you would order additional Application User licenses for that module (typically in blocks or as needed). Those new licenses co-term with your existing support (usually, you pay a prorated support fee for the remainder of the year).
The software has no technical limitation – you simply need to ensure you’ve paid for the appropriate number when you exceed your current allowance. Similarly, if you want to start using a new module you didn’t originally license, you can procure a license for that module and then deploy it. Many Oracle EBS customers start with a subset of modules and then purchase others as their needs grow (for example, adding Procurement or Manufacturing modules a year later).
The process is straightforward: you issue a purchase order or contract amendment for the new licenses, and Oracle provides the license keys or certs. Your Oracle Customer Support Identifier (CSI) gets updated to include the new products so you can download software and get support.
Financially, budgeting for expansion is good, as adding modules can be a significant cost. But you are not locked out from expansion – the EBS perpetual model is meant to be modular and extensible. Remember that adding a module might also entail prerequisite licenses if you lack them (refer back to Q21). Overall, scaling up (more users, more modules) is a normal part of the EBS lifecycle; it just involves buying the needed additional licenses, and then you’re entitled to use them perpetually under the same terms.
Q30: Do Oracle EBS perpetual licenses cover upgrades to new software versions?
A: Yes, with active support. You can use the version you bought forever when you own a perpetual license. To get upgrades to newer versions, you must have an active Oracle support agreement. Oracle’s policy is that customers with valid support can download and install new releases (for example, upgrading from EBS 12.1 to 12.2) without purchasing new licenses. The annual support fees you pay (which include Software Update License & Support) entitle you to product updates, patches, and new version releases.
If you let support lapse, you are still licensed for your current version but won’t be authorized to access or use newer versions. Oracle even notes that without support, you “cannot upgrade to later software versions”. So, essentially, the perpetual license gives you usage rights, and the support gives you upgrade rights. If you plan a major upgrade, ensure your support is current.
There’s no additional license cost to move from EBS 12.2 to a hypothetical 12.3 – it’s covered under support. (One exception: if Oracle were to release a substantially different product or module not covered by your existing licenses, that might require new licenses, but point releases and new versions of the same modules are included.)
In summary, perpetual licensing and support mean staying on the latest version. If you stop paying support, you’d be stuck on whatever version you last had rights to and would need to reinstate support (often with back fees) to upgrade later. Therefore, maintaining support is highly recommended to keep your Oracle EBS system current.
