Professional services firms face a sharper version of the scope question than most. They run Oracle for clients, give contractors access, and operate partner environments, and whether that usage falls inside the ULA decides whether the certification is clean. The customer definition, not the technology, settles it.
By the Meridian advisory team · Ex Oracle licensing analysts · Updated June 2026
Professional services firms face a customer definition question sharper than most: whether usage by clients, contractors, and partners falls inside the ULA or outside it. The answer decides whether the certification is clean or carries hidden exposure, and it is governed entirely by the use rights and customer definition in your specific contract.
The customer definition is the central risk, and it is more acute in professional services than in almost any other sector. The reason lies in the business model. A consultancy, a systems integrator, an outsourcing provider, or an advisory firm does not only run Oracle for its own back office. It frequently runs Oracle as part of delivering services to clients, gives contractors and subcontractors access to systems, and operates environments that sit between the firm and its partners. A ULA grants unlimited deployment, but only for a defined customer and usually only for that customer's own business operations. The question that decides a professional services certification is whether the firm's client facing, contractor, and partner usage falls inside that definition or outside it. Where it falls inside, it can be certified like any other deployment. Where it falls outside, it cannot be certified, and worse, it can represent usage that was never licensed correctly in the first place, surfacing as an exposure precisely when the firm is trying to close out cleanly. The general ULA mechanics are unchanged, but the customer definition does far more work here, and a firm that has not read it carefully can be certifying a position that does not match how it actually uses the software.
For professional services firms, the certification stands or falls on the customer definition and the use rights. Internal operations are usually straightforward. Client delivery, contractor access, and partner environments are not, because a typical ULA limits use to the customer's own business. Map every deployment to who uses it and for what, test each against the contract, and resolve any out of scope use before exit. Certify only what the agreement genuinely covers.
It depends entirely on the agreement, and this is one of the clearest cases where a general answer would mislead. Many ULAs restrict the grant to the customer's internal business operations, language that can exclude using the software to deliver services to third party clients. Other agreements specifically contemplate hosting, outsourcing, or service provision and permit it within defined limits. Some are silent, and silence is not permission. The practical consequence is that two firms with apparently similar businesses can get opposite answers depending on a single clause. Where client facing use is permitted and in scope, those deployments may count toward the certified number like any other. Where it is excluded, the deployments do not count, and certifying them would overstate the position and rest on usage the contract never authorised. Before any client related deployment is added to a count, the use rights have to be read and the answer confirmed, because the downside of getting this wrong is not merely a smaller count but a misstatement attached to a letter a senior executive signs.
Even firms that keep Oracle strictly for internal operations often have a softer boundary than they realise. Contractors and subcontractors access internal systems. Partner organisations connect to shared environments. Managed service arrangements blur who is operating a system and on whose behalf. Each of these is a use rights question, because a ULA that limits use to the customer's own personnel and operations may treat extensive third party access differently. The point is not that such access is automatically a problem, but that it is a question that must be asked and answered against the contract, rather than assumed away. The quiet edges of access are where a professional services firm most often finds usage it had not mapped to a clear licensing basis.
The preparation follows a clear sequence built around the customer definition. First, map every Oracle deployment not just to a product and an environment, but to who uses it and for what purpose: internal business operations, client service delivery, contractor or subcontractor access, or partner facing systems. This usage map is the input that a normal inventory omits and that a professional services firm cannot do without. Second, test each category against the customer definition and the use rights in the agreement, marking what is clearly in scope, what is clearly out, and what is genuinely ambiguous. Third, resolve the out of scope and ambiguous categories before exit, either by bringing the usage into scope where the contract permits it, by separating or relicensing it, or by ceasing it deliberately. Fourth, certify only what the agreement genuinely covers, with evidence that ties each certified deployment to in scope usage. Done in this order, the firm certifies a position that matches reality and survives scrutiny. Done carelessly, it certifies a number that an audit can unpick, which is a particularly poor outcome given that audit risk rises in the two years after certification and the evidence file is the only defense.
| Usage category | Typical scope question | The disciplined response |
|---|---|---|
| Internal business operations | Usually in scope | Inventory and evidence normally |
| Client service delivery | Depends on hosting and outsourcing rights | Read use rights before counting |
| Contractor and subcontractor access | Depends on customer definition | Confirm against the agreement |
| Partner and shared environments | Often ambiguous | Resolve scope before exit |
Consider a global consultancy, figures and facts indicative only, that assumed its ULA covered everything it ran. A usage map showed three pictures: a clean internal estate, a set of client delivery environments whose status depended on a hosting clause, and contractor access that needed checking against the customer definition. Reading the agreement confirmed the internal estate and the permitted hosting were in scope and could be certified, while a small set of client environments were not and were separated before exit. The firm certified a strong, accurate position and avoided attaching out of scope usage to the certification letter, which would have invited exactly the audit it wanted to avoid.
More than in any sector covered here, the professional services certification is a contract reading exercise. The size of the estate matters less than the precise wording of the customer definition and the use rights, because those clauses decide which of the firm's many kinds of usage can be certified at all. A firm that treats certification as a counting task will miss the question that matters. A firm that treats it as a scope and use rights task, supported by a careful usage map and clean evidence, will certify a position it can stand behind. As always, where the answer turns on specific language, it has to be read from your agreement rather than inferred from the general pattern.
The scope discipline here connects to the other industry playbooks. Read Oracle ULA certification for healthcare for the entity scope challenges of an acquisitive group, and Oracle ULA certification for telecom for the global territory questions of a multi national estate. Our Oracle ULA certification guide is the pillar that frames the certification process end to end. To map your usage against your customer definition and certify a clean position, the next step is a confidential assessment.
The customer definition. Professional services firms routinely run Oracle on behalf of clients, give contractors access, and operate partner environments. Whether that usage falls inside the ULA depends on how the customer definition treats third parties and outsourced use. If it sits outside scope, it cannot be certified and can become an exposure. The contract language is decisive.
It depends entirely on the agreement. Some ULAs restrict use to the customer's own internal business operations, which can exclude running systems for third party clients. Others permit defined hosting or outsourcing. Where client facing use is permitted and in scope it may count; where it is excluded it does not, and certifying it would misstate the position. Read the use rights before counting.
Start by mapping every Oracle deployment to who uses it and for what: internal operations, client delivery, contractor access, or partner systems. Then test each category against the customer definition and use rights. Resolve any out of scope use before exit, by bringing it into scope where the contract allows or by separating it. Certify only what the agreement genuinely covers.