EBS Self Service and Read Only User Licensing
Self service and read only EBS access can still require a licence. Whether an employee using self service screens or running inquiries becomes a chargeable user depends on the module, the responsibility, and the access configured, not on whether the access is light. Configuration, not headcount, decides the count.
Do EBS self service users need a licence?
This is the question that decides the largest EBS user populations, because self service access is deployed to the whole workforce. The short answer is that it depends, and the dependency is not on how lightly the user touches the system but on what they are authorised to do and under which licensed module. Some self service functionality is bundled with employee metric modules and adds no incremental user cost. Some self service access points at a full module and creates chargeable Application Users at scale.
Getting this distinction right is worth more than almost any other EBS remediation, because the populations are so large. A misclassification that turns ten thousand self service employees into full Application Users is a catastrophic finding; the correct classification can make the same population free or near free. The EBS licensing pillar frames the metrics; this article works through the self service grey zone specifically.
Employee self service and the Employee metric
Self Service HR, including employee facing screens for leave, expenses, personal data, and benefits, is generally tied to modules licensed by the Employee metric rather than Application User. Where that is the case, the self service population is already accounted for in the headcount based licence and does not add an incremental Application User charge. The exposure is not the self service access itself but the underlying module licence, which is a headcount reconciliation covered in the HR and Payroll licensing article.
The trap is assuming all self service behaves this way. It does not. Self service procurement, self service expenses tied to a financial module, and self service inquiry into operational modules can each point at products licensed by Application User, in which case the self service population becomes chargeable under that metric.
iProcurement and the requisition trap
iProcurement is the canonical example. Deployed as a self service requisitioning tool to the entire workforce, it can appear to be lightweight self service, but it is a licensed module with its own Application User metric. If every employee is granted an iProcurement responsibility, every employee is a candidate Application User for iProcurement. On a large workforce this single configuration decision can dwarf the rest of the EBS user position.
| Self service access | Likely metric | Incremental user cost |
|---|---|---|
| Leave, benefits, personal data (SSHR) | Employee | None if HR is licensed by headcount |
| Self service expenses (Internet Expenses) | Often Employee or activity | Depends on module licence basis |
| iProcurement requisitions | Application User | High if deployed to all staff |
| Operational inquiry / read only | Disputed, see read only article | Contested |
Are read only and inquiry users chargeable?
Read only and inquiry access is the most contested self service category. Oracle's general position is that the metric counts authorisation to use the program, and read only access is still use. Customers frequently argue that pure inquiry access, with no ability to create or change data, should not attract a full user licence. The contractual reality varies by agreement, and the outcome often turns on the specific responsibility configuration and the wording of the customer's licence definitions.
Because this is genuinely contested, it is an area where documentation and configuration discipline pay off. A clearly bounded, demonstrably read only responsibility is a far stronger position than ambiguous access that mixes inquiry with latent transactional capability. The read only reporting users article develops the argument, and where a claim turns on it, the audit defence practice argues the position.
How to control the self service population
The control levers are configuration levers. Map each self service entry point to the module and metric behind it. Confirm that employee metric self service is not inadvertently granting Application User module access. Bound iProcurement and other module backed self service to the population that genuinely needs it rather than the whole workforce. And configure read only access as demonstrably read only, separated from transactional responsibilities. Each of these is a decision that changes what Oracle's measurement returns.
This work sits inside the broader Application User reconciliation, so it is best done together with the steps in the Application User article as part of a single baseline run by the applications licensing practice.
The buyer side view
Self service is where EBS licensing is won or lost at scale, because the populations are measured in thousands. The buyer side discipline is to refuse the assumption that light access means free access, and instead map every self service entry point to its real metric. Where the metric is Employee, the cost is already in the headcount licence. Where it is Application User, the deployment scope is the cost, and scoping it to genuine need is the saving.
Treat self service as a configuration to be designed for licensing, not a convenience to be granted universally, and the largest user populations in the estate stop being the largest exposure. To map and bound your self service populations, request a consultation.
Configuration patterns that decide cost
Because the self service licence outcome turns on configuration, a handful of recurring patterns determine the cost for the largest populations. The first is responsibility scope: a self service responsibility that bundles transactional functions alongside the self service screens pulls the whole population into the transactional module's metric. The second is module attachment: a self service entry point that calls a function belonging to a full Application User module attaches that module to every user who can reach it. The third is the inquiry boundary: where read only access is mixed with latent transactional capability, the access is hard to defend as read only.
Each pattern has a clean counterpart. Scope self service responsibilities to the self service functions only. Confirm that self service entry points call self service functions, not full module functions. And configure inquiry access as demonstrably and exclusively read only, separated from any transactional responsibility. These are configuration decisions, and they change what Oracle's measurement returns, which is why the Application User article treats responsibility design as the core lever across the whole estate.
The scale of the stakes justifies the diligence. A self service population is measured in thousands, so a single misconfiguration that attaches a full module to the workforce is among the largest findings an EBS audit can produce. Conversely, a clean self service configuration removes the largest population from the chargeable count entirely. Few licensing controls have a higher ratio of effort to saving.
The contract decides the grey zone
Where self service and read only access is genuinely contested, the deciding document is the customer's own agreement, not Oracle's general policy. Licence definitions vary across ordering documents and over time, and the precise wording of the user definition, the description of the module, and any negotiated read only or self service provisions determine the outcome. Two customers with identical deployments can have different positions because their contracts say different things.
This is why the first step in any self service dispute is to extract and read the controlling definitions rather than to argue from first principles. A favourable definition is decisive; an unfavourable one sets the boundary of what can be argued on configuration alone. The read only reporting users article develops the inquiry specific argument, and where a claim turns on these definitions, the audit defence practice argues the position against the actual contract. The general lesson, repeated across the cluster, is that EBS licensing is decided on the specific agreement and the specific configuration, never on Oracle's policy statements alone.
Common questions.
Do EBS self service users need a licence?
It depends on the module and metric behind the self service access, not on how lightly the user touches the system. Self service tied to Employee metric modules adds no incremental user cost; self service pointing at a module licensed by Application User makes the population chargeable.
Does iProcurement require a licence for every employee?
iProcurement is a licensed module with an Application User metric. If every employee is granted an iProcurement responsibility, every employee is a candidate Application User. Scoping the responsibility to the population that genuinely requisitions is the key control.
Are read only EBS users chargeable?
This is contested. Oracle's general position is that authorisation to use the program is chargeable and read only access is still use. The outcome often turns on the responsibility configuration and the customer's specific licence definitions, so a demonstrably read only, bounded responsibility is a stronger position.
Is Self Service HR licensed separately?
Self Service HR is generally tied to modules licensed by the Employee metric, so the self service population is accounted for in the headcount based licence rather than adding incremental Application Users. The exposure is the underlying module licence, a headcount reconciliation.
How do we control the EBS self service user count?
Map each self service entry point to its module and metric, confirm employee metric self service is not granting Application User module access, bound module backed self service such as iProcurement to genuine need, and configure read only access as demonstrably read only.