Building a Defensible Named User List: The Reconciliation Oracle Auditors Accept

Oracle's opening named user count is almost always built from raw account extracts that nobody deduplicated, and roughly seven in ten defended audits are inflated at the data stage rather than the pricing stage. This is the reconciliation method that produces a roster Oracle's GLAS team can test and cannot dismiss, plus the arithmetic that tells you when deduplication is worth the effort at all.

Why Oracle's Count Is Wrong Before Anyone Talks About Price

The single most expensive mistake buyers make in an Oracle Named User Plus dispute is treating the opening number as a given and spending their energy on the discount. It is not a given. In our audit-defense practice the pattern is consistent with the published finding that in roughly 7 of 10 defended audits the claim was inflated at the data stage rather than the pricing stage, and the arithmetic that follows is brutal: a 40 percent discount on a 50 percent overstated claim still leaves you paying for licenses you do not owe. Run it. A claim of 4,000 NUP on Enterprise Edition at $950 list is $3.8m. Negotiate a 60 percent discount and you sign for $1.52m. Establish first that only 2,400 users were ever authorized, then take the same 60 percent, and you sign for $912,000. The discount conversation moved nothing. The reconciliation moved $608,000, and it moved the annual support base with it, because 22 percent support attaches to whatever license quantity you agreed to, forever.

The mechanics of the overstatement are mundane and repeatable. GLAS runs its measurement scripts, asks for a directory extract, and receives whatever the DBA and the AD administrator can produce quickly: a DBA_USERS dump, an AD group export, sometimes an application user table. Nobody deduplicates. The result is a gross account count containing disabled accounts that were never removed, orphaned service IDs left behind by decommissioned interfaces, generic schema owners, test and clone accounts, leavers still sitting in a security group, and the same human being appearing under five identities across five directories because they moved departments twice and once worked for a subsidiary. Oracle does not owe you the cleanup. Under the agreement, the burden of proving the authorized population sits with the customer, so an uncontested gross extract becomes the baseline claim.

Then the multiplier bites. Every duplicated human on Enterprise Edition costs $950 at list plus $209 in annual support, and that is only the database line. If Partitioning, RAC, Advanced Security, and Diagnostics Pack are licensed on the same database, the counts must match the database, so one duplicate propagates across every option and pack on the box. Four hundred duplicates on a database carrying four options is not a $380,000 problem, it is closer to a $1.5m problem at list before support, as our note on why options and packs must match the database user count sets out in detail. Fix the roster before you argue about price, or you will discount a number that was never real.

A 40 percent discount on a 50 percent overstated claim still leaves you paying for licenses you do not owe.

The Contract Test: Authorization, Not Activity

Before you build anything, fix the definition you are building to, because most buyer-side rosters fail on the wrong test. Oracle's standard License Definitions and Rules define a Named User Plus as "an individual authorized by you to use the programs... regardless of whether the individual is actively using the programs." The same text adds that a non-human operated device is counted as a NUP in addition to all authorized individuals if it can access the programs. Read those two sentences literally, because GLAS will. Activity is not the metric. A login report showing zero connections for 18 months does not remove anyone from the count, and neither does a disabled AD account, unless authorization itself was withdrawn. Disabling is an operational state that IT can reverse in 30 seconds; authorization is a permission the customer granted and must be shown to have revoked.

The practical consequence is that your defensible reduction is not an activity report, it is a documented deauthorization event with a date. That means an approved access-removal ticket, a leaver record, a security-group removal with a timestamp, or a formal policy statement that role X is no longer entitled to the environment, each tied to a named individual. In 25 years of these arguments, activity reports get argued and deauthorization records get accepted, because one is an inference and the other is evidence. Where a user was authorized for part of the period, date the record; Oracle counts the population at the point of measurement, not the peak of the year.

Two further lines decide most of the remaining disputes. The multiplexing clause requires that the count be measured at the multiplexing front end, so a middle tier, portal, or web server does not compress 3,000 downstream users into 12 pooled database sessions. See the detail in our analysis of why a middle tier does not shrink your named user count. The next sentence, however, is yours: "Automated batching of data from computer to computer is permitted." That single line is the strongest defense available for file-based interfaces, ETL feeds, and scheduled extracts, and it is why the distinction between a permitted batch transfer and a countable device matters so much in the treatment of non-human named users such as batch jobs and sensors. Decide, in writing, which of your service accounts sits on which side of that sentence before Oracle decides for you.

Run the Floor Math First: When Deduplication Buys Nothing

Before anyone opens a spreadsheet or requests an HR extract, calculate the per-processor floor. Enterprise Edition requires a minimum of 25 Named User Plus per Processor, and that Processor count is derived from hardware through the Core Factor Table, not from your headcount. If your true, deduplicated population sits below the floor, every hour spent reconciling identities produces exactly zero dollars of savings. I have watched clients burn six weeks and a consulting budget cleaning a roster that was always going to price at the minimum. Triage first: compute Processor equivalents for every server hosting an Oracle Database, multiply by 25, and compare that number to your rough account count. Only the gap above the floor is worth chasing. Below it, your effort belongs in hardware scoping and Core Factor arguments instead, which is where the 25 NUP-per-processor minimum with worked server examples does the real work.

The arithmetic is unforgiving in both directions. Take 30 users plus 5 service accounts, 35 actual named users, running on eight Intel cores. At the 0.5 core factor that is 4 Processor equivalents, so the floor is 100 NUP, or $95,000 at the August 2026 list price of $950 per NUP. Deduplicating those 35 down to 28 changes nothing. Now scale the hardware: 2 x 16-core Intel Xeon gives 16 Processor licenses and a 400 NUP minimum, and above 400 real users every duplicate you remove is $950 of pure cash, multiplied again across every option pack that must match the database. The third case matters most. If your true count approaches 50 users per Processor, you are at the crossover, because NUP prices at exactly one-fiftieth of the $47,500 Processor price. Model both metrics before you concede a count.

The Four-Source Reconciliation: HR, AD, Database, and Application

A roster Oracle's GLAS team will accept is a join, not a list. Four sources, in sequence, each with a defined role. The HR master is the identity spine: it is the only system that authoritatively states whether a human exists, is employed, and on what date they left. Active Directory or your IdP is the authorization layer, and authorization is the contractual test, since a Named User Plus is an individual authorized to use the programs regardless of whether they are actively using them. DBA_USERS and application account tables are the technical layer, evidencing what actually exists in the estate. Entitlement records (ordering documents, CSI reports) are the ceiling, not a source of truth about people. Build the join in that order and every disputed record has a lineage. Build it the other way, starting from DBA_USERS, and you have produced the same inflated extract Oracle already has.

Match keys run in strict priority: employee ID first, corporate email second, sAMAccountName third, and fuzzy name matching last, always flagged for manual review and never accepted silently. Then every record carries a disposition code (matched-active, matched-terminated, contractor-verified, service-account, orphan-unmatched, duplicate-of-record-X, out-of-scope) with a named owner and an evidence reference. That is the difference between an auditable roster and an assertion. Four breakages recur in nearly every engagement I have run: contractors with no HR record, shared functional logins that Oracle will treat as a virtual user each, leavers whose application account was never disabled, and the senior DBA holding a personal ID, an admin ID, and a break-glass emergency ID that Oracle happily counts three times. Note that the front-end rule still applies to humans behind middleware, so consult the multiplexing front-end rule on user counting before you assume an application server shrinks anything.

Build the join from DBA_USERS instead of HR and you have simply reproduced the inflated extract Oracle already has.

Contractors, Service Accounts, and the Records That Prove Them

Three categories carry almost all the argument in a Named User Plus reconciliation, and Oracle knows exactly which ones they are. Contractors, agency staff on pooled logins, and service accounts are where GLAS builds its inflation, because these are the populations where your HR system has no record, your AD tenant has stale objects, and your application team cannot immediately explain what a login does. The contract test is authorization, not activity, so an expired contractor whose account was never disabled is still arguable as authorized unless you can produce the record that removed the authorization. That record is the contract end date paired with the offboarding ticket, ideally with the AD disable timestamp attached. Two of the three, on their own, get challenged. All three together do not.

Pooled agency logins are the more expensive misunderstanding, and it usually runs in your favor at first glance and against you on inspection. Oracle counts the number of individuals authorized to use the programs, not the number of credentials issued. Five staff from a managed service provider sharing one login is five Named Users, not one, and any attempt to argue the credential count is the user count invites Oracle to widen the scope. Argue it honestly, price it into your model, and reclaim the leverage elsewhere. For a fuller treatment of external populations, see our guidance on counting external contractors in Primavera and Aconex deployments.

Service accounts split into two legally distinct groups. Genuine automated batching of data from computer to computer is permitted under Oracle's own multiplexing sentence and is defensible. Robotic process automation bots and emulated human users are not: under the Applications rule, each emulated human user and non human operated device is counted as a virtual user for NUP purposes. Get the classification wrong in Oracle's favor by accident and you will pay for it six times over once the option stack multiplies.

• Owner: a named individual, not a team mailbox, who can answer questions under audit conditions.
• Purpose: what the account does, in one sentence, in business terms.
• Upstream trigger: scheduler, message queue, file drop, or human click, stated explicitly.
• Interactive capability: whether a human can log in with the credential and run queries, which is the single question that decides the batching defense.
• Change record: the ticket or CMDB entry showing when the account was created and by whom, which is what turns your classification from assertion into evidence.

Making the Roster Survive GLAS Scrutiny

A number is what your SAM tool exports. A defensible number is a number an Oracle auditor can attempt to reproduce, fail to disprove, and eventually accept. The difference is five pieces of discipline. Version control on the roster file, so nobody negotiates against an outdated copy. An as-of date matched precisely to Oracle's measurement date, because a roster dated three months after their extract is a gift to their argument. A reproducible extract script per source, so that when GLAS asks how you got 4,180 from AD, you rerun it in front of them. A written deduplication rule set, published before you run it, covering identity matching, orphan handling, and the contractor and service account classifications above. And the reconciliation bridge.

The bridge is the negotiating document, not the roster. It walks line by line from Oracle's gross figure to your net figure, with every deduction categorized and evidenced: terminated employees with HR dates, duplicate identities with matching keys, non-interactive batch accounts with change records, test and training accounts with environment tags. Presented this way, Oracle cannot attack the total. They have to attack a named category with named evidence, and in our experience across defended audits the categories that survive first challenge are the ones with three independent sources behind them.

One further reason to close every duplicate before you argue price: option and pack counts must match the associated database. RAC, Partitioning, Diagnostics Pack, Advanced Security and the rest all inherit the same user count, so a single unresolved duplicate does not cost you one license, it costs you one across six SKUs, each with its own 22 percent support tail. Read why your Partitioning NUP cannot be lower than your database NUP before you agree any number in writing. Resolve duplicates first, then negotiate. Never the reverse.

Timing, Leverage, and What to Do First

The Master Agreement gives you 45 days to respond to an audit notice, but Global License Advisory Services typically telephones within days of the letter to manufacture urgency and to start the conversation before your data exists. Do not take that call as a data request. In our experience across defended Oracle files, the clock runs roughly like this: scope negotiation in weeks 2 to 4, data collection weeks 4 to 10, findings letter weeks 10 to 16, and settlement negotiation for about ten weeks after that. That sequence hands you a specific piece of leverage: the entire window before week 4 belongs to you. Run the four-source reconciliation internally, before you agree to any scope, so that a timestamped roster exists before Oracle's number does. Once GLAS publishes a count, every hour you spend afterward is spent disproving their arithmetic rather than presenting your own. The payoff is measurable. Across defended engagements we have observed reductions of 20 to 50 percent below opening exposure, with the median sitting well above the bottom of that band on files where the roster was evidenced with source extracts, HR termination dates, and contract records rather than assertions.

• Hour 0 to 24: freeze account provisioning. No new database accounts, no new application logins, no AD group changes in scope until the snapshot is taken. Moving targets destroy defensibility.
• Hour 24 to 48: snapshot all four sources with timestamps. HR active roster, AD or LDAP export, DBA_USERS per instance, and application user tables. Hash or checksum each file and log who pulled it.
• Hour 48 to 60: compute the hardware-derived floor. Cores times Core Factor equals Processor licenses, times 25 for Enterprise Edition. Use the worked per-processor minimum examples to check your arithmetic.
• Hour 60 to 72: rank databases against the floor. Only instances where actual authorized users exceed the minimum justify full reconciliation. For the rest, confirm the floor and stop, then check whether the crossover to Processor licensing already applies.

Related advisory: the full topic guide.

Frequently asked questions

Does disabling an Oracle database account remove that user from the Named User Plus count?

Not on its own. The contract counts individuals authorized to use the programs regardless of whether they are actively using them, so the test is withdrawal of authorization, not the account status flag. You need a dated deauthorization record, typically an offboarding ticket or an access revocation approval, tied to the individual. A disabled account with no revocation trail will be challenged and usually restored to the count.

How do we count contractors who share a single login in an Oracle system?

Count the individuals authorized to use that credential, not the credential itself. If eight agency staff have been given the shared password, Oracle's position is eight Named User Plus licenses, and shared logins are one of the fastest ways to inflate an audit finding. Either issue individual accounts so the population is provable, or maintain a signed access register naming exactly who holds the credential and for what dates.

Are service accounts and batch jobs always counted as named users?

No, and this is where the multiplexing clause earns its keep. The rule states that automated batching of data from computer to computer is permitted, so a genuine machine-to-machine ETL job that no human can trigger interactively is generally defensible. An RPA bot that emulates a human user, or a service account any operator can log into and run queries with, is counted, and for Oracle Applications the price list explicitly treats emulated human users and non-human devices as virtual users.

Is it worth deduplicating users if we are already at the 25 NUP per processor minimum?

Usually not for that database. The minimum is derived from hardware using the Core Factor Table, so a four-Processor-equivalent server carries a 100 NUP floor whether your real population is 35 or 95. Spend the reconciliation effort on the databases where the true count sits above the floor, because that is the only place a removed duplicate converts into a real saving of $950 plus $209 annual support at list.

Should we give Oracle our reconciled user list, or just the total?

Give a reconciliation bridge, not a bare total. Walking from Oracle's gross account figure to your net figure with each deduction categorised, quantified, and evidenced forces the auditor to attack a specific category rather than dispute the headline number. Provide the underlying personal data only to the extent your agreement and privacy obligations require, and never hand over raw HR extracts.

How much of an Oracle audit claim is typically data error rather than genuine shortfall?

In defended engagements the majority of the inflation sits in the data, with roughly seven in ten cases overstated at collection rather than at pricing. Disciplined buyers who run their own reconciliation before responding routinely settle 20 to 50 percent below Oracle's opening exposure, and files with a fully evidenced roster commonly do better than that. The reduction comes from removing licenses you never owed, not from a bigger discount.