When an audit reaches Oracle E Business Suite, most asset managers brace for a question about application users and are surprised when the larger number comes from somewhere else. EBS is an application, but it sits on an Oracle Database, and that database is licensed on its own terms with its own options and its own minimums. The auditor examines both layers, and the layer that usually produces the bigger finding is the one underneath, not the one users actually log into. Understanding how the two licenses interact, and where the restricted use grant ends, is what separates a contained EBS finding from a runaway one.
How is EBS licensed in an Oracle audit?
E Business Suite is licensed on application metrics, principally the application user and, for some modules, metrics tied to the business volume the module processes. The auditor counts the users provisioned in each licensed module against the entitlements you hold, module by module, because EBS entitlements are granular rather than a single blanket grant. That part of the exercise is familiar territory, and it is rarely where the surprise lives. The surprise lives one layer down, because every EBS instance runs on an Oracle Database, and that database is a separate licensed product. An EBS audit is therefore really two audits stapled together: the application entitlements, and the database that carries them.
Why does the database drive EBS audit exposure?
The database drives the exposure because it carries the expensive, easily triggered liabilities that the application layer does not. Options and management packs can be enabled accidentally, where a single Enterprise Manager click can switch on Diagnostics or Tuning Pack, and many options install by default. A processor shortfall against the core factor table, or a Named User Plus count below the per processor minimum, produces a finding measured against database license values, which are typically higher than the application user values. So even when the EBS application count is clean, the database underneath can carry an options finding, a processor finding, or a minimums finding that dwarfs it. The buyer who only checks application users is checking the smaller number.
| Layer | What is counted | Where exposure hides |
|---|---|---|
| EBS application | Application users by module | Users provisioned beyond entitlement |
| Oracle Database | Processors or Named User Plus | Options enabled, minimums, core factor |
| Restricted use grant | Database use that supports EBS | Database used for anything else |
Does the EBS restricted use license cover everything?
No, and the restricted use grant is one of the most misunderstood pieces of an EBS estate. An EBS application license that includes restricted use of the Oracle Database grants only the database use that supports E Business Suite itself. The moment that same database is used for something else, a custom application, a reporting layer, a data extract feeding another system, that additional use can fall outside the restricted grant and require full database licensing. This is a contract dependent boundary, so the exact scope of the restriction turns on your agreement, but the principle is consistent: the database under EBS is licensed for EBS, and stretching it to serve other workloads is a common way exposure appears without anyone deciding to create it.
What are the classic EBS audit findings?
The classic findings follow the database, not the application. Options and management packs enabled on the EBS database, often by default or by a single click, top the list. Named User Plus undercounts against the per processor minimum come next, because EBS environments often have more potential database users than the application user count suggests. Processor shortfalls against the core factor table appear where the database has been moved to newer or larger hardware without recounting. And restricted use boundary breaches round out the set, where the EBS database has quietly taken on work it was never licensed for. Each of these is defensible with evidence, but each is also a place where a preliminary finding can be inflated, which is why a line by line review matters.
A manufacturer was audited on an EBS estate and braced for an application user finding. The application count came back broadly clean. The exposure instead sat in the database underneath, where Tuning Pack had been enabled during routine performance work and a reporting team had pointed a custom dashboard at the EBS database, stretching it beyond the restricted use grant. A buyer side review confirmed the options usage, scoped the restricted use boundary against the agreement, and addressed both before the preliminary number hardened. The defensible position was a fraction of the opening claim, and the remaining gap was resolved commercially rather than at list price.
What is the buyer move?
The buyer move is to audit both layers yourself before Oracle does, and to weight your attention toward the database where the money is. Reconcile EBS application users by module, then turn to the database underneath: check which options and management packs are enabled and disable any not licensed and not needed, verify the Named User Plus count against the per processor minimum, confirm the processor count against the core factor table, and map the restricted use boundary against your agreement so the database is not quietly serving unlicensed work. Doing this before an audit converts the classic EBS findings into a clean, evidenced position rather than an opening for an inflated claim.
For where on premises apps differ from the cloud model, see on premises apps versus Fusion SaaS. For the support cost that rides on the estate, see application support costs and the estate. The full method sits in the Oracle license compliance guide.