A software subscription looks simple. You sign up, you pay monthly or annually, the service is delivered, and the contract seems to run itself. That apparent calm is precisely what should raise a flag. In a SaaS contract, price drift and risk rarely show up as a spectacular incident. They build quietly, through renewals, rising usage and features switched on without anyone fully measuring their reach.
This article does not approach licensing and software from the angle of copyright or intellectual property. It deals with what a contract manager can actually act on, namely managing commitments over time, a subject made more topical than ever by the arrival of artificial intelligence in vendors’ offerings, which has made day-to-day contract management more sensitive than it has ever been.
SaaS, licence or subscription: what are we actually talking about?
Three concepts are regularly confused, even though they create entirely different contractual relationships. First, the perpetual licence is a right of use acquired once and for all. This is the model of the old Microsoft Office CDs you bought in a shop, installed on your machine and then used for as long as you liked. The company pays up front, installs the software in its own environments and runs it without depending on the vendor to keep it working. Maintenance and updates fall under a separate contract, but the right of use remains acquired.
The so-called “on-premise” subscription, found in particular in sensitive sectors, introduces rental rather than purchase while keeping a local installation (hence the name). The software is still hosted by the client, but the right of use becomes temporary and conditional on a recurring payment.
SaaS, for Software as a Service, goes further. The software is no longer installed at the client’s site; it is hosted and operated by the vendor, then consumed remotely. Where you once bought an Office CD in a shop, you now register your bank details on a Microsoft (or other) platform and pay for as long as you use the service. The company no longer buys a product; it subscribes to a service whose availability, evolution and hosting rest entirely with the supplier.
In practice, few organisations use only one model. Most manage a hybrid estate where legacy licences sit alongside recent subscriptions, whether on-premise or SaaS. That coexistence is a difficulty in itself, because it forces you to reason along two opposing risk logics at the same time.
Changing models have moved the risk
Contractual risk did not disappear when the perpetual licence gave way to SaaS (or, put another way, when software became dematerialised); it simply moved. Every time the usage model evolved, the point where exposure concentrates moved with it. Two successive shifts are worth pausing on, because they call for different reflexes.
The first shift runs from the perpetual licence to SaaS. With a licence, risk was concentrated at the point of purchase. Once the decision was made and the right of use acquired, the company controlled its own operations, even if that meant ageing with a frozen version. SaaS moves that risk into continuous execution. The service lives, changes and grows, and dependence on the vendor sets in over time. The balance of power shifts as well. The more deeply usage is embedded in processes, the more expensive it becomes to leave, and the stronger the vendor’s leverage at every renewal.
The second shift is more recent. It separates pre-AI SaaS (broadly 2000 to 2020) from the SaaS we know today, in which AI finds its way into almost every offer. Questions that were theoretical yesterday are becoming concrete. The very sustainability of some business models is open to question when the price of a service depends upstream on the per-token cost charged by large language model providers. Public policy decisions can restrict access to certain features, and recent news (in the last few days, with Anthropic cutting off access to the Fable 5 model for all “non-Americans”) has shown that this prospect is anything but abstract. Finally, the build-or-buy trade-off is no longer settled solely at the initial decision. Building your own AI-tooled solution, out of reach for most until recently, is becoming a credible option, and that changes the very nature of the commitment you are prepared to make. Behind all this, one constant remains: the value the software creates, the value a high exit cost can destroy, and the flexibility you have (or have not) kept for yourself during execution.
Five points to watch in contract management
Billing metrics
The first change to observe (and to factor in) is that the headline price is no longer the right indicator, because price lists now move so fast!
What deserves attention is the induced cost, in other words what the billing unit actually triggers once the service is in production. We have moved from the named or concurrent user, readable and predictable, to consumption metrics of which the token is today the clearest example.
Switching on an AI component means accepting billing by volume consumed, which is by nature volatile and hard to model in advance. Understanding the metric is therefore no longer about negotiating a number of seats, but about anticipating a consumption trajectory. That trajectory immediately raises the question of how it can be verified, which we come back to below.
Price escalation and renewal terms
Beyond the metrics discussed above, price escalation and renewal are one of the biggest sources of (excess) cost. Annual indexation, increase clauses framed far too loosely, automatic renewal, termination notice periods calibrated in the vendor’s favour: each of these mechanisms looks harmless taken on its own, yet together they lock you into a relationship you no longer want on economic grounds.
The guiding principle is simple: keep one or more concrete exit routes open, and cap price increases with clear thresholds. The contract manager must work to make termination rights concrete, measurable and genuinely exercisable, so as not to end up a prisoner of the contractual relationship.
Service commitments and service levels
Under the previous SaaS model, indicators such as availability or uptime rates did exist, but in practice they were rarely monitored. That laxity has no place once entire swathes of activity are automated and value creation comes to depend on AI.
Availability then stops being a cosmetic indicator and becomes a measure of real operational risk and, more broadly, a key factor in service continuity. This level of requirement is not drafted alone in a corner. It is built with users, the business and the vendor, so that together you can assess what really happens when the service goes down, and calibrate commitments that contain that risk instead of sidestepping it.
Usage and compliance audits
The classic risk remains. The vendor keeps an audit right, true-ups for over-deployment can be heavy, and indirect access, where another system consumes the service, remains a billable use that many discover far too late. On top of that sits an informational dependency specific to SaaS: the platform measures everything, and the client needs its own visibility over actual consumption in order neither to overpay for dormant licences nor to find itself non-compliant.
AI adds a third level, probably the trickiest of all. Token consumption is data produced by the vendor, and it is difficult for the client to verify, if not impossible altogether. You are billed on a meter you do not hold, cannot replicate, and have (almost) no independent means of challenging. The asymmetry is of an entirely new kind. It is no longer the vendor auditing the client, nor the client struggling to audit itself; it is the client having to rely on a measurement imposed on it. Where verification is impossible, vigilance shifts to what the contract can require, namely transparency on the counting method, accessible logging, caps and alerts, a right of reconciliation and, where feasible, a challenge mechanism.
Reversibility and control of switching costs
The underlying question is not only whether you can leave, but at what price, and in what state you get your data back. In what format it is returned, within what timeframe, with what documentation, and at the cost of what reintegration effort. These conditions, far more than the termination clause itself, determine the real cost of a change (leaving aside the cultural, or change management, dimension). Poorly negotiated reversibility turns a theoretical freedom into dependence in fact. We have devoted a full article to this subject, and in a SaaS context it takes on particular sharpness.
The contract manager must get involved upstream
These five points share a common denominator: none of them can usefully be handled under pressure. The metric has to be understood before signature, the exit window is negotiated while you still have a choice, service commitments are calibrated before go-live, and reversibility conditions are set when you enter the relationship, not when you are trying to get out of it. It is therefore essential for the IT contract manager to be part of the pre-signature phases of the contract lifecycle, rather than looking only at execution.
A SaaS contract (setting aside bespoke development and integration) is negotiated and signed upstream; once it is signed, all that is left is to live with it. If the contract manager confines themselves to the execution phase, their impact can quickly prove negligible, because the agreed contractual terms already limit their scope and their levers.
More broadly, this evolution in SaaS contract models is helping to reposition the IT contract manager. Reducing the role to administrative support once the contract is signed was never entirely fair, and it is becoming less so. In a subscription economy where the build-or-buy trade-off is constantly replayed, and where the value of a service is created or destroyed during execution, the contract manager becomes the guarantor of that value across the whole life of the contract. That means engaging with technical, finance and business teams as much as with the vendor, and thinking in terms of software assets and long-run costs, not just clauses.
Conclusion
A SaaS contract is a living thing. Its value is not captured at signature; it is managed over time, as usage spreads, prices move and features change. AI invented none of this mechanism; it has accelerated it and made it more visible. Where mastering these contracts was yesterday one good practice among others, it is becoming a condition of performance, and that is excellent news for contract management.