From Budgets to Bills: What the Shift to Usage-Based Software Spend Really Means for Finance Teams

Software used to be a simple line on the balance sheet. You bought a licence, you owned it, and your accountant knew exactly what to do with it. Then everything moved to subscriptions, and for a while that felt like progress. Predictable monthly costs, no big capital outlays, easier to cancel if something stopped working.

Now a third model is taking over, and it is making finance teams nervous for good reason. Usage-based pricing means your bill next month depends on how much your team (or your AI systems) actually used the software. That is genuinely harder to budget for, and most procurement processes were not built with it in mind.

The three eras of software spend

To understand where we are, it helps to see the full arc. Not just for historical interest, but because the ghost of each model is still present in most organisations' software estates right now.

A short history of how software hit the books, from capex to opex (optional, click to expand)

Before cloud software, buying enterprise applications meant writing a large cheque up front. Oracle databases, SAP implementations, Microsoft Office on perpetual licences: these were capital expenditure. Amortised over three to five years, approved through a formal capex process, and owned outright. The CFO knew exactly what had been spent. The IT team knew what they were running. It was slow, expensive to change, and the upfront costs could be eye-watering, but the numbers were stable.

The SaaS era, which accelerated through the 2010s, reframed software as an operating expense. Salesforce, Workday, HubSpot, Slack: you paid a monthly or annual subscription per seat, and it showed up in opex rather than on the balance sheet. This made procurement faster (no capex approval needed in many organisations), made it easier to try things, and gave finance teams a predictable recurring cost. The trade-off was that you never owned anything. But for most buyers, that was worth it.

The usage-based model has been around longer than people realise. AWS launched its pay-per-hour EC2 model in 2006. Twilio, Stripe, and Snowflake all built their businesses on consumption pricing. What has changed recently is that this model has moved from infrastructure and developer tools into everyday business software and, critically, into AI services. OpenAI's API charges per token. Many AI writing, coding, and data tools now bill on a per-action or per-call basis. The bill is no longer fixed. It is a function of how much the software gets used.

The reason this matters now is that AI tools are the fastest-growing category of software spend in most organisations, and many of them, particularly API-accessed AI services, are usage-based. When a team starts using an AI assistant that costs per request, or an AI agent that bills per task completed, the finance team has a new kind of problem: the cost is tied to behaviour, not headcount.

Why usage-based pricing breaks the old procurement playbook

Traditional SaaS procurement is fairly well understood. You get a quote for N seats, you negotiate a discount for an annual commitment, legal reviews the DPA and the data processing clauses, and procurement raises a PO. The number on that PO is the number you budget for. Done.

Usage-based pricing does not work that way. The vendor cannot tell you what you will spend because they do not know how much you will use it. The best they can offer is a price per unit (per API call, per document processed, per agent task completed) and possibly a committed spend tier that buys you a lower rate. Your actual bill emerges from how the software gets used day to day.

This creates three specific problems for finance teams.

Forecasting becomes genuinely hard

With seat-based SaaS, you forecast by headcount. With usage-based pricing, you forecast by activity. How many API calls will your developers make? How many documents will that AI tool process? How many tasks will your agent complete in a month? Unless you have historical data for a similar workload, the answer is usually a guess.

Vendors will often offer benchmarks ("customers of your size typically spend around X"), but those benchmarks are built on their interests as much as yours. Take them as a starting point, not a commitment.

Costs can spike without anyone noticing

In a seat-based model, cost overruns are obvious. You added people, you pay more. In a usage-based model, a single team or workflow change can generate a significant bill without any procurement decision being made. A developer runs an expensive script in a loop. A new business process sends ten times more data to an AI service than expected. A pilot expands informally across two extra departments.

None of those are reckless decisions. But each of them can produce a bill that surprises the finance team at month end.

Committed spend tiers add a new negotiation dimension

Many usage-based vendors offer volume commitments: promise to spend a certain amount over twelve months and get a lower per-unit rate. This looks attractive, and often is. But it means you are now underwriting a consumption forecast. If your usage comes in below the committed tier, you have paid for capacity you did not use. If it exceeds it, you are paying the on-demand rate for the overage, which can be significantly higher.

This is a different kind of procurement risk from anything that existed in the capex or flat-subscription era.

What good looks like now

The organisations handling this well are doing a few things consistently.

They treat usage data as a finance function, not just an engineering one

For SaaS tools, usage data was mostly the concern of the IT or ops team. For usage-based AI tools, it needs to sit in finance's line of sight. That means getting vendor dashboards set up with appropriate access, setting up budget alerts before you need them, and building a monthly review into the normal accounts process.

They pilot with hard caps

Most major AI platforms offer budget alerts and spend monitoring, but hard caps that actually stop billing vary by platform and are not universal. OpenAI, for example, moved away from a hard monthly budget cap and now sends alerts only; AWS Budgets likewise alerts but does not halt spend by default. Check what each platform actually enforces before relying on a cap. Where hard limits are available, use them. When a team is piloting a new AI tool, put the tightest control the platform supports in place before they start. It limits downside, and it also forces the team to be deliberate about what they are building rather than running experiments with no cost awareness.

They ask vendors for sandbox or flat-rate pilot options

Not all vendors offer these, but it is always worth asking. A fixed-fee pilot for the first sixty or ninety days lets you gather real usage data before you commit to a pricing model. That data is what you need to build a credible forecast and negotiate sensibly.

They reframe the comparison

Usage-based AI spend is easiest to justify when it is compared to the cost of the alternative, not to the cost of the previous software budget. If an AI agent handles work that would otherwise require a contractor or a full-time hire, the right comparator is the employment cost, not the SaaS subscription it replaced. Finance teams that make this comparison accurately tend to approve AI spend more readily, because the ROI is often clear once you frame it correctly.

The questions worth asking before you sign

Before committing to any usage-based AI tool or service, the procurement conversation should include at least these:

• What is the unit of billing, exactly? (Per token, per API call, per task, per document? Make sure you understand what triggers a charge.)
• What does a typical month look like for an organisation our size and use case?
• What alerts or caps can we put in place to prevent unexpected spend?
• What happens when we exceed a committed tier? What is the overage rate?
• Can we start on a metered plan with no commitment and move to a committed tier once we have three months of usage data?
• How does pricing change if we integrate this into multiple workflows or teams?

None of these are unreasonable questions. Any vendor worth working with will have clear answers.

This is not going back to subscriptions

It is tempting to think that the market will eventually standardise on flat-rate pricing again, because flat rates are easier to budget for. That is probably not how this plays out. Usage-based pricing aligns vendor and customer incentives in a way that flat subscriptions do not. If you use the software more and get more value from it, the vendor earns more. If you use it less, you pay less. That alignment is genuinely appealing to both sides, even if it makes forecasting harder.

The practical response is not to wait for the market to change. It is to build the internal capability to manage variable software spend: better tagging, better dashboards, tighter approval flows for new tool adoption, and finance teams who understand what they are buying when they sign off on an AI service.

The tools are not going back to being simple. The organisations that adapt their procurement and budgeting processes to match will have a meaningful advantage over those still trying to force usage-based spend into a capex or flat-subscription framework.

How AI with Ash can support you

If you are trying to make sense of what AI tooling is actually worth adopting and what the real cost looks like when you model it properly, that is exactly the kind of conversation worth having early. A clear picture of the costs, the alternatives, and what you are actually automating makes the procurement decision much simpler.

Book a call and we can work through the numbers together before you commit to anything.