Named User Plus looks like the friendly metric. You count the people who touch the database, you buy a licence for each, and the bill scales with the team. That intuition is where the trouble starts. Named User Plus carries a minimum tied to hardware, not to people, and that minimum is one of the quiet ways an Oracle finding grows from a number you recognise into one you do not. Understanding how the minimum is counted is the difference between conceding it and defending it.
What is the Named User Plus minimum for Enterprise Edition?
The Named User Plus minimum for Oracle Enterprise Edition is 25 licences per processor, where a processor is counted with the core factor table rather than as a physical socket. The metric exists so that Oracle is paid for the capacity available to users, not only for the users an organisation happens to declare. A server with substantial core count therefore carries a floor that can sit well above the actual number of named individuals, and the licensed quantity is always the greater of the two.
That single word, greater, is the whole mechanic. You do not get to choose the more favourable basis. If the user count is higher, you license users. If the per processor minimum is higher, you license the minimum. Most undercount findings are simply Oracle pointing out that the second number was the one that applied and was never bought.
How does Oracle count the minimum in an audit?
Oracle counts the minimum by taking every processor that runs the licensed program, applying the core factor for that chip, and multiplying the result by 25. The processor figure comes from cores multiplied by the core factor, so a sixteen core server on a 0.5 factor counts as eight processors, and the minimum for that server alone is 200 Named User Plus licences. Set that against a declared user count of, say, 60, and the finding writes itself: the floor wins, and the gap is the exposure.
The arithmetic is mechanical, but each input is contestable. The number of processors depends on which cores genuinely run the program, the core factor depends on the exact processor model in the core factor table, and the program boundary depends on what the contract actually licensed. A wrong core factor or an over broad server list inflates the floor before a single user is counted, and correcting those inputs is the first place a defence finds room.
A team of 40 developers runs Enterprise Edition on a two server cluster, each server holding sixteen cores at a 0.5 core factor. That is eight processors per server, sixteen across the pair, and a minimum of 400 Named User Plus licences. The declared user count of 40 is irrelevant once the floor is computed. The opening finding values the 360 licence gap at list price. A review then shows the second server was a passive standby covered by the contract's failover terms, halving the processor base and cutting the gap to 160 before any further argument.
Where do NUP minimums bite hardest?
NUP minimums bite hardest where small user populations meet large or modern hardware, because core counts have grown far faster than team sizes. A development group, a reporting database, a departmental application, each may have a handful of real users sitting on servers built for headroom. The metric that felt cheap when the team was the cost driver becomes expensive the moment the processor floor overtakes the people. The same effect appears after a hardware refresh, when a like for like migration onto denser chips silently raises the minimum even though nothing about the workload changed.
Disaster recovery is another pressure point. Standby and failover servers can be drawn into the processor base if their licensing position is not handled with care, and the 10 day rule and the contract's failover language decide whether they count. Treating every server in the estate as live capacity is how a defensible position turns into an inflated one. The counting question and the contract question have to be answered together.
How do you defend a Named User Plus undercount?
You defend a Named User Plus undercount by attacking the inputs to the floor before you accept the floor itself, because the minimum is only as large as the processor count and core factor that feed it. Confirm exactly which servers run the program and remove any that do not. Verify the core factor against the published table for the precise processor model. Apply the contract's failover and disaster recovery terms to standby hardware rather than assuming it counts. Then, and only then, compare the corrected floor with a clean, deduplicated user count.
An independent line by line review of Oracle findings typically cuts a claim 60 to 80 percent, and undercount findings are fertile ground for that reduction precisely because the floor compounds every input error. Get the processor base and the core factor right and the minimum often falls below the user count, at which point the finding disappears. To go deeper on the counting itself, see counting Named User Plus correctly and processor versus Named User Plus. The full method sits in the Oracle database licensing guide.