A capped ULA gives you unlimited deployment up to a ceiling, then a true up applies. The cap limits the count you can certify, so the deployment plan and the exit number both have to respect it. Knowing where the line sits is the whole game.
By the Meridian advisory team · Ex Oracle licensing analysts · Updated June 2026
A capped ULA is an unlimited license agreement whose unlimited right is bounded by a ceiling. You deploy freely up to the cap, which is usually a maximum quantity of processors or named users, or a restriction on which products or entities the unlimited right covers. Below the line the agreement behaves like a standard ULA. Above it, deployment is not automatically covered and is settled through a true up or a separate purchase. The cap is the defining feature, and it cuts both ways: it limits the price exposure for Oracle, and it limits the free value a buyer can extract. Reading exactly where the cap sits, and what it measures, is the first task with any capped agreement.
A capped ULA is unlimited only up to a ceiling. Certification can convert deployment into perpetual licenses up to the cap and no further. Deployment above the line is exposure, not free value, and it is usually settled at terms far worse than the original deal. The strategy is to land at or just below the cap, and to plan any true up deliberately rather than discover it.
Caps take several forms, and the form changes the management approach. The most common is a quantity cap, a maximum number of processor licenses or Named User Plus that the unlimited right will convert at certification. Others restrict scope: the unlimited right applies to a named subset of products, or to specified legal entities or territories, with everything outside that boundary excluded. Some agreements combine both. The practical effect is the same in each case. There is a line, and the contract treats deployment on one side of it very differently from deployment on the other.
A quantity cap sets the maximum count you can certify. If the ceiling is, indicatively, four hundred processor licenses, you can deploy and certify up to four hundred, and deployment beyond that figure falls outside the unlimited right. The discipline this imposes is real. A team used to thinking of the ULA as truly unlimited can deploy past the cap without realising it, turning what felt like free capacity into a settlement obligation at exit.
A scope cap limits which products, entities, or territories the unlimited right covers. Deployment of a product that is in your estate but outside the named set is not covered, even if you are well under any quantity ceiling. Scope caps interact badly with corporate change. An acquisition, a new subsidiary, or a deployment in an entity outside the named list can sit outside the cap and create exposure that has nothing to do with how much you deployed.
A true up is the mechanism that settles deployment above the cap. When usage exceeds the ceiling, the contract typically requires you to purchase the excess, and the pricing for that purchase is usually far less favourable than the economics of the original ULA. This is the sharp edge of a capped agreement. The unlimited right that felt generous up to the cap becomes ordinary, list driven licensing the moment you cross it. A buyer who manages deployment to land at or below the cap avoids the true up entirely. A buyer who plans a true up deliberately, with the cost understood in advance, at least controls it. The worst outcome is the true up that arrives as a surprise at certification, priced from a position of no leverage.
Certification of a capped ULA follows the same process as a standard one, with a hard limit bolted on. You measure the deployment, build the evidence, and convert deployed quantities into perpetual licenses, but only up to the cap. The maximisation logic that applies to a standard ULA, where careful handling of cloud, disaster recovery, and non production deployment can lift the certified count well above the first estimate, still applies, but it is bounded. There is no value in driving the count above the ceiling, because the excess is not certified for free; it is trued up. The strategy shifts from maximise the count to land the count exactly at the cap, with a clean evidence file that supports every license up to the line.
| Deployment position | Standard ULA | Capped ULA |
|---|---|---|
| Below the implied count | Certify what you deployed | Certify what you deployed |
| At the cap | No special effect | Maximum free value, ideal landing point |
| Above the cap | Certify the full count | Excess trued up, often at list driven pricing |
| Best strategy | Maximise the certified count | Land at or just below the cap |
Take a capped ULA with a ceiling of four hundred processor licenses, figures indicative only. A buyer who measures and lands at three hundred and ninety certifies a strong, fully covered position. A buyer who lets deployment drift to four hundred and sixty certifies four hundred and faces a true up on the sixty excess, priced from list rather than from the original deal. Same products, very different exit cost, decided entirely by whether the cap was respected.
Three things deserve standing attention through the term. First, instrument the deployment against the cap so you always know how close to the line you are; the ceiling is only useful if you can see it. Second, treat corporate change as a scope risk, because acquisitions and new entities can push deployment outside a scope cap regardless of quantity. Third, read the true up clause early, not at exit, so the cost of crossing the line is a known number you can plan around rather than a surprise you absorb. A capped ULA is a perfectly reasonable instrument when it is managed against its cap. It becomes expensive only when the cap is treated as if it were not there.
Caps and perpetual structures are the two variations on the standard ULA, and they reward different strategies. Read what a PULA is and how it differs from a ULA for the perpetual variant, and the PULA mistakes that last forever for the errors that compound when an agreement has no clean exit. Our PULA guide is the pillar that frames perpetual and capped agreements together.
A capped ULA is an unlimited license agreement whose unlimited right is bounded by a ceiling, usually a maximum quantity of processors or users, or a limited product or entity scope. You deploy freely up to the cap, but deployment beyond it is not covered and is settled through a true up or a separate purchase. The cap also limits the count you can certify at exit.
Certification of a capped ULA can only convert deployment up to the cap into perpetual licenses. Anything you deployed above the ceiling is not automatically certified and typically has to be resolved separately, often at list driven pricing. The cap therefore sets both the ceiling on your free value and the line above which exposure begins.
A true up is the mechanism that settles deployment above the cap. When usage exceeds the ceiling, the contract typically requires the customer to purchase the excess, often at terms far less favourable than the original ULA pricing. Managing deployment so it lands at or below the cap, or planning the true up deliberately, is the core of capped ULA strategy.