Oracle licenses attach to a named legal entity, not to your corporate group, and every affiliate that touches the software outside that definition is a potential audit finding. This guide shows where the boundary sits, how shared-services and M&A activity breach it, and what to fix before Oracle counts it for you.
Oracle licenses attach to a named legal entity, not to your corporate group, and every affiliate that touches the software outside that definition is a potential audit finding. This guide shows where the boundary sits, how shared-services and M&A activity breach it, and what to fix before Oracle counts it for you.
The single most misread clause in an Oracle contract is the definition of "Customer." Buyers assume it means the enterprise. Oracle means the specific legal entity that signed the Ordering Document, plus whatever affiliates the agreement expressly names or defines. In the standard Oracle Master Agreement (OMA), the default is usage by the signing entity and its majority-owned affiliates (over 50 percent ownership), and nothing wider unless you negotiated it. Rights are limited to those expressly granted. There is no implied group license.
This matters because your corporate structure almost never matches the contract's entity definition. You have sister companies under a common parent, minority-owned joint ventures, newly acquired subsidiaries not yet integrated, and shared-services centers running workloads for entities that never appear anywhere in the paperwork. Every one of those is a question Oracle will ask at audit, and the burden of proof sits with you. If an entity is not inside the definition of Customer, Oracle treats its usage as unlicensed and prices it accordingly.
The OMA replaced the older Oracle License and Services Agreement (OLSA) in 2013, so many enterprises hold a mix of both across acquisitions and legacy purchases. The entity language is not identical across those documents, which is precisely where post-merger gray areas live. Before you assume anything is shared, pull every base agreement and read the Customer definition in each one. Related transfer and reassignment constraints are covered in our Oracle license transfer and assignment guide.
Oracle licenses attach to a named legal entity. If the affiliate is not in the definition of Customer, its usage is unlicensed by default, and the burden of proving otherwise is yours.
Even a Full Use license carries a hard limit: it may be used solely for the licensed customer's own internal business operations. Oracle's hosting policy states plainly that the customer is not allowed to use the licensed programs for the internal business operations of any other entity. When you run Oracle software to support a separate legal entity's operations, Oracle classifies that as hosting, and hosting requires either different license terms or Oracle's written approval.
This is the clause that turns ordinary group IT into a compliance problem. A shared ERP instance that processes payroll or orders for three subsidiaries is, in Oracle's reading, running the internal business operations of three entities. If only the signing entity is licensed, the other two are hosted parties, and Oracle will price the environment as if it needed full licensing for all of them. The same logic applies to a group data center that hosts an Oracle Database consumed by a minority-owned affiliate.
Agents and outsourcers are treated differently. Oracle's standard language permits your agents and contractors, including outsourcers, to use the programs for your internal business operations, and holds you responsible for their compliance. That is a narrow exception. It lets a third party operate the software on your behalf. It does not let a separate corporate entity consume the software for its own benefit. The distinction between "someone operating my system for me" and "another company using my license" is where most disputes turn. If a hosting provider or managed datacenter is in the picture, read our rules for running Oracle in a hosting or managed environment alongside this page.
Centralized IT is exactly the model Oracle's entity language penalizes. Consider the common patterns and how each reads under a standard OMA:
| Deployment pattern | How Oracle reads it | Default exposure |
|---|---|---|
| Signing entity + majority-owned subsidiaries listed | Compliant if all users' entities are in the Customer definition | Low |
| Shared ERP serving sister companies not named | Hosting of third-party internal operations | Full-capacity relicensing risk |
| Group data center used by minority-owned JV (under 50%) | JV is a third party, outside majority-owned default | Separate license required |
| Newly acquired subsidiary on parent's licenses pre-integration | Unlicensed use until contract amended and Oracle approves | Backdated fees plus new licenses |
| Contractor/outsourcer operating your system for you | Permitted exception, you remain liable for their compliance | Low if genuinely operating on your behalf |
The financial mechanics of a finding make this worse than it first looks. Oracle typically demands licenses for the full capacity of any environment where unlicensed usage appears. On Enterprise Edition at 47,500 dollars per processor (Technology Global Price List, effective April 16, 2026), a modest cluster becomes a seven-figure claim quickly. Then Oracle layers backdated support at 22 percent of the license value per year of the violation period, which on a multi-year exposure can approach the license figure itself. Virtualization amplifies this: a single Oracle Database on a VMware cluster can trigger a claim across every host in the cluster, which is how a Fortune 500 manufacturer received an opening audit claim of roughly 27 million dollars driven primarily by VMware. For the server-side count, see our note on reassigning Oracle licenses between servers and data centers.
Oracle prices unlicensed affiliate use at full environment capacity, then adds 22 percent backdated support per year. A shared instance serving three unnamed subsidiaries is not a rounding error, it is a multi-million dollar remedy.
Corporate transactions invalidate original licensing assumptions on close. When you acquire a company, that entity and its users are not entitled to use your Oracle licenses until Oracle approves and your agreements are updated. Oracle expects the acquiring company to formally add the new subsidiary to the list of entities under its Oracle agreements, which means contacting Oracle to amend the contract. Running the acquired workforce on your existing licenses in the integration window is, by the letter of the agreement, unlicensed use, and integration windows routinely run 12 to 24 months in our experience.
The OMA also commonly restricts assignment of the agreement or the licenses without Oracle's consent, so you cannot simply move licenses to an affiliate or transfer them in a reorganization on your own authority. Legacy terms compound the risk: if Company A's contract allowed usage by any global affiliate and Company B's did not, assuming Company B's licenses travel the same way is a breach. Mergers are a named, recurring audit trigger for exactly this reason. When a business unit is being spun out, the reverse problem applies and is covered in our guide to carving out Oracle licenses for a divested unit.
Practical sequence for any deal: (1) inventory every Oracle base agreement on both sides and read each Customer definition, (2) map which acquired entities will consume Oracle and under which contract, (3) request the amendment or consent in writing before go-live, and (4) preserve evidence of entitlement and approval, because that is what an auditor will demand. On the evidence point, our page on proving a legitimate Oracle transfer at audit lists exactly what to keep.
Fusion Cloud applications carry an Affiliate Usage Rights clause that allows subsidiaries, sister companies, and other affiliated entities to use the subscription under a single master agreement. On the surface this looks more generous than the on-premises default. It is, but with a hard edge: any legal entity not specified in the agreement is not allowed to use the Fusion Cloud subscription. The clause streamlines group adoption while moving compliance responsibility to the group level rather than the local entity level.
That group-level accountability is the tradeoff buyers underestimate. Under Fusion, you cannot argue that a single non-compliant subsidiary is an isolated local issue, because the master agreement holds the group responsible for the total picture. If your cloud roadmap involves consolidating affiliates onto Fusion, negotiate the list of authorized entities up front and revisit it at every renewal, because the list is the boundary, not your intentions.
The entity definition is negotiable, and it is one of the highest-return terms in an Oracle contract for any group with a complex structure. Expanding the definition of controlled or majority-owned affiliate to include additional named entities can unlock significant value and reduce per-entity licensing cost. This can be done in Ordering Documents and sometimes in the OMA itself. A global retailer negotiated its OMA to list all international subsidiaries as part of the Customer definition, with the result that any license purchased under that OMA could be deployed and used by those subsidiaries worldwide without breaching the terms.
Timing matters. The moment of maximum leverage is a purchase or renewal, when Oracle wants the deal signed. Attach the entity expansion as a condition of that transaction rather than requesting it as a standalone amendment later, when you hold no leverage and Oracle can charge for the privilege or simply decline.
Affiliate and shared-services findings are not marginal in Oracle audits. Across roughly 60 to 80 Oracle license audits Redress Compliance defended between 2024 and 2025, opening claims ran 35 to 55 percent above the position the buyer could defend after a clean measurement, and final settlements landed 30 to 50 percent below the opening number once the count was rebuilt. Entity-scope disputes are a major contributor to that inflation, because Oracle's default assumption is that every entity touching the software is unlicensed until you prove it is inside the Customer definition.
The settlement mechanics reward getting the entity definition right early. When a settlement includes backdated license fees, Oracle applies its standard 22 percent annual support charge on those licenses, and that support base then escalates at 8 percent per year compounding going forward. A 500,000 dollar license settlement today translates to 700,000 dollars or more in support obligations over five years. In other words, a settlement is not a one-time cost, it is an annuity you pay Oracle. Preventing the affiliate finding is worth far more than negotiating it down after the fact.
For buyers pressured to buy their way out of a used or resold position, note that the secondary market interacts with entity rules in ways Oracle exploits; our page on the used Oracle license secondary-market reality covers why an assignment that ignores the entity definition can be void. If cloud migration is part of the plan, the entity question follows the license under BYOL, addressed in our guide to moving Oracle licenses to the cloud with BYOL.
Only if the subsidiary is inside the contract's definition of Customer. The standard OMA default covers the signing entity and its majority-owned affiliates (over 50 percent ownership), so a wholly owned subsidiary is usually fine while a minority-owned JV is not. Read your specific agreement, because the definition varies and some contracts list entities explicitly rather than relying on the ownership default.
It restricts use of the software to the licensed entity's own operations. Oracle's hosting policy states the customer may not use the programs for the internal business operations of any other entity, and classifies such use as hosting. A shared ERP instance serving unnamed sister companies breaches this, because it runs those other entities' operations.
The acquired entity and its users cannot use your Oracle licenses until Oracle approves and your agreements are amended to add that entity. Running them on your existing licenses during integration is unlicensed use. Contact Oracle to amend the contract before go-live, and preserve written evidence of the approval for audit.
No. Oracle's standard language permits agents, contractors, and outsourcers to use the programs for your internal business operations, with you responsible for their compliance. That covers a third party operating your system on your behalf. It does not cover a separate corporate entity consuming the software for its own benefit, which is where affiliate exposure lives.
Fusion Cloud includes an Affiliate Usage Rights clause allowing subsidiaries and sister companies to use the subscription under one master agreement, but any legal entity not specified in the agreement is barred from using it. The tradeoff is that compliance accountability moves to the group level, so a single non-compliant affiliate becomes a group problem.
Yes, and it is one of the highest-value terms for complex groups. Expanding the affiliate definition or listing entities explicitly can be negotiated in Ordering Documents and sometimes the OMA itself. Do it at a purchase or renewal when you have leverage, and add a mechanism to include future majority-owned acquisitions automatically.
Oracle Exadata can lock you into full core licensing across X9M, X10M, and Cloud at Customer. The buyer side strategy to size the platform and cut the bill.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
