From Shelfware to Token Overuse: The New Economics of Software Inflation

For years, one of the most familiar problems in software procurement was shelfware. Companies bought licenses, distributed them widely, and later discovered that many users barely used the software, had been allocated premium editions they did not need, or had access to applications that duplicated functionality already available elsewhere.

The procurement response was relatively straightforward: analyze utilization, remove inactive accounts, downgrade unnecessary license tiers, eliminate redundant applications, and adjust the license mix at renewal. The underlying commercial problem was underutilization. The organization had already committed the money, and procurement was trying to determine whether it had extracted enough value from that commitment.

That problem has not disappeared. But consumption-based pricing introduces the opposite risk: software can be heavily used and still represent poor value.

AI tokens, API calls, cloud capacity, automation runs, and other consumption metrics increasingly determine what an organization ultimately pays. Usage can therefore grow faster than anticipated without producing a corresponding increase in business value.

For software procurement, that changes the game considerably.

Shelfware Was Easier to Understand

Seat-based licensing produces waste, but at least the financial exposure is relatively predictable. If a company buys 2,000 licenses at a fixed monthly price, it broadly knows its annual commitment before signing the contract.

The commercial uncertainty is therefore mostly about value rather than cost. Will enough employees use those licenses, and will they use enough of the functionality to justify what the organization has already agreed to pay?

That is why traditional SaaS optimization concentrated so heavily on utilization. Procurement and ITAM (IT Asset Management) could identify inactive users, expensive license tiers with low adoption, and redundant applications. At renewal, this information provided a basis for reducing quantities, changing license tiers, or negotiating better terms.

Consumption pricing changes the equation. The initial commitment may be relatively small, but the eventual cost depends on what users, systems, and increasingly autonomous processes actually do.

The organization therefore needs to understand more than whether the software is being used. It needs to understand what drives consumption, how quickly it can scale, and what happens in the background when automated processes start generating costs without immediate human intervention.

This does not make consumption pricing undesirable. Paying for what is actually consumed can be more rational than buying capacity that may never be used. Still, it shifts some commercial risk from unused capacity to uncontrolled demand.

AI Changes the Economics of Adoption

AI makes this shift particularly visible because consumption varies dramatically between users and use cases. One employee may occasionally use an AI assistant, while another may generate substantially more prompts, choose more expensive models, or embed AI into workflows that run continuously in the background.

The distinction becomes even more important as organizations move from individual LLM use toward agents and automation. Human activity is constrained by working hours, attention, and the physical ability to interact with a system. Automated activity is not constrained in the same way.

A poorly designed or rapidly scaling process can generate thousands or millions of backend transactions without anyone consciously deciding to incur the associated cost overrun. The software is being used; adoption can look excellent, but the invoice can look dramatic.

That creates an important contradiction for procurement.

Under a fixed-price SaaS license, higher adoption generally improves the economics because more value is being generated from an expenditure that has already been committed. Under a consumption model, higher adoption can increase both value and cost. Adoption alone therefore is no longer evidence that the commercial model is working.

The relevant question becomes whether the additional consumption produces sufficient additional business value.

Software Inflation Is Bigger Than Supplier Price Increases

Token overuse is only one part of a wider problem: software inflation.

The obvious form is price inflation, where suppliers increase subscription prices. But total software expenditure can rise even when the negotiated unit price remains unchanged.

Volume inflation also occurs as organizations add employees, transactions, or workloads. 

Feature inflation occurs when customers progressively move to premium editions, add optional modules, and adopt functionality not included in the first requirement.

Portfolio inflation brings another layer. Applications move between portfolios, new solutions are introduced, responsibilities shift between business units, and the effective software estate expands even when individual contracts appear controlled.

Finally, consumption inflation occurs through AI tokens, API calls, cloud resources, automation capacity, and other metered activities.

These different forms of inflation matter because they require different procurement responses. If the supplier has increased its price, negotiation may be appropriate. If expenditure is increasing because the organization has added unnecessary functionality, expanded demand, or allowed uncontrolled consumption, another two percentage points of renewal discount will not solve the core problem.

In those situations, procurement has to challenge internal demand as rigorously as it challenges external supplier pricing.

In June 2026, software inflation surged to 16.4%, significantly outpacing the US Consumer Price Index, which stood at 3.5%, highlighting a rapid increase in software costs compared to general inflation.

Annual License Reviews Are No Longer Enough

Traditional program optimization often concentrated on the period immediately before renewal. Procurement reviewed usage, challenged inactive licenses, and adjusted quantities before negotiating the next commitment.

That rhythm becomes less effective when cost is generated continuously. By the time excessive consumption becomes visible during an annual review, the organization may already have incurred months of unnecessary expenditure.

This does not mean procurement should monitor every token or API call. It means the organization needs regular visibility into the operational drivers that materially influence cost and must know who is accountable when those drivers change.

Users also need to understand the economic consequences of their choices. Selecting a more expensive model, creating unnecessarily complex prompts, running repeated automated processes, or activating resource-hungry agents can all affect consumption even when the underlying business requirement has not changed.

The distinction between productive and unproductive growth is therefore critical. If consumption rises because a successful process is handling more customers, decreasing manual work, or improving service, higher expenditure may be entirely justified.

If consumption rises because workflows are poorly designed, users have no incentives to control usage, or nobody understands what is happening in the backend, the same growth represents waste.

The relevant control model is therefore not simply usage versus cost. It is usage, cost, and business outcome.

Start With Benefits, Not Adoption

This becomes especially important when evaluating AI business cases.

Organizations should distinguish between benefits created specifically by AI and benefits that would have resulted from the underlying process redesign anyway. If cycle time improves because a previously manual process has been digitized, it is misleading to attribute the entire benefit to AI merely because AI forms part of the final solution.

The same discipline should apply after implementation. Increased adoption is useful only if it leads to financial, operational or performance benefits sufficient to justify the additional consumption.

This is where procurement can make a useful commercial contribution. Rather than asking simply whether employees are using the product, it can ask whether greater usage is improving the outcome that originally justified the investment.

Traditional License Discipline Still Matters

The move toward consumption pricing does not make conventional license optimization obsolete. Many suppliers now combine subscriptions with additional consumption charges, which means organizations can suffer from underutilization and overconsumption at the same time.

A company can have hundreds of unused premium licenses while another part of the same platform generates rapidly increasing token or API charges. Managing one problem does not remove the other.

Role-based license segmentation therefore remains important. Not every employee needs the same tier, premium functionality, or AI capability simply because standardizing user profiles makes administration easier.

Roles can also be more useful than departments when defining consumption profiles. Business analysts working in IT, Procurement, and Finance may have similar requirements even though they sit in different organizational structures. At the same time, two employees in the same department may use the technology in completely different ways.

Trials require similar discipline. Experimental licenses should have an owner, an end date, and defined criteria for wider deployment; otherwise, supposedly free or temporary pilots can quietly become permanent subscriptions without a deliberate investment decision.

Consumption Needs Financial Guardrails

Variable pricing requires controls that mattered less when most software spending was fixed in advance.

If the platform permits, organizations should consider usage alerts, quotas, budget thresholds, and consumption caps. The objective is not to prevent productive use but to make rising expenditure visible early enough for someone to decide whether the additional consumption remains worthwhile.

This becomes especially important with automated activity. Thousands of employees can create incremental cost through personal actions, but autonomous systems can create the same exposure through millions of transactions that nobody sees.

Forecasting also needs to change. A software budget based primarily on historical license counts becomes progressively less reliable when future expenditure depends on transactions, tokens, agents, or API activity.

Procurement and Finance therefore need to identify the operational variables that drive consumption and model how changes in those variables affect expenditure.

Scenario analysis can be particularly useful before commitment. A pricing model that looks attractive at today’s consumption level may look very different if adoption doubles or triples, particularly once the organization has integrated the technology deeply enough that switching becomes difficult.

The commercial evaluation should therefore include not only the business case but also the economics of successful adoption.

Understand What the Supplier Is Charging For

Consumption pricing introduces another question that procurement should not ignore: does the charging metric make commercial sense?

A supplier may charge per token, API call, or transaction because the metric is technically easy to measure. That does not necessarily mean the metric bears any meaningful relationship to the value the customer receives.

This matters because pricing mechanisms create incentives. If supplier revenue increases every time consumption increases while customer value does not, the commercial interests of the two parties gradually diverge.

The better model is not necessarily the cheapest unit price. It is a model in which supplier economics and customer economics remain reasonably aligned as usage expands.

That may require different mechanisms depending on the solution: committed-volume bands, decreasing unit rates, usage ceilings, alerts, alternative model choices, or commercial reviews triggered when consumption moves materially beyond the assumptions utilized in the original business case.

The objective is not to eliminate variable pricing. It is to avoid a commercial structure in which every successful increase in adoption automatically creates disproportionate supplier revenue regardless of the value being generated.

This is exactly the demand-management logic behind the Technology Procurement Framework used in the IT Procurement Foundations course: first make software demand and consumption visible, then optimize licenses, features, models, and usage, and only then negotiate the commercial structure. A lower unit price cannot compensate for shelfware, unnecessary premium functionality, or consumption that grows faster than the value it creates.

From Maximum Adoption to Productive Usage

Consumption-based pricing is not inherently better or worse than subscription pricing. It solves one problem of unused capacity, but introduces another by making future expenditure dependent on usage that may be difficult to predict.

Software procurement therefore needs a wider view of optimization.

For years the discipline concentrated on finding licenses that nobody used. The emerging challenge is more complicated: organizations also have to identify usage that grows faster than the value it creates.

The objective should consequently be neither minimum usage nor maximum adoption. It should be economically productive usage — software consumption where additional expenditure continues to produce additional business value at an acceptable rate.

That requires traditional license discipline to remain in place. Still, it must now be combined with stronger demand management, role-based allocation, controlled experimentation, consumption guardrails, scenario modeling, and a better understanding of how supplier pricing converts operational activity into cost.

Shelfware taught procurement to ask whether software was being used.

Consumption pricing requires another question:

Is the additional usage still worth what we are paying for it?