Oracle EBS User Compliance

Oracle E Business Suite licensing is one of the most complex areas of the Oracle product line. The named user definitions vary by module. The compliance position depends on which combination of modules is licensed and how the user roles interact across the suite. Most customers carry compliance risk in EBS that they would not accept in any other Oracle product.

This article walks through the EBS user compliance framework on the buyer side. It is a companion to our licensing compliance pillar and supports our audit defense service.

The User Categories in EBS

EBS licensing recognises several user categories. Application user, professional user, employee user, supplier user, customer user, and self service user each appear in different EBS modules with different rules.

The application user is the broadest category. It applies across the suite and licenses a named individual to access any EBS function. The professional user is a narrower category that applies to power users in specific modules. The employee user category applies to HR and self service functions. The supplier and customer user categories apply to portal access by external parties. The self service user category applies to limited functions within HR and procurement.

Each category has a different price and different counting rules. Customers who use only the application user count often discover at audit that they should have been counting employees, suppliers, and customers under their own categories. The mismatch produces the compliance exposure.

The Counting Rules

The named user count is not the headcount. Oracle's counting rules require that any individual who can access an EBS function be counted, regardless of whether they actually do. Dormant accounts, terminated employees who retain access, contractors who use occasional access, and seasonal workers all count.

The minimum user requirement is also a feature of EBS licensing. Some modules require a minimum number of named users per processor, regardless of actual usage. The minimum requirement produces compliance exposure when the deployment grows past the licensed processor count without a corresponding user purchase.

The cross module rule complicates the picture. A user who has access to multiple EBS modules must be licensed for each. A user with general ledger access and accounts payable access requires two licences, not one. The cross module count grows quickly as users acquire role assignments over time.

The Role Assignment Problem

EBS role assignments accumulate. Users who join the organisation receive role assignments based on initial job description. Role assignments are then added as the user changes job, supports new projects, or covers for absent colleagues. Role assignments are rarely removed.

The accumulation produces compliance exposure that scales with tenure. A user who has been at the organisation for ten years often holds role assignments that span six or seven EBS modules. Each role assignment is a licensable touch point. The licence count required to cover the actual role assignments is often much larger than the licence count purchased.

The buyer side response is a role review programme. Role assignments should be reviewed annually. Inactive role assignments should be removed. The user's current role profile should match the user's current job. Customers who run the role review consistently maintain a sustainable licence position. Customers who skip the role review accumulate exposure.

The Audit Methodology

Oracle's audit of EBS users begins with a data extract from the EBS user table. The audit team requests the FND USER table and the role assignment tables. The data is loaded into Oracle's analysis tools and the licensable user count is calculated.

The methodology applies the counting rules strictly. Inactive users are counted unless explicitly disabled. Cross module assignments are counted as multiple licences. Role assignments that grant access to licensable modules are counted regardless of whether the user has used them.

The customer defence rests on the inverse measurement. The customer should run the same extracts internally, validate the user records, and identify users who should be disabled rather than licensed. Each disabled user reduces the count. Each cross module assignment that can be eliminated reduces the count. The defence proceeds line by line.

The Self Service User Category

The self service user category is often the source of the largest disputes. Self service users are employees who access limited HR and procurement functions through a self service interface. The category is priced lower than the application user category.

Oracle's policy on self service users has tightened over time. Early agreements treated almost any employee access as self service. Recent agreements limit self service to specific functions and require application user licences for any role that extends beyond the limited set. The customer's contractual position depends on which version of the agreement applies.

The defence rests on the contractual ground. Customers with older agreements should hold to the original self service definition. Customers signing new agreements should negotiate explicit self service language that protects the broader population of employee users.

The Supplier and Customer User Categories

The supplier and customer user categories apply to external parties who access EBS through portals. The category is priced lower than the application user category and is intended for portal access only.

The audit risk here is the boundary between portal access and full application access. Customers who allow suppliers to access functions beyond the portal scope find that Oracle reclassifies the supplier users as application users at audit. The reclassification produces large findings.

The defence is architectural. The portal should be a separate interface from the core EBS application. The supplier access should be limited to portal functions. The licence category should match the actual access pattern. Customers who maintain this discipline keep the supplier and customer categories defensible. Customers who blur the boundary face audit exposure.

The Custom Extensions

EBS customisations and extensions add a layer of compliance complexity. Custom forms, custom reports, and custom workflows often grant access to underlying EBS data. The users of the custom extension may be licensable for the underlying EBS modules even if they never access the standard EBS interface.

The audit position is that users of any extension that reads or writes EBS data require the corresponding EBS licences. The position is defensible from the contract. The customer's exposure depends on how many users access the custom extensions and which underlying EBS modules they touch.

The compliance posture should treat custom extensions as part of the EBS deployment. The user inventory should include extension users. The role assignment review should examine extension permissions. The licence count should cover the actual access pattern across both standard and custom interfaces.

The Migration Trigger

EBS migrations to Fusion Cloud or to other ERPs are a common audit trigger. Oracle's audit programme often targets EBS customers who are in the middle of a migration because the migration disrupts the user inventory and creates ambiguity about who is using which system.

The customer defence during migration is to maintain rigorous user records on both sides of the migration. The EBS user count should be tracked. The Fusion user count should be tracked. The transition users who exist in both systems should be classified explicitly. Audit findings during migration are easier to defend when the customer can show the user inventory across the transition.

Where to Read Next

For the BYOL compliance rules see our BYOL article. For the broader compliance posture see our licensing compliance pillar. The Oracle Audit Defense Handbook covers the full methodology. The Apps Unlimited deal page covers EBS contracting. The EBS product page covers the product family.