Oracle EBS Batch & Integration User Licensing

What counts as a batch or integration user?

Every E-Business Suite estate runs work that no person initiates in real time. Concurrent programs post journals overnight, interfaces pull orders from a web storefront, middleware writes supplier records into Payables, and scheduled jobs reconcile subledgers before the books close. All of this runs under accounts, and under Oracle's licence definitions an account that operates the programs is a user whether or not a human sits behind it. The contract language is explicit on this point: a user is an individual or a non human operated device authorised to use the programs. The non human operated device is the phrase that pulls service and integration accounts into scope.

This is where many estates carry hidden exposure. The teams that manage these accounts think of them as plumbing, not as licensable users, and they proliferate without governance. A new interface is built, a generic account is created to run it, and it is never reviewed again. When Oracle's measurement scripts run, every one of those accounts surfaces in the same count as the human population, because the query that produces the Application User count does not distinguish a person from a process. The starting point for control is therefore an inventory of every non human account and a deliberate decision about how each one is licensed. The EBS licensing pillar sets out where this fits in the wider metric picture.

Does multiplexing change the count?

The single most important principle for integration accounts is multiplexing. Oracle's standard position, stated in its licensing policy documents, is that licensing is required at the point where humans interact with the application, regardless of how many tiers of hardware or software sit between the person and the licensed program. Pooling a thousand web customers behind one integration account does not convert a thousand users into one. If those customers are named individuals whose activity originates the data flowing into EBS, they are the licensable population, and the integration account is merely the conduit.

The practical consequence is that the licensing question for any integration is not how many accounts run it but who, ultimately, the data belongs to. An interface carrying machine generated telemetry with no human originator is a different case from an interface carrying orders placed by named buyers. The first points to a single licensable integration account; the second points to the human population behind it. Getting this distinction wrong in either direction is expensive, which is why the classification has to be made on the facts of each interface rather than on a blanket rule.

Concurrent managers and scheduled jobs

The concurrent manager is the EBS engine that queues and runs background work. The manager itself is infrastructure and is not a user. What matters for licensing is the accounts that submit and own concurrent requests. In a well governed estate, system jobs run under a small number of dedicated scheduling accounts that exist only to execute work the application generates. Those accounts are defensible as a contained, documented set. The problem arises when human users submit heavy batch work under shared generic logins, because the shared login then looks, to Oracle's query, like a single user doing the work of many.

The discipline is to separate genuine machine accounts from shared human logins masquerading as machine accounts. A shared login that thirty analysts use to submit reports is not a service account; it is thirty users hiding behind one record, and an auditor who establishes that fact will count thirty. Resolving these before a measurement, rather than during one, keeps the position clean.

Interface and integration accounts

Modern EBS estates rarely stand alone. They exchange data with middleware, with cloud applications, with bank gateways, with tax engines, and with bespoke front ends. Each connection runs under an account, and each account is a licensing decision. The questions to ask are consistent: what data crosses this interface, who originates it, and is that originating population already licensed for the modules the data touches. Where the originators are internal employees already counted as Application Users, the interface adds nothing new. Where the originators are an unlicensed population, such as external partners using a portal, the interface is the visible edge of a licensing requirement that has to be sized.

This is closely related to indirect access, a theme that runs through several Oracle product lines and is handled in depth alongside custom application licensing, where bespoke front ends reading EBS data create their own user populations. The same logic also touches the database layer, because an interface that reads EBS tables directly may pull the restricted use database entitlement into scope, a boundary covered in the restricted use database article.

How to classify non human accounts

The defensible method is a register. Every non human account is listed with its name, owner, purpose, the modules it can reach, the data it carries, and the licensable basis you have assigned. For each account the register records one of three determinations: a single service user that is licensed in its own right, a conduit for a human population that is licensed separately, or an account that should be retired because it duplicates access already provided. This register is the artefact you present in an audit, and it converts a vague exposure into a documented position the auditor must engage with on your terms.

The work pays off twice. It prevents over counting, where Oracle's default query treats every generic login as a named individual, and it prevents under counting, where genuine programmatic access to licensed modules is quietly omitted and surfaces later as a finding with penalty pressure. Building the register is part of establishing a standing EBS licence position baseline, and where an interface population turns out to be larger than the entitlement supports, the applications licensing practice can structure the remediation before it becomes a claim.

The buyer side view

Batch and integration accounts are the part of the EBS estate most likely to be ignored until an audit forces attention, and that neglect is precisely what makes them dangerous. Oracle's measurement does not care that an account is a process; it counts what it sees. The buyer side discipline is to inventory every non human account, decide its licensing treatment deliberately, document the decision, and retire what is redundant. Done proactively, the integration layer becomes a controlled, explainable part of the position. Left unmanaged, it is a reservoir of findings waiting for a measurement to expose them.

The same principle that governs human users governs machine ones: authorisation, not intention, drives the count, and only deliberate documentation converts a default query result into a defensible position. If your estate carries undocumented service and integration accounts, the time to classify them is before Oracle does. To scope a review of non human account exposure, or to prepare for a live measurement, engage audit defence or request a consultation.

Cloud integrations and the API economy

The integration surface of a modern EBS estate has grown far beyond the overnight batch jobs of a decade ago. REST and SOAP services, integration platforms such as Oracle Integration Cloud, robotic process automation bots, and low code connectors all reach into EBS, and each runs under an account that Oracle's measurement will see. The volume and the variety make governance harder, because new integrations are stood up by project teams who think in terms of endpoints, not licences, and a generic account is created for each one without a licensing review. Over a few years an estate can accumulate dozens of integration identities, none of them documented, every one of them visible to an auditor.

The licensing principle does not change because the technology is newer; multiplexing still applies, and the question is still who originates the data crossing each interface. A robotic process automation bot that automates the work of named employees does not reduce the licence requirement for those employees, because the bot is acting on their behalf and the multiplexing rule looks through it to the humans behind it. An API that serves an external partner population is the visible edge of a licensing requirement for that population. The newer the integration pattern, the more important it is to apply the old principle deliberately, because the technology invites the assumption that an automated process is somehow outside the licence model. It is not.

The control is to extend the non human account register to cover every integration identity, including the ephemeral ones that modern platforms create dynamically. Where a platform pools many human users behind a single technical account, the register records the human population as the licensable unit. Where it carries genuinely machine generated data, the register records the integration account as a contained service user. The same register that governs concurrent managers and overnight interfaces must reach the API layer, or the API layer becomes the part of the estate where exposure accumulates unseen.

What an auditor asks about non human accounts

When Oracle's License Management Services team examines an EBS estate, the non human accounts are a standard line of enquiry, and knowing the questions in advance is how you prepare for them. The auditor will produce the full list of active accounts with responsibilities reaching licensed modules, and will not pre filter out service and integration accounts; that filtering is your job, and the burden of explaining each account falls on you. An account you cannot explain is an account the auditor counts as a user.

The lesson is that the register is not an internal nicety; it is the evidence pack for the audit. Each account that carries a clear purpose, a documented data source, and an explicit licensing basis is an account the auditor must accept on your terms rather than count on theirs. The accounts that are dangerous are precisely the ones nobody can explain, which is why building the register before a measurement, as part of the standing licence position baseline, converts the most ambiguous part of the estate into the most documented.