Named User Plus vs Application User on EBS

Two metrics, two layers

Oracle E-Business Suite is not a single licensable thing; it is an application layer running on a technology layer, and the two layers are licensed under different metrics. The application modules, the Financials, the HR, the Supply Chain, are licensed on the Application User metric. The Oracle Database underneath, and any separately licensed middleware, are licensed on Named User Plus or on processor metrics. Treating EBS as one product under one metric is the conceptual error that produces the most common and most expensive audit findings, because it leads customers to count one layer by the rules of the other.

The distinction matters because the two metrics count different populations by different rules and carry different minimums. A clean EBS position reconciles each layer to its own metric: the modules to Application User, as set out in the Application User article, and the database to Named User Plus or processor, within the bounds of the restricted use grant covered in the restricted use database article. The EBS licensing pillar places both in the wider context. This article compares them directly so the boundary is unambiguous.

The Application User metric

The Application User is an individual authorised to use the application programs, counted through responsibilities and without any processor minimum. Its defining characteristics are that it counts people, that it counts authorisation rather than activity, and that the count is generated from the EBS security configuration you control. Because there is no processor minimum, the Application User count is purely a function of how many people you authorise, which makes it the most controllable metric in the Oracle catalogue: trim the responsibilities and the count falls.

This controllability is the metric's great advantage. An estate that manages access tightly presents a low Application User count regardless of how powerful the underlying hardware is, because the metric does not look at hardware at all. The full mechanics of how the count is assembled, and how it inflates through broad responsibilities and stale accounts, are the subject of the dedicated Application User article. What matters for the comparison here is the contrast: Application User is a people count with no hardware floor.

The Named User Plus metric

Named User Plus is the database and technology metric, and it counts differently in two important ways. First, it counts not only individuals but non human operated devices that access the program, so a sensor, a service, or an integration that touches the database is a named user. Second, and decisively, it carries a per processor minimum: the contract specifies a minimum number of named users for each licensed processor, and the count cannot fall below that floor no matter how few people actually use the system.

The practical effect is that Named User Plus behaves like a hybrid of a user metric and a processor metric. On small hardware with many users, the user count dominates and NUP behaves like a people metric. On large hardware with few users, the processor minimum dominates and NUP behaves like a processor metric, charging you for users you do not have. This is why the same database, moved onto more cores, can become more expensive under NUP even with no change in the user population, a dynamic developed further in the database licensing practice.

Why processor minimums catch people out

The processor minimum is the trap that turns a NUP licence costly. A customer who licenses the EBS database on Named User Plus reasoning that they have only a few hundred direct database users can find that the per processor minimum, multiplied across a large, high core server, sets a floor far above their actual count. They are then licensing to the minimum, paying for thousands of notional users to satisfy the per processor rule. The decision between NUP and processor licensing for the database layer therefore turns on the ratio of users to cores, and that ratio should be calculated before the metric is chosen, not discovered in an audit.

Because the minimum is contractual, it cannot be configured away the way an Application User count can. The levers for a NUP position are the number of licensed cores and the number of devices and individuals with direct database access, both of which require infrastructure and architecture decisions rather than security configuration changes.

Which metric applies where

The allocation is layered and, once understood, unambiguous. The EBS application modules are Application User. The Oracle Database that EBS runs on is governed by the restricted use grant bundled with EBS, which permits use in support of the licensed applications; use beyond that grant, such as custom reporting, direct queries, or other applications sharing the database, is licensed on the full database metric, Named User Plus or processor, with its minimums. Separately licensed middleware follows its own metric. A person who only uses application modules is an Application User and nothing else; a person who also accesses the database directly, beyond the restricted grant, is additionally a named user of the database.

The boundary that causes the most findings is the restricted use line. Customers assume the bundled database grant covers all their database use, then build custom reporting or third party integrations that read EBS tables directly, which exceeds the restricted grant and pulls full database licensing into scope, often at the punishing NUP minimum. This boundary is the entire subject of the restricted use database article, and getting it right is the difference between a contained EBS position and an unexpected database claim. The applications licensing practice reconciles both layers together so the boundary is documented rather than assumed.

The buyer side view

The clearest way to think about EBS licensing is as two stacked positions, each on its own metric, that must be reconciled separately and never netted. The application layer is an Application User position you control through responsibilities, with no hardware floor and every incentive to manage access tightly. The technology layer is a Named User Plus or processor position you control through cores and direct access, with a contractual minimum that punishes large hardware and rewards architectural restraint. Confusing the two, or assuming the bundled database grant stretches further than it does, is the source of most EBS findings.

The buyer side discipline is to know exactly which metric governs which layer, to count each by its own rules, and to watch the restricted use boundary where the application layer quietly pulls the technology layer into scope. Do that, and the two positions stay clean and independent; ignore it, and a well managed Application User count is undone by a database claim nobody saw coming. To reconcile both layers of an EBS estate to their correct metrics, request a consultation.

Worked example: the same estate under each metric

The difference between the two metrics is easiest to see on a single estate. Consider a manufacturer running EBS Financials for eight hundred finance staff on a database server with sixteen cores, with only forty of those staff holding direct database access for reporting. On the application layer, the position is straightforward: eight hundred Application Users of the relevant Financials modules, with no hardware floor, the count driven purely by how many people are authorised. Trim the responsibilities and that number falls; the cores are irrelevant to it.

On the database layer the picture inverts. If the database is licensed on Named User Plus with a per processor minimum of, say, twenty five users per core, the contractual floor is sixteen cores multiplied by twenty five, or four hundred named users, even though only forty people have direct access. The estate would have to license four hundred named users to satisfy the minimum, ten times its actual direct user count, purely because of the core count. The same forty users on a four core server would face a floor of one hundred, and on processor licensing the decision would turn on the core count alone.

The lesson is that the two layers respond to opposite levers. The application position is controlled by managing people and responsibilities; the database position is controlled by managing cores and direct access, with the minimum setting a floor that headcount cannot lower. A customer who optimises one while ignoring the other is exposed on the side they neglected, which is why both must be reconciled, never netted, as the baseline methodology requires.

Minimums, ULAs and metric conversion

The choice of metric is not always fixed for the life of an estate. At renewal, at the point of a major hardware change, or within an unlimited agreement, there can be scope to convert between Named User Plus and processor licensing for the database layer, and the right choice depends on the user to core ratio that the worked example illustrates. A low user, high core environment favours processor licensing because the named user minimum would punish it; a high user, low core environment can favour Named User Plus. Modelling both before committing is the difference between an efficient database position and an expensive one.

Unlimited agreements complicate the picture usefully. Within a ULA the metric distinction is suspended for the products in scope, because deployment is unlimited during the term, but it returns sharply at certification, when the deployed quantity is fixed into perpetual licences under a specific metric. The metric chosen at certification, and the core count at that moment, lock in the cost for years, which is why certification planning and metric selection are inseparable and why the interaction belongs with ULA negotiation support. The application layer's Application User count and the database layer's metric both crystallise at certification, and getting either wrong fixes an inefficient position permanently.