The customer definition decides who your ULA covers, and everyone it leaves out. At renewal it is one of the most valuable terms you can shape, and one of the easiest to leave unchanged by accident.
By Daniel Voss · Ex Oracle LMS · 4 June 2026
The customer definition names which legal entities may deploy under the ULA, and by extension which may not. It governs your right to deploy across the group during the term and which deployments can be certified at the end. Because it sets the boundary of the whole agreement, it is one of the most consequential terms in the contract and is highly negotiable at renewal. The right time to align it to your actual and planned corporate structure is now, before a future merger or exit turns a mismatch into an exposure.
Every ULA names a customer, and that name is rarely just your parent company. The customer definition is the clause that lists which legal entities are entitled to deploy the named products, often with rules about ownership thresholds, subsidiaries, and affiliates. It does two things at once. During the term it decides where you may deploy your unlimited rights. At the end it decides which of those deployments are eligible to be counted into your certified entitlement. A deployment in an entity outside the definition is not covered, however genuine it is, and at exit it becomes a remediation demand rather than a certified license.
This makes the customer definition the boundary of the entire agreement. Get it right and your deployments across the group are covered and certifiable. Get it wrong, or leave it frozen while the group changes, and usage you believed was protected turns out not to be. Renewal is the moment this boundary is open, and it should not be allowed to roll forward unexamined.
It is the clause that decides which legal entities are allowed to deploy under the agreement, and therefore everyone whose usage does not count. It typically names the contracting entity and sets rules for which related companies are included, often by ownership percentage. Reading it carefully tells you exactly where your unlimited rights reach and where they stop. The entities inside it can deploy and certify. The entities outside it cannot, and their Oracle usage sits outside the agreement entirely.
The customer definition should describe the company you are becoming, not only the company you were when the ULA was signed. Renewal is the rare moment the boundary is movable. Align it to your real and planned structure deliberately, because the next time it matters is at an exit, when it is too late to change.
Corporate change is what turns a settled definition into a problem, because it moves entities across the boundary the clause draws. The three patterns to watch all stem from structure changing faster than the contract.
In each case the deployment did not change. The boundary did, or the company moved across it. A definition written for the company as it was can fail the company as it becomes, and the failure surfaces at the worst moment, when you are trying to certify or exit.
Negotiating the definition is not simply about making it bigger. It is about fitting it to your real structure and your plans. Widen it to cover entities you know you will deploy into, including recent acquisitions and planned ones where you can. Narrow it where a broad definition adds risk without benefit, for example by removing entities you intend to divest. Protect it with assignment and corporate change language that lets the definition follow reasonable restructuring without renegotiation, and with clear rules for how acquired entities are brought into scope. The aim is a definition that bends with the business rather than one that has to be rewritten under pressure at the next exit. As always, what is achievable depends on the specific contract language and on what Oracle will agree, so the clause should be read closely before any position is taken.
An anonymized example shows the stakes. A manufacturer renewed its ULA shortly after acquiring a competitor. The original customer definition named only the legacy group, so the acquired entity's substantial Oracle estate sat outside scope. Left unaddressed, it would have become a remediation demand at the next certification. By negotiating the acquired entity into the definition at renewal, and adding corporate change language for future deals, the manufacturer brought the deployments into scope and protected itself against the next acquisition. The figures are indicative, but the exposure avoided was significant, and it cost nothing but attention at the right moment.
The customer definition is open at renewal and closed everywhere else, so use the moment to fit it to the company you are becoming. Read the renewal number for what it really is in the renewal quote is an opening position, assemble the facts that carry every term in the renewal data room, and ground the decision in our certify or renew guide.
Book a ULA assessment and we will read your customer definition against your real and planned structure, then shape it to cover what you deploy and protect what you certify.