Counting Non-Human Named Users: Batch Jobs, Sensors, and Automated Devices

Oracle's Named User Plus metric counts machines as well as people, and in a well-integrated estate the device count can exceed the human count by an order of magnitude. This guide draws the line between a device your licensed staff operate and a device Oracle counts on its own, and tells you exactly where the exposure and the leverage sit.

The rule most buyers miss: NUP counts devices, not just people

Read the Named User Plus definition in your Oracle License and Services Agreement literally, because Oracle's auditors will. The contract states that "a non human operated device will be counted as a named user plus in addition to all individuals authorized to use the programs, if such devices can access the programs." That single clause is the reason a plant with 20 operators and 100 sensors does not need 20 NUP licenses. It needs 120.

The metric measures authorization, not activity. It does not matter whether a sensor writes once a day or ten thousand times a second, whether sessions are concurrent, or whether a batch job runs at 2am while nobody is watching. If the device or process can access the Oracle program, it consumes a license. In 25 years of counting these estates I have never seen a client lose an audit argument on frequency of access, because frequency is simply not the test. Authorization is. This is the opposite of most SaaS metrics, and it is where estates built by engineers who assume "per user means per person" quietly go non-compliant.

The test is not how often the machine talks to the database. The test is whether it is authorized to. A sensor that connects once a day counts exactly the same as a person who logs in all day.

For the counting mechanics and the per-processor floor that interacts with all of this, read the pillar on Named User Plus counting rules, per-processor minimums, and audit traps alongside this page. Device counting is where the abstract counting rules turn into real money.

Operated device versus independently counted device: the line that matters

Here is the distinction that decides most disputes. Oracle's own materials recognize an exception: where a non-human process is directly operated by a licensed named user, that activity is covered by the operating person's license. If a DBA runs a script that performs database operations, those operations sit under the DBA's NUP entitlement, because a licensed human is operating the tool. Likewise, if a warehouse worker scans a barcode, you count the worker, not the scanner in their hand. The device is an extension of a licensed person.

The exception collapses the moment the process runs independently of any human session. Scheduled batch jobs, system agents, integration middleware, monitoring tools, and service or integration accounts each require their own NUP license when they access Oracle directly. There is no human operating them at run time, so there is no license to shelter under. The line is simple to state and easy to get wrong in practice: "operated by a licensed human at run time" is covered; "runs autonomously" is counted.

The reason this matters for exposure is that Oracle's LMS audit scripts do not care about your intent. They enumerate every connection account, including system and service accounts, and Oracle's default position is that each one requires a NUP license unless you can prove it is operated by an already-licensed human. The burden of proof is yours. If you cannot tie a service account to a specific licensed individual, expect Oracle to count it.

The batch-processing carve-out, and why it is narrower than people think

There is a genuine carve-out, and it is one of the most misunderstood clauses in the agreement. Oracle contractually permits "automated batching of data from computer to computer." In plain terms, if you hold data in one relational database and batch it into an Oracle data warehouse, the users of the first database do not automatically become named users of the warehouse. The upstream population does not flow through the pipe and land on the destination license.

Computer-to-computer batching between databases does not multiply your named users onto the destination. A device physically importing or exporting files does. That one word, "physically," is the whole argument.

The carve-out is narrow, and the trap sits at its edge. Oracle's guidance on data transfer environments is explicit: where you license by Named User Plus, "the users or devices that are performing the import/export of flat files are considered actual users and need to be licensed." So a clean database-to-database batch is protected, but the moment a specific device or process performs a flat-file import or export against the Oracle system, that device or process is an actual user and must be counted. Do not read the batching permission as a blanket exemption for every automated pipeline. It exempts pass-through data movement between systems, not the machines that touch the Oracle instance directly.

In practice I advise clients to document, per interface, whether data crosses computer to computer (carve-out likely applies) or whether a named process or device performs an explicit import/export against Oracle (it must be licensed). Build that map before an audit, not during one.

Multiplexing will not shrink the count

Architects reach for a middle tier to reduce the count. It does not work, and the contract says so. The multiplexing rule requires that "if multiplexing hardware or software (e.g., a TP monitor or a web server product) is used, this number must be measured at the multiplexing front end." Oracle's position is blunt: multiplexing reduces the number of devices or users directly touching the database, but it does not reduce the license requirement. You count the population in front of the pooling layer, not the handful of pooled connections behind it.

This matters enormously for IoT and industrial estates, because a device gateway or message broker looks, to a network diagram, like it collapses 5,000 sensors into three connections. It does not collapse anything for licensing. You still count the sensors at the front end. For the full mechanics and the failure modes, see why a middle tier does not shrink your named user count. Treating an IoT gateway as a multiplexing device that hides sensors is one of the most expensive assumptions in the estate.

Where the IoT and industrial estate quietly balloons

The classic worked example makes the scale obvious: 20 human users plus 100 heat sensors accessing the same Oracle database produces 120 required NUP licenses, not 20. A warehouse scanner that writes autonomously, or an IoT sensor feeding telemetry, counts as one named user each. In a well-integrated enterprise the non-human device count can exceed the human user count significantly, and it does so without anyone raising a flag, because nobody thinks of a temperature probe as a database user.

Now layer in Oracle's per-processor minimum and the arithmetic turns hostile. On the Technology Global Price List effective April 16, 2026, Oracle Database Enterprise Edition lists at $47,500 per Processor and $950 per Named User Plus, with a floor of 25 NUP per processor. A 16-core x86 server (0.5 core factor) therefore carries a minimum of 16 x 0.5 x 25 = 200 NUP at list, which is $190,000, regardless of whether your real population is 50 or 500. If your device estate pushes the true count above the floor, you pay for every device above it. If it sits below the floor, the floor still bites.

Two consequences follow. First, at $950 NUP versus $47,500 Processor, Oracle prices NUP at exactly one fiftieth of Processor on the Database line, so the crossover is always 50 real users (or devices) per Processor, floors permitting. Once your enumerated device-plus-human population crosses roughly 50 per processor, Processor licensing is cheaper and removes the counting burden entirely. Model this before you commit, using the Named User Plus versus Processor metric decision guide. Second, the per-processor minimum can make NUP the wrong metric even when your population looks small, which is exactly the scenario worked through in the 25 NUP-per-processor minimum with worked server examples.

Audit exposure: where Oracle looks and how much it costs

Auditors target this gap deliberately. Oracle's definition covers automated devices accessing the database, and that is precisely why batch interfaces and IoT feeds break Named User Plus counts. LMS scripts surface every connection account, and the default assumption is that each undocumented service account, integration account, and device connection is an unlicensed named user. Organizations found non-compliant in Oracle audits face average exposures that industry ITAM guides put in excess of $79 million for large estates, and while your number will vary, the direction is not friendly.

The critical strategic point is that NUP is only defensible where the population is enumerable. NUP is appropriate for internal-facing systems with a finite, knowable set of people and devices. The moment you cannot enumerate the connecting population (an external or web-facing application, or an uncapped device fleet), Oracle can, at least in theory, demand NUP licenses for everyone and everything that could access the system. For those populations, Processor licensing is the safer play, and Oracle itself does not permit NUP on genuinely internet-facing systems. If any part of your estate is web-facing, read why Oracle will not let you use Named User Plus on internet-facing systems before you rely on a device count.

NUP works only where you can name every connecting device. If you cannot enumerate the fleet, Oracle counts everything that could connect, and Processor licensing becomes the cheaper certainty.

What to do before your next audit or true-up

Treat the device estate as a first-class part of your compliance position, not a footnote. The moves below are the ones that hold up when Oracle's scripts run.

• Inventory every connection account and map each to either a licensed human operator (covered) or an autonomous process (counted). Undocumented accounts default to counted, so document them now.
• Classify each interface as computer-to-computer batching (carve-out likely applies) or as a device performing explicit import/export against Oracle (must be licensed). Keep the evidence per interface.
• Count the population at the multiplexing front end, including every sensor and device behind any gateway, broker, or connection pool. Do not let architecture diagrams tempt you into counting pooled connections.
• Run the crossover math: total enumerated humans plus devices, divided by processors. If you are near or above 50 per processor, or if the per-processor minimum already exceeds your count, price Processor licensing as the alternative.
• Build a defensible, reconciled named user list before Oracle asks for one, using the approach in building a named user list Oracle auditors accept.
• Remember discounting leverage: 2026 figures above are list. Market experience puts typical negotiated Database discounts at 40 to 70 percent, so any metric decision should be modeled at your expected net price, not at list.

The strategic conclusion is straightforward. In estates with heavy automation, the device count is the risk, and the metric choice is the leverage. Enumerate honestly, apply the operated-versus-autonomous line rigorously, and if the enumerated population is large or unbounded, move to Processor licensing where the counting problem disappears. Do the math before Oracle does it for you.

Related advisory: the full topic guide.

Frequently asked questions

Does an IoT sensor really count as an Oracle named user?

Yes, if it accesses the Oracle database without a human operating it at run time. Oracle's NUP definition counts each non-human operated device that can access the program, so a sensor writing telemetry counts as one NUP each. A worked example puts 20 humans plus 100 sensors at 120 required licenses, not 20.

When is a device covered by an existing person's license instead of counted separately?

When a licensed named user directly operates it at run time. A barcode scanner used by a licensed warehouse worker is covered by that worker's license, and a script a DBA runs interactively is covered by the DBA's NUP. The exception fails the moment the process runs autonomously, such as a scheduled batch job or an integration service account.

Do batch jobs need their own Named User Plus license?

An autonomous scheduled batch job that connects to Oracle without a human at run time needs its own NUP. Pure computer-to-computer data batching between databases is a permitted carve-out and does not push the source database's users onto the destination. But a device or process that physically performs a flat-file import or export against Oracle is treated as an actual user and must be licensed.

Can an IoT gateway or middle tier reduce my device count?

No. Oracle's multiplexing rule requires you to count users and devices at the front end, in front of any pooling layer. A gateway that collapses 5,000 sensors into three pooled connections does not reduce the license requirement; you still count the 5,000 sensors.

At what point should I switch from NUP to Processor licensing for a device-heavy estate?

Oracle prices NUP at one fiftieth of Processor on the Database line, so the crossover is roughly 50 real users or devices per processor, floors permitting. Above that, or where the 25 NUP per processor minimum already exceeds your count, Processor licensing is usually cheaper and removes the device-counting burden entirely.

How much is at stake if my device count is wrong in an audit?

On the April 16, 2026 price list, NUP lists at $950 each, so an undercount of a few hundred devices runs into hundreds of thousands of dollars at list before support. Industry ITAM guides put average large-estate non-compliance exposures above $79 million, and Oracle's LMS scripts surface every connection account, so undocumented device connections default to counted against you.