Most large Oracle estates are held by a single contracting entity, yet the software is used across dozens of legal entities in the corporate group. The gap between the entity that signed the contract and the entities that actually use the software is one of the most common and most expensive compliance findings Oracle raises. This article sets out how subsidiary and affiliate use should be governed and where the audit risk concentrates.
This article is a companion to our licensing compliance pillar and supports our contract review service.
The Definition of Customer
Every Oracle agreement defines who the customer is. The definition matters far more than most procurement teams realise at signing. A narrow definition limits use to the named legal entity. A broad definition extends use to affiliates, subsidiaries, and sometimes to entities under common control. The difference between these two definitions can be worth millions of dollars over the life of the agreement.
The standard Oracle ordering document names a single legal entity. The use rights granted under that document attach to that entity. If a sister company or a foreign subsidiary deploys the same software, the deployment falls outside the licence grant unless the agreement specifically extends to affiliates. Oracle's audit team checks the contracting entity against the entities running the software, and the mismatch becomes a finding.
The Affiliate Clause
The affiliate clause is the mechanism that extends use rights beyond the contracting entity. Where it exists, it usually defines an affiliate by reference to ownership or control thresholds. A common formulation extends rights to any entity that the customer owns or controls by more than fifty percent. Some clauses are broader and cover any entity under common control with the customer.
The defensive position is to negotiate the affiliate clause at the point of signing rather than to discover its absence at audit. Customers with active acquisition strategies should push for a definition that captures future acquisitions automatically. Customers with complex group structures should ensure that the clause captures the way the group actually operates, including shared service centres and intra group hosting arrangements.
The clause should also address what happens when an affiliate leaves the group. Without divestiture language, the question of whether a divested entity may continue to use the software becomes a negotiation at the worst possible time.
The Shared Service Centre Problem
Many groups run Oracle workloads from a shared service centre that processes transactions for multiple group entities. The shared service centre is a single technical deployment, but it serves many legal entities. Oracle's licensing logic does not always follow the deployment. It can follow the use.
For named user metrics, the question is which individuals access the system. For processor metrics, the question is the hardware capacity. Where a shared service centre processes data for entities that are not covered by the licence grant, Oracle can argue that those entities are using the software and require their own licences. This is a frequent finding in groups that consolidated their Oracle operations without revisiting the contractual scope.
The most expensive subsidiary findings we have defended did not come from new deployments. They came from corporate reorganisations that moved Oracle workloads between legal entities without anyone checking whether the licence grant followed the move. The software ran fine. The compliance position did not.
The Acquisition Trap
When a group acquires a company, the acquired entity often brings its own Oracle estate. The acquiring group then faces a choice. It can maintain the acquired entity's contracts separately, or it can consolidate the acquired estate into the parent agreement. Both paths carry risk that Oracle is well positioned to exploit.
If the acquired entity's licences were limited to that entity, moving its workloads onto the parent's infrastructure can breach the original grant. If the parent's licences do not extend to the newly acquired affiliate, deploying parent licensed software at the acquired entity creates exposure in the other direction. Oracle audits frequently follow major acquisitions precisely because these transition periods generate compliance gaps.
The disciplined approach is to map the licensing position of both estates before the integration begins, and to negotiate any required contractual changes as part of the deal rather than after it. Our ULA deal page covers how an unlimited agreement can simplify acquisition integration where the volume justifies it.
The Divestiture Question
Divestitures are the mirror image of acquisitions. When a group sells a business unit, the buyer expects to receive the software the unit runs on. Oracle licences are generally not transferable without Oracle's consent. The divested entity cannot simply walk away with a share of the parent's licences.
This creates a negotiation that should happen before the sale closes, not after. The seller needs either to carve out a transferable set of licences for the buyer or to ensure the buyer can stand up a fresh agreement. Oracle has significant leverage in this moment because the transaction depends on a working software estate. Buyers and sellers who address the licensing position early avoid paying a premium under deal pressure.
The Foreign Subsidiary Currency and Entity Issues
Multinational groups face an additional layer of complexity. Foreign subsidiaries may contract with local Oracle entities in local currency. The use rights, the support renewal, and the audit jurisdiction can all differ from the parent agreement. A group that assumes its master agreement governs all global use can find that several foreign subsidiaries are operating under separate, narrower contracts.
The reconciliation discipline is to maintain a single inventory of every Oracle contract across every entity in the group, with the contracting party, the metrics, the territory, and the support status for each. Groups that maintain this inventory can answer an audit request precisely. Groups that cannot produce it spend the early weeks of an audit assembling the picture that Oracle already has.
The Internal Governance Control
The practical defence against subsidiary exposure is an internal governance control that requires licensing review before any corporate reorganisation, acquisition, divestiture, or shared service consolidation. The control should sit with the same team that manages the Oracle relationship, and it should have visibility of corporate development activity.
Groups that wire licensing review into their corporate development process catch the exposure before it becomes a finding. Groups that treat Oracle compliance as an IT matter, disconnected from corporate structure decisions, accumulate exposure quietly until an audit surfaces it. Our BYOL compliance article covers the related discipline for cloud deployments, which often span multiple group entities.
Where to Read Next
For the EBS user side of compliance see our EBS user compliance article. For the broader compliance posture see our licensing compliance pillar. The Oracle Audit Defense Handbook covers the full methodology. The ULA deal page covers how unlimited agreements handle group structures. The Oracle Database product page covers the product family that drives most subsidiary findings.