Software Pricing Is Drifting From Per-Seat to Per-Use, and Budgets Are Not Ready

Business software settled for two decades on per-seat pricing, and its dominance owed as much to procurement convenience as to any pricing theory. A per-seat contract produces a number known in advance, renewed annually, approved once and forgotten — which suits budgeting cycles, makes multi-year planning tractable, and gives the buyer a single lever to pull if costs need cutting. The correspondence between what was paid and what was used was always poor, and nobody minded much, because predictability was worth more than accuracy. AI-heavy features are eroding that arrangement, because their underlying costs are genuinely variable. A vendor whose own costs scale with usage cannot offer unlimited use at a flat rate without either pricing for the heaviest users — making the product expensive for everyone else — or accepting an uncapped liability. The result is a drift toward hybrid structures: a platform fee plus consumption, credits that expire, tiered allowances with overage. Each is a reasonable response to real cost structure, and each transfers variance to the buyer. The buyer's problem is organisational rather than financial. Approval workflows, departmental budgets and procurement thresholds were all designed around a fixed annual figure, and a bill that varies by a meaningful percentage month to month does not fit them. Teams respond by imposing internal caps that make the tool unreliable at exactly the moments it is most useful, or by not imposing caps and discovering the consequence at quarter end. Neither is a pricing problem; both are a forecasting problem in an organisation with no instrument for forecasting it. The practical response that works is treating consumption software the way infrastructure spend is already treated — with usage visibility per team, alerting on trajectory rather than on the invoice, and a named owner for the line. That is ordinary discipline in cloud cost management and almost entirely absent in application software procurement, because it was never needed. It is needed now, and the gap between the two practices is where the unpleasant surprises are currently accumulating.