Oracle EBS Module Licensing

Why EBS is licensed module by module

Oracle E-Business Suite is sold as a suite but licensed as a collection of independent products. You do not hold a licence for EBS; you hold licences for General Ledger, Payables, Order Management, Inventory, iProcurement, Projects, and each other module you have bought, each with its own price, its own metric, and its own authorised user population. This modularity is the structural fact that shapes every EBS licence position, because compliance is assessed product by product, not across the suite.

The consequence is that an estate is never simply compliant or non compliant. It is a portfolio of positions, some with headroom and some in shortfall. A review that looks at total users against total entitlement misses the picture entirely; the exposure lives in the per module gaps. The EBS licensing pillar sets out the metrics, and this article focuses on how those metrics combine across the module portfolio.

The module families and their metrics

EBS modules group into families, and while each module is licensed individually, the metric tends to follow the family. Financials and procurement modules use Application User. Human capital modules use the Employee metric. Some specialised modules use business activity metrics. Knowing the family tells you which counting exercise applies before you open the contract.

The detail of the financials family is developed in the EBS Financials licensing article and the supply chain family in the supply chain module article. The common thread is the Application User metric, whose counting mechanics are covered in the Application User article.

Module dependencies and bundled access

Modules do not stand entirely alone. Some require others to function, and access to one frequently exposes another. Order Management depends on Inventory and Pricing. A responsibility built for an order management role may grant access to inventory inquiry, pulling Inventory into the user count for users whose role is ostensibly only sales orders. These dependency driven inclusions are a common source of unexpected per module shortfall, because the user was never intended to be an Inventory user but is counted as one.

Mapping these dependencies is part of the per module reconciliation. The goal is to ensure that each user is counted for the modules their role genuinely requires, and that dependency driven access is either justified by real use or removed by responsibility redesign, exactly as in the Application User reconciliation.

Where shelfware hides in the module portfolio

The flip side of per module exposure is per module shelfware: modules licensed but never deployed, or deployed and abandoned. Because support is charged as a percentage of the licensed estate, shelfware modules carry an annual cost long after they stop being used. Identifying them is straightforward in principle, the deployment shows no real users, and valuable in practice, because they are candidates for removal before the next support renewal locks the cost in for another term.

Shelfware removal is a renewal strategy as much as a licensing one, and it interacts with any unlimited agreement on the table. Where module sprawl is significant, the ULA negotiation practice assesses whether consolidation under an unlimited agreement or a deliberate drop of unused modules produces the better outcome. The support renewal strategy article covers the timing.

Building the per module position

A defensible module position is a table: every licensed module, its metric, its entitlement, its authorised population, and the resulting headroom or shortfall. Built proactively, it shows exactly where to remediate and where shelfware can be cut. Built reactively under audit, it is the document that disciplines Oracle's aggregate claim into a set of specific, arguable per module positions, many of which dissolve on the evidence.

This per module table is the heart of the EBS baseline run by the applications licensing practice. It is the artefact that turns a vague sense of EBS exposure into a quantified, prioritised remediation plan.

The buyer side view

The single most important shift in EBS licensing is to stop thinking about the suite and start thinking about the portfolio. Every module is a separate position with its own metric, its own population, and its own headroom or gap. Aggregate thinking hides both the exposure and the savings. Per module thinking surfaces the shortfalls to fix and the shelfware to cut, and it forces Oracle to argue specifics rather than assert a suite wide number.

Build the per module table, keep it current, and review it before every renewal. It is the cheapest insurance in the EBS estate. To build your module by module position, request a consultation.

Running the portfolio review

A module portfolio review proceeds in a fixed sequence that makes the per module positions comparable. First, enumerate every licensed module from the contract, with its metric and entitled quantity. Second, measure the authorised population for each from the EBS security configuration. Third, reconcile that population against genuine need, removing terminated, duplicate, and over scoped access. Fourth, compute headroom or shortfall per module. Fifth, flag shelfware where the deployment shows no genuine users. The output is a single table that prices the entire EBS estate one module at a time.

The discipline of doing this per module, rather than in aggregate, is what surfaces both the risks and the opportunities. Aggregate user counts hide a Payables shortfall behind General Ledger headroom; the portfolio table exposes each. It also makes the remediation prioritisable: the modules with the largest shortfall and the highest unit cost get attention first, and the shelfware with the highest support cost gets cut first. This table is the backbone of the licence position baseline and the artefact the applications licensing practice maintains between reviews.

Suite bundles and component licences

Oracle has sold EBS modules both individually and in bundles, and the bundle a customer bought shapes the position decisively. A suite bundle such as a financials family pack may license a defined set of modules together under combined terms, which can be advantageous, fewer separate metrics to manage, or constraining, the bundle may include modules the customer does not use and exclude one they do. Understanding exactly which modules a bundle covers, and on what metric, is essential before any per module conclusion can be trusted.

The shelfware point is the subtle one. In a bundle, unused modules do not show as separate line items, so the support cost of shelfware is hidden inside the bundle price and is harder to challenge at renewal. Surfacing it requires decomposing the bundle into its component modules and measuring each, which is exactly what the portfolio review does. The renewal implications are developed in the support renewal strategy article.