What a ULA true-up actually means
In most enterprise software contracts a true-up is the periodic reconciliation between what a customer is entitled to and what it has actually deployed, with a payment owed for the gap. An Oracle Unlimited License Agreement inverts this logic for the products it covers. During the term the customer may deploy an unlimited quantity of each in scope product without any incremental payment, so there is no gap to reconcile and no in scope true-up to pay. The fixed fee bought the right to grow freely. This is precisely why the agreement is attractive to organisations expecting rapid deployment, as set out in the Oracle ULA pillar guide.
The confusion arises because true-up obligations do not vanish entirely. They migrate to the boundaries of the agreement. Anything deployed outside the defined product scope, anything used by a legal entity that is not a party to the contract, and anything that pushes the organisation past a contractual growth limit can still create a payable position. The disciplined customer treats the ULA not as a blanket immunity but as a fence with very specific gaps, and spends the term making sure nothing material falls through them.
Why there is no annual true-up in scope
The economic premise of a ULA is that the customer prepays for unlimited deployment of a named set of products over a fixed period, usually three years. Oracle has already collected the fee, so it has no contractual mechanism and no commercial reason to bill again for in scope growth during that window. A customer that triples its database footprint in year two owes nothing extra for those databases, provided every instance runs a product on the ULA schedule and sits inside a covered legal entity. This is the core value the agreement delivers and the reason aggressive deployment during the term is rational behaviour, a theme developed in the ULA certification guide.
Inside the fence, deploy freely; the meter is off. Outside the fence, every instance is a separate purchase. The whole game is knowing where the fence runs.
The absence of an in scope true-up is also what makes the certification count so consequential. Because Oracle never bills for growth during the term, it captures the cumulative value only at the end, when the customer declares the total deployed quantity and that number becomes a permanent perpetual entitlement. The lack of interim reconciliation is not generosity; it is a deferral of the reckoning to a single decisive moment, which we cover under certification below.
What triggers a true-up under a ULA
Four situations create a payable position during or at the end of a ULA. Each is avoidable with attention, and each catches unprepared customers regularly.
| Trigger | What happens | How to avoid it |
|---|---|---|
| Out of scope product | Separate licence owed | Confirm every deployed product is on the ULA schedule before install |
| Unnamed legal entity | Usage is unlicensed | Map all entities; add subsidiaries to the agreement where possible |
| Acquisition over threshold | Renegotiation required | Model the growth clause before closing any deal |
| Certification shortfall | Perpetual entitlement understated | Maximise and evidence the count before term end |
The first trigger, out of scope products, is the most common and the most insidious. A team deploys an option or pack that was not included in the ULA schedule, assuming the unlimited right covers it, and creates an unlicensed position that surfaces in an audit. The remedy is a strict deployment control that checks every new install against the schedule. This discipline overlaps directly with Oracle audit defence, because the same gaps that create true-up exposure are the findings an auditor pursues.
The second trigger, usage at unnamed legal entities, is a structural problem. A ULA covers only the legal entities named in it, and deployment at a subsidiary, joint venture, or newly formed entity outside that list is simply unlicensed, no matter how clearly it belongs to the same corporate group. Customers with complex group structures should map every entity at the outset and negotiate the broadest possible definition of the licensed parties, a point we return to in the ULA negotiation strategy guide.
Acquisitions and the growth threshold
The merger and acquisition clause is where true-up risk most often becomes material. Many ULAs permit acquired entities to deploy in scope products under the unlimited right, but only if the acquisition keeps the organisation under a stated growth threshold, frequently expressed as a percentage of revenue or employee headcount, often around ten percent. An acquisition that exceeds the threshold falls outside the ULA, and the acquired entity's Oracle usage must be licensed separately or folded in through a renegotiation that Oracle will price to its advantage.
This makes the ULA growth clause a live consideration in corporate development, not a back office licensing detail. A company that signs a ULA and then makes a transformational acquisition can find that the deal it expected to absorb under the unlimited right instead triggers a substantial separate licensing cost or an unfavourable mid term renegotiation. The buyer side discipline is to model the clause before any deal closes, so that licensing cost is priced into the transaction rather than discovered after it. The interaction between corporate transactions and the unlimited right is explored in depth in the dedicated guide to ULA exit strategy, where divestiture creates the mirror image problem.
Certification as the final true-up
The certification at the end of the term is, in substance, the only true-up that the ULA truly demands, and it runs in the customer's favour rather than Oracle's. Instead of paying for deployment, the customer declares it, and the declared quantity converts to a permanent perpetual licence at no additional cost. The reconciliation that other agreements perform annually, the ULA performs once, at the end, as a count rather than a bill.
This reframes the certification from a compliance chore into the single most important commercial event of the agreement. Every in scope instance deployed and running before the cut off date adds to the perpetual entitlement; every instance the customer fails to deploy or fails to count is value left permanently on the table. Because there was no interim true-up, all the value accumulates to this moment, which is why the certification process deserves a year of preparation rather than a fortnight. The customer that understands the ULA has no annual true-up also understands why the certification count carries the entire weight of the deal.
How to manage true-up exposure during the term
Managing true-up exposure under a ULA is a continuous governance task, not a year end scramble. Three practices keep exposure under control. The first is a deployment gate: every new Oracle installation is checked against the ULA product schedule and the list of licensed legal entities before it goes live, so out of scope products and unnamed entities never accumulate silently. The second is an internal inventory maintained in parallel with deployment, so the customer always knows its own position and arrives at certification with a finished count rather than a discovery exercise.
The third practice is corporate development integration. Whenever an acquisition, divestiture, or group restructuring is contemplated, the ULA growth and assignment clauses are checked as part of deal diligence, so licensing consequences are priced and planned rather than inherited. Together these three practices convert the ULA from a source of latent surprise into a controlled asset. They are the same governance disciplines that underpin a strong ULA negotiation engagement, because the clauses you manage during the term are the clauses you should have shaped at signing.
The buyer side view
The practical takeaway is that the ULA does not eliminate true-up risk; it relocates it. There is no meter running on in scope deployment, which is exactly why customers should deploy freely inside the fence, but the boundaries of that fence carry real exposure that compounds quietly if it is not governed. The customers who treat the ULA as a fence to be patrolled, checking every product, every entity, and every transaction against the contract, never receive an unexpected bill and arrive at certification with the maximum legitimate count.
Map your product scope and licensed entities at signing, model the growth clause before any acquisition, and run the term as a deliberate accumulation toward the certification count. To work through your own agreement, read the ULA pillar guide and engage the ULA negotiation service well before the term end approaches.
Oracle ULA true-up: frequently asked questions
Does an Oracle ULA have an annual true-up?
A standard Oracle ULA does not require an annual true-up for in scope products, because deployment of those products is unlimited during the term. True-up obligations arise for products outside the ULA scope, for entities not named in the agreement, and at certification when the final count is declared. See the ULA pillar guide.
What triggers a true-up under an Oracle ULA?
A true-up is triggered by deploying products that are not in scope, by usage at legal entities not party to the agreement, by acquisitions above the contract growth threshold, and by certification at term end where the cumulative count becomes the perpetual entitlement.
How are acquisitions handled during a ULA?
Acquisitions are governed by the merger and acquisition clause. Many ULAs allow acquired entities to deploy in scope products only if combined revenue or employee growth stays under a stated threshold, often ten percent. Larger acquisitions require renegotiation or a separate licence. See the exit strategy guide.
Is the certification count a kind of true-up?
Yes. Certification is the final true-up of the agreement. The customer declares the total quantity deployed and that figure becomes the permanent perpetual entitlement, so the certification count should be maximised legitimately before the term ends. See the certification guide.