Does custom code create an EBS licensing exposure?
Custom code can create an E-Business Suite licensing exposure, because custom interfaces and reports that reach EBS data through the database can pull additional users into the licensed count as indirect use, even when those users never open the EBS front end. Most large EBS estates carry years of custom development: integrations to other systems, reporting layers, self service portals and batch interfaces. Each of these is a potential route by which a person who is not a named EBS user nonetheless consumes licensed EBS functionality, and Oracle's auditors look closely at exactly these routes.
The exposure is real but it is also frequently overstated. The fact that a custom interface exists does not mean every person downstream of it is an indirect EBS user. Much custom code moves data that has already left the licensed boundary, serves purely technical functions, or feeds systems that are licensed in their own right. The compliance question is not whether custom code exists, but what each piece of it actually accesses and who actually benefits. That distinction is where the buyer position is built.
What is indirect use in Oracle EBS?
Indirect use in Oracle EBS is access to licensed E-Business Suite functionality through an intermediary, such as a custom portal, an integration or a report, rather than through the EBS application directly. Oracle's position is that the human who ultimately benefits from licensed functionality needs a license, regardless of the technical path the data travels. A customer who places an order through a website that writes into EBS, or an employee who reads EBS data through a custom dashboard, can be characterised as an indirect user under this reading.
The reach of the concept is what makes it contentious. Taken to its widest, indirect use would count every person anywhere downstream of any EBS data, which is neither what most contracts say nor a workable standard. The contract is what bounds it. EBS user metrics are defined in the agreement and its ordering documents, and those definitions, not a general theory of indirect benefit, decide who must be licensed. A buyer faced with an indirect use claim should ask what the contract's own definition of a user covers, because that definition is usually narrower than the audit assertion.
| Custom interface | Oracle position | Buyer move |
|---|---|---|
| Self service portal to EBS | Users are indirect | Map to contract definition |
| Read only reporting layer | Often claimed | Show what it accesses |
| System to system integration | Disputed | No human user to count |
| Data exported and licensed elsewhere | Sometimes claimed | Show the licensed boundary |
How do you map custom code for compliance?
You map custom code for compliance by inventorying every custom interface and recording, for each, what EBS data or functionality it touches and which population of people it ultimately serves. This is the document that turns an open ended indirect use claim into a bounded, factual question. Without it, Oracle's auditors can assert that the whole user base behind every interface is licensable, and the buyer has nothing concrete to push back with. With it, each interface becomes a line that can be assessed on its own facts.
The map should distinguish interfaces that genuinely deliver licensed EBS functionality to a human from those that do not, such as purely technical data movement, functions licensed under a different product, or data that has already crossed the licensed boundary. It should also tie each population to the contract's definition of a user, so the count reflects the agreement rather than a theory. Building this map before an audit, as part of standing compliance, is far easier than reconstructing it under a 30 to 45 day response window, which is one reason a compliance review before an audit is worth doing.
How do you defend a custom code EBS finding?
You defend a custom code E-Business Suite finding by setting the interface map against the contract's user definitions and showing, line by line, who is genuinely a licensable user and who is not. The factual front uses the map to demonstrate what each interface actually accesses and serves, which rebuts a blanket indirect use claim. The contract front holds the count to the agreement's own definition of a user, since contract language beats a general theory of indirect benefit, and many indirect use assertions do not survive a close reading of the signed terms.
This matters because preliminary findings arrive inflated at list price, and indirect use is one of the easiest places for a finding to balloon, since it can be made to sweep in entire downstream populations. An independent line by line review of findings typically cuts claims by 60 to 80 percent, and custom code findings, built as they often are on the widest reading of indirect use, are a common place for a substantial reduction. The work is methodical: inventory, map, and read against the contract.
The next step
This article is part of our EBS and Applications cluster. Read the pillar, the Oracle license compliance guide, for the full picture, and these related reads: indirect use in Oracle applications, and EBS user metrics and counting rules.