Oracle EBS Read Only & Reporting User Licensing

Why read only is not free by default

The most persistent misconception in EBS licensing is that read only users are free, or at least cheaper, than full users. They are not, under the standard metric. The Application User is defined as an individual authorised to use the programs, and that definition makes no distinction between a user who posts transactions and one who only views them. Both are authorised, both reach the licensed module through a responsibility, and both are counted. The depth of use is irrelevant; the existence of authorisation is everything. A reporting analyst who never changes a record but holds a responsibility reaching General Ledger is a full General Ledger Application User.

This catches organisations out because their mental model of value does not match Oracle's model of authorisation. Intuitively, someone who only looks at data seems to consume less and should cost less. But the metric does not measure consumption; it measures permission, as explained in the Application User article and the EBS licensing pillar. The result is that large inquiry populations, granted access casually because read only access feels harmless, generate exactly the same counts as transactional populations and frequently dominate an inflated position.

Reporting tools and the data boundary

Reporting is where the read only question becomes genuinely intricate, because there are two distinct ways to report against EBS data and they engage different licences. The first is reporting through EBS itself, using a responsibility that reaches a module to run inquiries and standard reports. This is unambiguously Application User access and counts as such. The second is reporting through an external tool that reads the EBS database directly, bypassing the application layer. This does not engage the Application User metric at all; instead it engages the database licence and the restricted use boundary, because querying the EBS tables directly is database use.

The distinction matters enormously for cost. Direct database reporting that exceeds the restricted use grant bundled with EBS pulls full database licensing into scope, potentially at the Named User Plus processor minimum, which can be far more expensive than the application users it was meant to avoid. This is the boundary set out in the comparison of Named User Plus and Application User, and it means a decision to serve reporting outside EBS to dodge user counts can inadvertently create a larger database exposure. The reporting architecture is therefore a licensing decision, not just a technical one.

When a lighter metric applies

A reduced arrangement for read only or limited access exists only where the contract explicitly provides one. Oracle has, in various agreements, defined self service users, employee users, or other limited use categories that carry lighter terms than the full Application User, and some negotiated contracts include specific inquiry or read only rights. But none of these apply by default. The existence of a lighter category is a function of what was negotiated, and the only way to know whether your inquiry population can sit under a reduced arrangement is to read the contract definitions that govern your estate.

Where a lighter category does exist, the boundary between it and full access is policed by Oracle in an audit, so the classification must be defensible. A user nominally categorised as read only but holding a responsibility that permits updates will be reclassified as a full user, with the difference treated as a finding. The classification has to match the technical reality of what the responsibility permits, which connects directly to the self service boundary developed in the self service user licensing article.

How to manage inquiry populations

The management discipline for read only users is the same least privilege approach that governs the rest of EBS, with one addition: question whether the access belongs in EBS at all. First, ensure inquiry responsibilities reach only the modules genuinely needed, because an inquiry responsibility that spans three modules counts the user in three. Second, confirm that read only really is read only at the responsibility level, so the classification is defensible. Third, evaluate whether large reporting populations would be better served from a separate analytics layer or warehouse, weighing the EBS users removed against the platform and database licensing introduced.

That third decision is the strategic one. Moving a thousand casual reporting users out of EBS responsibilities and onto a warehouse fed from EBS can remove a thousand Application Users from the count, but it introduces licensing for the warehouse platform and, if the warehouse reads EBS directly, for the database access that feeds it. The saving is real only if it is assessed net, which is the kind of architecture aware reconciliation the applications licensing practice performs. Where an audit is already questioning a read only population, audit defence manages the classification dispute.

The buyer side view

Read only access is the quiet inflator of EBS positions, because it is granted freely on the false assumption that it is free. Under the standard Application User metric it is not free; it is a full user count, and large inquiry populations authorised through broad responsibilities can dominate the bill. The buyer side discipline is to treat read only users with the same least privilege rigour as transactional ones, to verify that any lighter classification is genuinely supported by the contract and the responsibility configuration, and to think hard about whether heavy reporting populations belong inside EBS at all.

The deeper point is that the reporting architecture is a licensing decision. Where reporting is served, through EBS responsibilities, through direct database queries, or through a separate warehouse, determines which metric applies and how much it costs, and the cheapest looking option can carry the most expensive boundary. To right size an EBS read only and reporting population, and to choose a reporting architecture that minimises the net licence cost, request a consultation.

BI Publisher, Discoverer and reporting access

The reporting tools that surround EBS each engage licensing differently, and conflating them is a common source of error. BI Publisher embedded in EBS, used to render reports through EBS responsibilities, generally falls within the application access model: the user running the report through a responsibility that reaches a licensed module is an Application User of that module. The legacy Discoverer and other tools that connect to the EBS database to extract data are a different matter, because they may read the database directly and therefore engage the database licence and the restricted use boundary rather than the application metric.

The decisive variable is whether the tool reaches the data through the application or around it. A reporting layer that goes through EBS responsibilities counts users on the application metric, which is controllable through least privilege. A reporting layer that connects to the database directly counts against the database, where the restricted use grant limits what is permitted and the Named User Plus minimum can make the exposure large. The same business requirement, a population that needs to see EBS data, has a completely different cost depending on which path the architecture takes, which is why the reporting tool decision is a licensing decision.

This is the practical edge of the two layer structure set out in the Named User Plus versus Application User comparison. A team trying to economise by moving reporting off EBS responsibilities and onto a direct database tool can walk straight into a larger database claim, because they have moved the population from the controllable application metric to the floor bound database metric. The cheaper looking architecture is sometimes the more expensive one, and only a net assessment reveals which.

Building a defensible read only classification

Where a contract does provide a lighter category for limited or self service access, the value of that category depends entirely on whether your classification of users into it is defensible. An auditor will test the classification against the technical reality, and a user labelled read only whose responsibility in fact permits updates will be reclassified to full, with the gap treated as a finding. A defensible classification therefore rests on the responsibility configuration, not on a label applied in a spreadsheet, and the two must match exactly.

Building the classification means auditing each responsibility assigned to a nominally read only population and confirming that it genuinely permits only inquiry, with no update or transactional functions reachable through any menu it exposes. Where a responsibility grants more than inquiry, either the user is reclassified to full or the responsibility is trimmed to genuine read only, restoring the match between label and reality. This is painstaking work, but it is what converts a contractual lighter category from a hopeful label into a position that survives a measurement.

The classification should then be documented in the baseline alongside the responsibility evidence that supports it, so that the read only population is defended by configuration facts rather than by assertion. Done this way, a lighter category genuinely reduces the count; done carelessly, it is a finding waiting to happen. Where an audit is already challenging a read only population, audit defence manages the reclassification dispute on the strength of that documented configuration.