How does Named User Plus counting work in an audit?
The Oracle Named User Plus audit turns on a definition that is broader than most customers assume. A Named User Plus is an individual authorised to use a program, or a non human operated device where one is used, regardless of whether they are actively using it at the moment of measurement. Authorisation, not active use, is the test, which is why dormant accounts, leavers who were never deprovisioned, and accounts created for occasional use all potentially count. The audit measures this population against the NUP licences held for each program.
Layered on top is the per processor minimum. Oracle sets a minimum number of Named User Plus licences per processor for many programs, so even a database with very few human users must be licensed for at least that minimum multiplied by its processor count. This means the licensable figure is the higher of the actual authorised user count and the minimum, and for lightly used databases on large servers the minimum, not the user count, frequently drives the number. The interaction of users, processors, and minimums is part of the metric foundation in the audit defence pillar.
Because both the user count and the minimum can be measured wrongly, the Named User Plus finding is one of the more error prone parts of any audit report, and one of the more recoverable when reviewed properly. The data behind it comes from the same collection described in the audit scripts guide, and reviewing that account data before it is submitted is the single most effective step.
Where Named User Plus counts get inflated
The commonest inflation is counting non human accounts as users. A database carries many accounts that are not people: service accounts, application schema owners, batch and integration accounts, monitoring accounts, and built in system accounts. None of these is a Named User Plus in the contractual sense, yet a raw account list hands Oracle all of them, and if the customer does not separate them, they inflate the count directly. Deduplication is the second issue, where one individual holds several accounts across systems and is counted multiple times rather than once.
| Account type | Oracle's default | Correct treatment |
|---|---|---|
| Human end user | Counts as one NUP | Counts once, deduplicated across systems |
| Service or schema account | Counted as a user | Excluded, not a human user |
| Batch or integration account | Counted as a user | Excluded, technical account |
| Disabled or leaver account | Counted if still present | Excluded where genuinely deprovisioned |
| Multiplexed front end users | Often overlooked | Counted, multiplexing does not reduce NUP |
There is a counterweight the customer must respect: multiplexing does not reduce the count. Where a middle tier or front end pools many human users behind a few database connections, Oracle counts the humans, not the connections, and a customer who assumes pooling protects them will undercount. Honest counting cuts both ways, removing technical accounts while including genuine end users behind any multiplexing layer, and the net effect for most estates is still a substantial reduction from the raw account list.
Getting the per processor minimums right
The per processor minimum is the other place findings go wrong. Applying it requires the correct processor count, after the core factor, for each program, and the correct minimum for that specific program, since minimums differ. An audit that overcounts processors, the same core counting error that inflates the processor metric, also inflates the Named User Plus minimum, compounding the error. Checking the processor basis is therefore part of checking the user finding, not a separate exercise.
Named User Plus is the higher of real users and the processor minimum. Get the processor count wrong and you overpay even with perfect user data.
The practical reconciliation compares, for each program, the deduplicated human user count against the minimum implied by the correct processor count, and licenses to the higher of the two. Holding this calculation in your own effective licensing position means that when the audit report arrives, you can test its Named User Plus lines immediately, which is exactly the line by line challenge described in the findings report guide.
Defending a Named User Plus finding
Defending the finding is an evidence exercise. The customer produces an account inventory that classifies every account as human or technical, deduplicates individuals across systems, and documents deprovisioning for leavers, then applies the correct minimum against verified processor counts. Each exclusion is supported, a service account named and explained, a duplicate identity mapped, so that the corrected figure is defensible rather than merely asserted.
This is detailed work, but it is among the most rewarding in an audit because the corrections are concrete and hard for Oracle to rebut. A named service account is self evidently not a person. An independent firm running the audit defence service performs this classification routinely, and the full method for testing user metrics sits in the audit defence white paper.
Devices and the operated device rule
The Named User Plus definition counts both individuals and non human operated devices where they are authorised to use a program, and this part of the metric is frequently overlooked in both directions. On one side, customers forget that automated devices, sensors, terminals, or machines that access the database without a human operator can themselves require counting, leading to undercounting in environments built around machine to machine access. On the other side, Oracle sometimes counts devices that do have a human operator, where the operator should be the unit counted rather than the device.
Getting this right requires understanding the deployment architecture, not just the account list. An estate with a large population of automated devices feeding a database has a genuinely different Named User Plus profile from one accessed only by human users, and the contract's definition of an operated device determines which is which. This is a question the customer should resolve from the agreement and the architecture together, in the same way it resolves the human account classification.
The device question interacts with the per processor minimum as well, because in heavily automated environments the device and user count may still fall below the minimum, in which case the minimum governs regardless. Working through both the device population and the minimum gives the true licensable figure, and holding that figure in the effective licensing position means it can be defended directly when the audit report asserts something different.
Because the device rule is nuanced and architecture dependent, it is one of the areas where independent review pays off most, and where a generic account count is most likely to mislead. The audit defence service assesses device populations alongside human users so that neither is miscounted, and the full treatment of the user metric sits in the audit defence white paper.
The buyer side view
Named User Plus findings reward customers who count carefully and punish those who forward a raw account list. The customers who settle small classified every account, deduplicated their people, deprovisioned cleanly, and applied the minimum against verified processor counts, often reducing the finding to nothing. The customers who settle large let Oracle treat every account, human or not, as a billable user, and accepted a processor minimum built on overcounted cores.
Separate people from machines, deduplicate, and check the minimum against the right processor count. Review the account data with the audit scripts guide, hold the calculation in your effective licensing position, and see how it fits the whole defence in the audit defence pillar.
Oracle Named User Plus audit: frequently asked questions
Do service accounts count as Named User Plus?
No. A Named User Plus is an individual authorised to use the program, or an operated device. Service, schema, batch, integration, and monitoring accounts are technical accounts, not human users, and should be excluded from the count. A raw account list hands Oracle all of them, so classifying accounts before submission is essential.
What is the Named User Plus per processor minimum?
Oracle sets a minimum number of Named User Plus licences per processor for many programs, so the licensable figure is the higher of the actual authorised users and the minimum multiplied by the processor count. The exact minimum varies by program, and it must be applied against the correct processor count after the core factor.
Does multiplexing reduce Named User Plus counts?
No. Where a middle tier or front end pools many users behind a few database connections, Oracle counts the human users, not the connections. Assuming multiplexing reduces the count leads to undercounting. Honest Named User Plus counting includes genuine end users behind any pooling layer while excluding technical accounts.