Oracle EBS Licensing – What Is Primary Usage
Executive Summary: Oracle E-Business Suite (EBS) on-premises licensing can be complex, particularly with legacy models such as Primary Usage. Primary Usage is an older Oracle licensing metric that allowed a user to access multiple core EBS modules with a single license count.
This article explains what Primary Usage means in Oracle EBS licensing, how it differs from modern licensing models, and why IT asset managers need to understand it to avoid compliance pitfalls and optimize costs.
Oracle EBS Licensing Basics (On-Premises)
Oracle EBS is licensed mostly by users rather than by hardware. Traditionally, each EBS module (e.g., Financials, Procurement, HR) requires a license per named user.
For example, if 100 employees need access to the General Ledger module, you need 100 user licenses for that module.
If 50 of them also need the Purchasing module, that would normally require another 50 licenses for Purchasing. In other words, under standard licensing, a single person using two modules counts twice (once for each module).
Oracle also offers some enterprise metrics (like licensing by total employees or revenue) for certain modules, but user-based licensing is the norm for EBS on-prem deployments.
This per-module, per-user model is precise but can become complex and costly if the same individuals use multiple modules.
It demands diligent tracking of user accounts in each application to ensure you have enough licenses and remain compliant. No generic “EBS user” license covers all modules by default – each module is a separate entitlement under standard rules.
Read about EBS Read-only licenses.
The Legacy “Primary Usage” Licensing Model
Primary Usage is a legacy EBS licensing concept designed to avoid double-counting users across certain core modules.
Years ago, Oracle offered an E-Business Suite licensing option (often called a “suite user” or Professional User license) where a user would be counted only once across a bundle of related applications. In Oracle’s documentation, Primary Usage was defined around five key application areas:
- Financials (core finance modules like General Ledger, Accounts Payable, Accounts Receivable, etc.)
- Discrete Manufacturing
- Process Manufacturing
- Project Costing
- Purchasing (core procurement modules)
Under the Primary Usage model, each user of these core applications is counted only once based on their primary module usage. If a person’s primary role is in Financials, you would count them as a Financials user (and purchase a license for Financials).
That license would entitle them to use the other listed modules (Manufacturing, Purchasing, Projects) as needed.
In essence, licensing one user for their primary application granted rights to the others in the suite, as long as your organization was licensed for those modules.
This eliminated the need to buy separate user licenses for each of those core modules for the same individual.
However, Primary Usage rights only applied to that specific set of applications. It did not cover other EBS modules outside the core bundle.
For instance, modules such as Human Resources, Order Management, CRM, or any optional extensions were not included – those would still require their licenses.
Primary Usage was a way to bundle the core ERP functions, allowing one user license to cover Financials, Purchasing, Manufacturing, and Projects simultaneously.
Why did Oracle offer this? It simplified licensing for broad ERP deployments and could make it more cost-effective for companies whose users naturally span multiple core functions.
Rather than charging the customer twice for the same user’s access to two modules, Oracle’s suite license (Primary Usage) counted them once.
This was particularly attractive in the early 2000s when many enterprises were first implementing integrated ERP suites.
Primary Usage vs. Modern User Licensing
Oracle eventually moved away from the Primary Usage/suite user model.
Modern EBS licensing treats each module separately – meaning today, if a user needs five different modules, they need five separate licenses (one per module).
The legacy Primary Usage metric is generally no longer sold in new contracts.
Oracle now expects customers to license “by module, by user” or use alternative metrics, such as enterprise or transactional metrics, where offered.
Let’s compare how a scenario would work under Primary Usage versus the standard model:
- Scenario: 50 users require access to Oracle Financials, and within this group, 20 also require access to Oracle Purchasing.
- Under standard licensing (per-module user): You need 50 Financials user licenses and 20 Purchasing user licenses. So in total, you are licensing 70 “instances” of use (even though it’s 50 people). For example, if a Financials User license costs $4,600 and a Purchasing User license costs $3,000, the total cost would be 50 × $4,600 + 20 × $3,000 = $290,000 (plus annual support fees). Each module is counted separately.
- Under Primary Usage (legacy suite licensing): You would count each person only once, based on their primary application. Assume all 50 are primarily Financials users – you would buy 50 Financials (suite) user licenses, and those users could also use Purchasing without extra user licenses. If a Financials suite user license were, say, $5,000 each, the cost would be 50 × $5,000 = $250,000 (plus support). The 20 users who also need Purchasing are covered by their primary Financials license. In this example, the Primary Usage model avoids paying twice for those 20 users, resulting in savings.
Table: Primary Usage vs. Standard User Licensing
| Licensing Model | How Users are Counted | Example: 50 Financials users, 20 also in Purchasing |
|---|---|---|
| Legacy Primary Usage | Count each user once in core suite | License 50 users total. (All 50 as Financials users cover Purchasing access for the 20.) |
| Modern Per-Module User | Count each user for every module used | License 50 Financials users and 20 Purchasing users (70 total user licenses counted). |
In practice, the Primary Usage approach could significantly reduce license counts for multi-module users. However, Oracle offset this benefit by pricing suite user licenses higher and by imposing minimum purchase requirements.
For example, under some older contracts, customers had to maintain a certain baseline of Professional User licenses (suite licenses) – often at least 10% of the total employee count – to continue using that model.
This ensured that Oracle still received substantial license revenue, even while allowing bundled use.
Why Primary Usage Matters Today
If Primary Usage is no longer sold, why should IT asset management professionals care about it now? The reason is legacy contracts and audits.
Many large enterprises that purchased Oracle EBS years ago may still be on these older licensing metrics.
Oracle typically grandfathered existing customers, allowing them to continue under the old terms (and even purchase additional licenses under those terms) as long as they adhered to that agreement.
For an ITAM professional, it’s crucial to:
- Understand your licensing entitlements: You may discover that your EBS contract from 2004 includes a Primary Usage clause or references “E-Business Suite Professional User” licenses. This knowledge can help prevent you from accidentally overcounting or purchasing unnecessary licenses under the new model.
- During audits, Oracle’s audit teams might assume the modern model by default. If you have Primary Usage rights, you’ll need to document and remind Oracle of those contract terms. For example, if an auditor sees 50 users in Financials and 50 in Purchasing, they might initially flag it as needing 100 licenses. You must be prepared to demonstrate that, under your Primary Usage agreement, these are the same 50 users counted only once. Always keep copies of the contract definitions (the clause defining Primary Usage and any special terms, such as the 10% minimum) handy to avoid misunderstandings.
- Expanding or upgrading: If you plan to add new EBS modules or more users, you should evaluate whether you can still purchase under the old model or if any changes (like moving to Oracle Fusion Cloud or a contract renewal) will force a shift to modern licensing. Oracle may push you to migrate off the legacy model, especially if you make significant changes to your licensing (they might offer a deal to convert to current metrics). Knowing the cost impact of losing Primary Usage is vital for negotiation.
Furthermore, understanding Primary Usage helps in cost optimization. If you do have it, you want to maximize its benefit by ensuring that all users who are cross-module are covered under the suite license, rather than mixing metrics.
Conversely, if you’ve partially moved to newer licensing, be careful not to “double-pay.” Sometimes, companies unknowingly end up licensing the same user twice (once under an old metric and once under a new metric) if they don’t have a clear strategy in place.
Key Considerations and Pitfalls
Managing Oracle EBS licenses with a Primary Usage metric introduces some unique considerations:
- License Tracking: You’ll need to track not only the number of users per module, but also which module each user designates as their primary. Typically, a user’s primary usage might correspond to their main job function. Define a clear rule – for example, if a user has access to multiple core modules, assign their license to the module in which they spend the majority of their time or the one with the higher licensing cost. All users should be counted in one of the primary usage categories (Financials, Manufacturing, Projects, or Purchasing) without overlap.
- Included vs. Excluded Modules: Remember that Primary Usage only covers the specific suite (the five core areas listed). If those same 50 Financials users also need access to, say, Oracle HR or Order Management (which are outside the defined suite), you must license those separately. One common pitfall is assuming a suite user can use any EBS module – they cannot. It’s limited to the designated programs. Extensions or options of the core modules (such as Advanced Procurement add-ons or specific manufacturing options) were also not automatically included under primary usage unless explicitly specified. Always check if additional modules require add-on licenses.
- Maintaining Contract Requirements: Legacy suite licenses often had contractual minima or ratios. For example, you might be required to keep a minimum number of Professional User licenses active (e.g., at least 10% of your total employees, as was the case in Oracle’s old EBS 2003 pricing model). Failing to maintain that could technically breach the agreement. In practice, if your user count grows significantly, you may need to purchase more licenses to meet a minimum threshold. Be aware of any such clauses in your agreement.
- Audit Scripts Alignment: Oracle’s audit scripts and tools will typically report raw counts of user accounts per module. If you’re on Primary Usage licensing, those raw counts need interpretation. It may fall to you to reconcile the data, for example, by identifying that the 50 Purchasing users are the same as the 50 Financials users. Oracle’s License Management Services might not automatically do that consolidation for you. Being proactive in presenting the data aligned with your entitlement (perhaps by providing a mapped list of users and their primary designations) can help avoid confusion.
- No New Sales on Primary Usage: If you need to purchase new modules or additional user licenses, Oracle may not officially quote the old metric unless your contract explicitly allows for it to be extended. You may have to negotiate to keep the old model. Sometimes Oracle will instead propose moving you to a newer licensing metric (potentially via an enterprise agreement or an unlimited license agreement for EBS). Weigh the pros and cons – the suite licensing was favorable in avoiding double-counting, but a modern unlimited agreement might offer other benefits. Always run a cost comparison.
Recommendations (Expert Tips)
1. Know Your Contract: Obtain and study your Oracle EBS license agreement and ordering documents. Identify if Primary Usage or suite metrics are mentioned. Highlight those clauses for easy reference during audits or negotiations.
2. Map Your Users: Maintain a detailed mapping of all EBS users to the modules they access. If you use Primary Usage licensing, assign each user a primary module for license counting purposes. Keep this updated as roles change.
3. Audit Yourself Regularly: Don’t wait for Oracle’s audit. Conduct internal license audits at least annually. If using Primary Usage metrics, ensure that your user counts per module align with your entitlements and that no user who is enabled in a core module suite is being inadvertently counted twice.
4. Educate Stakeholders: Make sure your IT, finance, and procurement teams understand the licensing model. If it’s a legacy system, new team members or even Oracle representatives might not be familiar with Primary Usage. Internally, ensure that everyone is aware of the licensing implications associated with adding a user to an EBS module, as well as the specific rules applicable to your model.
5. Cautious Expansion: If planning to roll out a new EBS module (especially one not covered by your Primary Usage suite), budget for the proper licenses. Don’t assume it falls under existing licenses. Please consult with Oracle or a licensing expert to determine how new modules would be licensed under your current contract.
6. Negotiate Mindfully: When renewing support or discussing cloud migrations, leverage your favorable terms. Oracle may offer cloud credits or discounts if you relinquish on-premises legacy terms. Calculate the value of your Primary Usage savings before agreeing to any change. You may negotiate to retain some benefits or get equivalent value in a new deal.
7. Document Everything: Keep records of communications with Oracle about your licensing. If Oracle representatives acknowledge your Primary Usage model in writing, keep it on file. During audits or personnel changes on Oracle’s side, having a paper trail helps resolve disputes quickly.
8. Use Tools Wisely: If you have access to Oracle’s License Management Services tools or third-party license management software, configure them with your licensing model. Some tools allow custom metrics – set up a report that consolidates users by primary usage to simplify compliance tracking.
9. Monitor Oracle Policy Updates: Although Primary Usage is legacy, Oracle licensing policies can change. Stay informed through Oracle’s official channels or ITAM professional networks in case any announcement affects legacy licensing (for example, if Oracle were to sunset support for certain contracts or offer a transition program).
10. Consult Experts: Oracle licensing is notorious for nuance. Don’t hesitate to consult an independent Oracle licensing advisor or legal counsel when making big decisions (such as contract renewals or responding to an audit finding). An expert can interpret your Primary Usage clause in context and help communicate it properly to Oracle’s audit team.
Checklist: 5 Actions to Take
- Retrieve Your Oracle EBS Agreements: Locate the original license contract, as well as any ordering documents or amendments. Confirm if you have the Primary Usage licensing clause or any suite licensing metrics in those documents.
- Inventory Your EBS Users: Collaborate with your EBS administration team to obtain a report of all user accounts organized by module. Deduplicate and determine the count of unique users across the core modules. Align each user to a primary application (if applicable).
- Validate Compliance Position: Compare your effective user counts (with Primary Usage considered) to the number of licenses you have purchased for each module or suite. Ensure you are not overusing any module beyond your entitlement. If the contract requires a minimum (e.g., 10% of employees licensed as Professional Users), check that as well.
- Update Internal Records: Maintain a licensing worksheet or system that notes which licensing metric applies to each module in use. Flag the modules covered under the Primary Usage bundle versus those that aren’t. This will help prevent mistakes, such as assigning a user to an unlicensed module.
- Plan for the Future: Develop a forward-looking plan. If your organization might migrate off Oracle EBS (to cloud or another ERP) or if an Oracle renewal is upcoming, outline how you will handle the licensing transition. If staying on EBS, plan for any growth – know how you will acquire additional licenses and what model will be used. Budget for support fees accordingly, as 22% annual support on licenses is significant over time.
By following this checklist, you can ensure you’re not caught off guard by the intricacies of Oracle’s licensing, and you’ll be prepared for any Oracle audit or contract negotiation.
FAQs
Q1: Is Primary Usage licensing still available from Oracle?
A1: Not in standard pricing for new Oracle EBS licenses. Primary Usage was a legacy licensing model from the early 2000s. Oracle now sells licenses per module (or via modern site-based metrics). However, if your company already has Primary Usage terms in a legacy contract, you can usually continue under those terms. Be aware that Oracle may encourage you to move to newer models if you make changes.
Q2: How do I determine a user’s “primary” application for licensing?
A2: Typically, the primary usage corresponds to the main module tied to the user’s role. For example, if an employee works mainly in Finance but occasionally in Purchasing, you’d count them as a Financials user (primary in Financials) under the suite license. You should count each person once, under the module where it makes the most sense (often the module they use most or the module with the highest cost). The key is consistency and documentation – decide on a rule and apply it uniformly.
Q3: What if a user needs a module outside the Primary Usage suite?
A3: Then you must license that separately. Primary Usage rights only cover the set of core programs defined (Financials, Manufacturing, Projects, Purchasing). Any other EBS module (for instance, Human Resources, CRM, Order Management, etc.) requires its user licenses even if you have a suite license. Your users would then have two types of licenses: one covering the core suite (counted via Primary Usage) and additional licenses for any extra modules. Keep track so these users are not overlooked in compliance.
Q4: We’re undergoing an Oracle license audit – what should we do about Primary Usage?
A4: First, inform Oracle’s auditors upfront that you have legacy EBS licenses with a Primary Usage metric (if that’s the case). Provide them with the specific contract wording that shows how users should be counted. Then provide your user counts in a way that aligns with that model (e.g., “X unique users across Financials/Projects/Purchasing, counted per Primary Usage license”). If the auditors are unfamiliar with the metric (which can happen), you may need to patiently explain or involve someone from Oracle who knows legacy contracts. Being transparent but firm about your contractual rights is important.
Q5: What are the cost implications of moving off Primary Usage to a modern model?
A5: It depends on your usage profile. If many of your users access multiple core modules, moving to per-module licensing could substantially increase your license counts (and costs) because you’d start counting each user multiple times. On the other hand, Oracle might offer an Unlimited License Agreement (ULA) or a discounted enterprise metric deal to compensate. Always model the scenario: calculate how many total user licenses you’d need under the new model versus how many suite licenses you have now. Include the 22% annual support cost in the comparison. This analysis will provide a dollar figure to use in discussions. If giving up Primary Usage will cost an additional $X million over a few years, you can request concessions of similar value (or decide to maintain the status quo if possible).
