Oracle EBS Custom Application Licensing

What is EBS custom application licensing?

Most EBS customers extend the suite. They build custom forms, reports, workflows, and integrations to fit the software to the business. Oracle anticipates this, and the licence grant for the EBS technology components, the Forms, Reports, Application Object Library, and the underlying database, permits customisation in support of the licensed application. The exposure arises when customisation crosses from extending the licensed modules into building genuinely new, standalone functionality that uses Oracle technology but is not part of any licensed product.

When that line is crossed, Oracle's position is that the new functionality requires its own licence, historically under metrics such as Custom Application User or a Custom Application licence priced against the user population of the bespoke system. The difficulty is that the line is not bright, and many customers do not realise they have crossed it until an audit raises the question. The EBS licensing pillar places this alongside the other metrics; this article focuses on the customisation specific exposure.

When does a customisation become licensable?

The practical test Oracle applies is whether the customisation supports the licensed application or constitutes new business functionality in its own right. A custom invoice approval workflow that extends Payables supports a licensed module. A standalone asset tracking system built on EBS Forms and the EBS database, used by people who hold no licence for any standard module, is new functionality and is exposed. Between these poles sit countless grey cases.

The last row is the most dangerous because it links two exposures. A custom schema in the EBS database is both a candidate custom application and a use of the database beyond the application, which voids the restricted use grant covered in the restricted use database article. One design decision can therefore create both an application and a technology finding.

The Custom Application User metric

Where Oracle does assert a custom application licence, it is typically counted on a user metric mirroring the Application User: every individual authorised to use the custom functionality. The same dynamics that inflate standard Application User counts apply here, with the added complication that custom systems often lack formal access controls, making the authorised population harder to bound. A custom app deployed to the whole workforce, without role based access, presents Oracle with the entire headcount as the count.

The remediation mirrors the standard metric: bound the authorised population with real access controls, document who genuinely uses the custom functionality, and separate it cleanly from the licensed modules. Where the custom functionality genuinely extends a licensed module, the supporting documentation should make that relationship explicit so it is defended as in scope rather than conceded as new. The contractual nuances are explored in the soft clauses and customisation article.

How to avoid hidden custom exposure

The defensible posture starts with an inventory. Catalogue every customisation, classify each as either an extension of a licensed module or potential new functionality, and document the basis for each classification. For genuine extensions, capture the link to the licensed module. For anything that looks standalone, decide deliberately whether to license it, retire it, or re engineer it as a documented extension. Doing this proactively converts an open ended audit question into a settled, evidenced position.

This inventory pairs naturally with the user reconciliation in the Application User article and the database review in the restricted use database article, because the three exposures are interlinked. The applications licensing practice runs the customisation inventory as part of a full EBS baseline.

The buyer side view

Custom application exposure is the EBS finding customers least expect, because the customisation felt like a normal use of software they had already paid for. The buyer side discipline is to treat every customisation as a licensing decision at the moment it is built, not at the moment it is audited. Classify it, control access to it, and document its relationship to the licensed modules. Where it genuinely extends what you have licensed, the documentation defends it. Where it is new, you decide the commercial response on your own terms.

An undocumented custom estate is pure downside in an audit. A catalogued, classified one is a defended position. To inventory and classify your EBS customisations before Oracle does, request a consultation.

Building the customisation inventory

An effective customisation inventory is not a list of objects; it is a classification of intent. For each custom form, report, workflow, schema, and interface, the inventory records what it does, which standard module it relates to, whether it extends that module or stands alone, and who is authorised to use it. The classification matters more than the count, because Oracle's exposure argument turns on whether the customisation is new functionality or an extension of something already licensed.

The inventory is best assembled from three sources cross referenced: the custom application registrations in the EBS configuration, the custom schemas present in the database, and the access controls that govern who reaches each customisation. Cross referencing these surfaces the dangerous cases, a custom schema with no relationship to a licensed module, reachable by users who hold no standard module licence, which is exactly the profile of a standalone application that Oracle will treat as separately licensable and that also voids the restricted use database grant.

Once classified, each customisation gets a decision: defend as an extension with documentation, retire if unused, re engineer to bring it within a licensed module's scope, or license deliberately if it is genuinely new and worth keeping. Making these decisions proactively converts an open ended audit question into a settled position, and it removes the single most unpredictable element of an EBS audit, the customisation Oracle finds that the customer had forgotten about.

Third party and bolt on systems

Customisation exposure is not limited to in house development. Third party bolt on products that sit on the EBS technology stack, integrate deeply with the database, or run their own schemas inside the EBS instance create the same exposure as bespoke code. A vendor supplied tax engine, document management add on, or industry specific extension that uses Oracle technology beyond the application can void the restricted use database and, where it constitutes distinct functionality, raise the custom application question.

The diligence here is to treat every bolt on as a potential exposure and to establish, before deployment, how it interacts with the EBS technology stack. The safe pattern is integration through supported application interfaces rather than direct database access. The dangerous pattern is a product that installs its own schema and queries EBS tables directly, because that is precisely the use of the database beyond the application that the restricted use grant forbids. Where bolt ons are already deployed, they belong in the customisation inventory and the technology stack review run by the applications licensing practice.