Indirect access is the term for the use of a licensed Oracle application by a person or a system that does not log directly into the application but reaches its data or its functions through another system. For E-Business Suite the indirect access question arises whenever a third party system reads EBS data, writes to EBS, or exposes EBS functions to users who hold no EBS licence. Oracle uses the indirect access argument to claim additional licence fees for those users and systems, and the claim can be large because it counts a population that the buyer never thought of as EBS users. This note sets out how the risk arises and how a buyer should defend it.
What indirect access means.
The principle behind indirect access is that an EBS licence is required by anyone who uses the EBS functionality, whether they reach it directly through the EBS interface or indirectly through another system. If a customer portal lets external users submit orders that flow into EBS, or if a data warehouse pulls EBS data for reporting consumed by hundreds of analysts, Oracle may argue that each of those users is an indirect user of EBS who requires a licence. The buyer who licensed only the direct EBS users faces a claim for the indirect population.
The argument turns on the licence metric. Where EBS modules are licensed by application user, the indirect access claim counts the users reaching EBS through the intermediary system. Where modules are licensed by a transaction or volume metric, the claim may instead count the volume the intermediary drives. The buyer must understand the metric to understand the exposure. For the metric detail see the Apps Unlimited pricing note.
Where the risk arises.
The indirect access risk arises wherever EBS connects to another system. The common sources are customer or supplier portals that feed transactions into EBS, integration middleware that moves data between EBS and other applications, data warehouses and reporting tools that read EBS data, and custom applications built on top of the EBS database. Each connection is a potential indirect access claim, and a typical enterprise EBS estate has many such connections accumulated over years.
The risk is heightened when the connected system serves a large user population that the buyer never associated with EBS. A self service portal used by thousands of employees or a reporting layer consumed across the business can turn into a very large indirect access claim. The buyer who has not mapped these connections does not know the size of the exposure. For the related middleware considerations see the Fusion Middleware product page.
The audit trigger.
Indirect access is most often raised in an audit. The Oracle audit examines the systems connected to EBS, identifies the users and the volumes reaching EBS through them, and constructs a claim for the indirect population. Because the audit has the technical access to map the connections, it can surface an exposure the buyer was unaware of, and the claim arrives with the weight of the audit behind it. The buyer who has not prepared the connection map defends from a weak position.
The defence to the audit trigger is to do the mapping first. The buyer who has mapped the connections, understood which raise an indirect access question, and formed a position on each can meet the audit with evidence rather than surprise. For the audit posture this sits within see our audit defense service and the related processor audit note.
The defence arguments.
The indirect access claim is not unanswerable. Several arguments limit it. The first is that the contract defines who is a user, and a careful reading of the licence definition may exclude the indirect population from the metric. The second is that the intermediary system performs the processing and the EBS data is merely a source, which may place the activity outside the EBS licence. The third is that the buyer already licenses the relevant population under another metric or another agreement, which avoids double counting.
The strength of these arguments depends on the specific contract language and the specific architecture. The buyer should analyse the licence definitions and the data flows together rather than accepting the Oracle characterisation. For the contract reading that underpins this see our contract review service, and for the wider compliance discipline see the compliance posture note.
Mapping the connections.
The foundation of any indirect access defence is a complete map of the systems that touch EBS. The map should record every inbound and outbound integration, the system on the other end, the users or volumes it serves, and the nature of the EBS interaction. With the map in hand the buyer can identify which connections raise an indirect access question, size the exposure for each, and form a position before any audit or negotiation.
The mapping is also valuable beyond the indirect access question because it documents the EBS estate for the renewal and for any migration planning. The buyer who maintains the connection map has the foundation for managing the whole EBS relationship. For the documentation discipline that supports this see the document trail note.
Resolving it in a negotiation.
The best resolution of an indirect access exposure is usually a negotiated one rather than a litigated or audited one. The buyer who has mapped the connections and formed a position can negotiate a resolution that licenses the genuine indirect access at a fair price while rejecting the overreaching part of the Oracle claim. The negotiation can also fold the resolution into a broader EBS renewal or restructuring so the indirect access question is settled as part of a larger deal on favourable terms.
The buyer should resist resolving the exposure under audit pressure, where the leverage favours Oracle, and should instead move the question into a commercial negotiation where the buyer leverage is greater. For the renewal context in which this often sits see the renewal timeline note, and for the complete framework read the Oracle Negotiation Playbook.
Preventing future exposure.
Beyond resolving the current exposure, the buyer should prevent new exposure from arising. New integrations into EBS, new portals, and new reporting layers each create potential indirect access claims, and the buyer who builds them without considering the licence position accumulates new exposure. The buyer should incorporate an indirect access check into the architecture governance so that new connections are assessed for their licence implications before they are built.
This prevention is part of the broader Oracle licence governance that a mature buyer maintains. The buyer who governs the EBS estate proactively avoids the accumulation of latent exposure that the unprepared buyer discovers in an audit. For the deal structures relevant to the application estate see the Apps Unlimited deal page, and for the wider cluster see the EBS Negotiation pillar.
Engaging an independent advisor.
An independent advisor maps the EBS connections, sizes the indirect access exposure, analyses the contract for the arguments that limit the claim, and negotiates a resolution that licenses the genuine activity while rejecting the overreach. The advisor sits on the buyer side and resists the Oracle characterisation rather than accepting it, and brings the EBS specific knowledge to a question that turns on both the architecture and the contract.
A North American distribution buyer faced an indirect access claim in 2024 for a self service portal feeding orders into EBS. The advisor mapped the data flow, established from the contract that the portal users fell outside the application user definition, and reduced the claim to a fraction of the Oracle opening position by licensing only the genuine indirect activity. The resolution was folded into the EBS renewal on favourable terms.