AI FinOps: Controlling the unpredictable invoices

AI FinOps: Controlling the unpredictable invoices

I'll happily admit I'm a numbers guy. At the end of each month I go through my bank and card statements, check every line is genuine, note what's coming out next month and cancel anything I no longer need. It isn't glamorous, but it means next month's budget is built on something close to fact.

Technology spend used to be fairly similar. I saw most of the contracts, invoices and licence agreements in my role as an IT service manager. They were known and the variable elements were understood. The price and the unit, such as extra network bandwidth in Gbps, were predictable. Cloud consumption changed that. Variability increased, and the disciplines to manage it improved. IT FinOps, TBM and other cost management methodologies emerged to support the need to identify and control costs.

Now we've moved on again, and AI has introduced further variability into technology cost management. It's relatively well known that AI is charged through tokens and providers do publish their prices. However, it's now hard to see who is consuming the tokens, using which models, what they are trying to achieve and how quickly tokens are being used. The same input query can have a very different cost depending on the model used, whether the user is inside an allowance or in metered overage, the length of the preceding conversation and whether an agent has completed multiple steps in the background.

It becomes very hard to forecast AI bills on a monthly basis, especially once the different seat licences, usage allowances, credits, API access and expensed personal subscriptions are added to the list of difficulties.

We are moving further away from the capability to predict monthly technology spend. Whilst there has always been a need to understand the cost levers for technology spend, I think this has moved from being an activity done at key points in a contract to an everyday one. The aim shifts as well, the invoice may never be a number that can be forecast to the pound, but it can be one that lands within limits that have been set and understood.

The levers that organisations can look at to help set and monitor these spend ranges fall into three groups: Visibility, Control, and Design.

Visibility

• Attribution. Can AI usage be linked back to individuals and teams, or to applications behind an API?
  The frontier providers differ in what they report, although the gap has narrowed this year. The largest enterprise platforms now break usage and cost down by group and by individual user. Elsewhere the data is thinner, and in many cases it sits within invoices for services not labelled specifically as AI, so it is not necessarily easy to find. Collating and de-duplicating all of the information available on current AI usage and the associated cost is the first step. The second is attributing that cost to individual users or APIs wherever possible. This is sometimes achievable via the provider's dashboard. More often it requires some manual effort or third party software to map the usage accurately, particularly across more than one provider.
• Seat utilisation. Are all of the licences bought actually being used?
  This is not specific to AI but is very often the cause of ongoing, higher-than-expected invoices. The attribution data can be used to identify users with paid-for licences who are not using them. Where tokens are pooled this is less of a concern. Where they are not, the choice is between driving use through training or incentives and reducing the licence count. In my experience, removing seats that genuinely will not be used is often the fastest route to savings. The first step is to confirm the types of contract in place for AI, whether enterprise-wide, per-seat or consumption-based, and to check usage for anything that is not a blanket price. If tokens are pooled, it is worth checking whether the full allocation is being used.
• Usage patterns. Are the AI capabilities in use actually being used well?
  Tools that analyse individual usage can provide insight, although reviewing the content of individual conversations has privacy implications and needs careful thought. Anonymising the source is very often not enough. The content of conversations frequently points back to individual users. Where that can be resolved, the insight is valuable for understanding where AI is being used best, proving value and controlling spend. It is worth questioning how well the organisation really knows how AI is being used, and finding ways to concentrate activity where it is most likely to add value to the business.

Control

• Consumption model. Is it clear how each AI service is actually charged?
  Enterprise plans range from seats with a usage allowance, to shared credit pools, to a seat fee with all usage metered. Two questions are raised by this: are the seat plans appropriate for how the organisation actually uses AI, and what happens when a user with an allowance uses it up? Understanding the charging model in place, and assessing whether it is still appropriate for the organisation, is the starting point. For seats with an allowance, whether the user is stopped, allowed to continue at a cost per token, or able to request more should be a conscious decision rather than a default. Per-user overage visibility has improved on the major platforms during 2026, but it remains easier to control the behaviour proactively than to explain it or try to modify it afterwards.
• Spend limits and alerts. Have limits on AI spend been set at organisation, team and individual level, with alerts before they are reached?
  This has changed quickly. OpenAI added usage analytics and spend controls to ChatGPT Enterprise in June 2026, covering caps by workspace, team and individual. Anthropic added org-level and per-user spend limits for Claude Enterprise in July 2026, with admin alerts at 75% and 90% of the cap and an admin API to manage them. The controls are there but they do need opt-in and configuring, much like compute resources in cloud platforms. OpenAI's documentation states that usage limits and the workspace overage limit both carry a ‘No limit’ option, which for the overage limit means no cap is configured and eligible overage usage can continue and be billed. Understanding which controls each platform offers, and setting them in line with the organisation’s AI ambitions, is often the most important lever in this whole set.
• Contracts. Is it clear which contracts cover the organisation's use of AI, covering chat interfaces as well as API connections?
  The AI services signed up to, including allowances, overage costs, limits and invoicing, need to be understood well enough to be controlled. They often differ from retail offers and are more complex. Rates are usually tied to specific models, and billing often appears across multiple invoices, as mentioned earlier. The intent behind an AI contract matters: being clear about what users, and systems with API access, should be able to do and how spend will be managed, then making sure that is reflected in the terms. Given the pace of change, these need reviewing regularly. There is a trade-off, in that committed volume can often buy a better rate. However, flexibility and shorter terms are likely to be worth more than the discount at this stage of the market.

Design

• Model guidance and controls. Are users able to access any guidance on which model to use for particular types of task?
  High capability models used for relatively simple work tend to be a significant source of additional cost, or of frustration when tokens and access run out. This then compounds with reasoning depth settings, conversation length and mode (chat, co-work or agentic) to consume very different amounts of tokens for what appears to be the same request. Organisations need access to the skill set that understands how these factors affect token usage and can help author guidance for users, a simple example being starting a new conversation rather than continuing an existing one for a new topic. That guidance can now be backed by configuration as well, since model-level entitlements on the main enterprise platforms allow admins to pin particular models to particular roles. Guidance should be regularly updated, in line with the control recommendations above, to ensure that the organisation maintains a current view of AI capabilities, costs and usage best practice.
• Agents and API workloads. Is the organisation aware of where API access to AI models is being used?
  This includes developer tools, agents and automated integrations. For any organisation with developers using coding agents, my experience is that this is often a larger spend than the chat interface, a less predictable one, and often much less visible. Alongside addressing that visibility, design choices matter. Choices around context size, caching and batch processing can all have large impacts on token consumption and, even with the API reporting token usage, it is not always obvious where any cost sinks on individual projects lie. Organisations should look to build clear development standards around AI API use that exist in parallel with other AI guidance.
• User guidance, including personal AI. Are users clear on what corporate AI can and cannot be used for, and is that guidance easily available?
  Shadow AI is now common. As an indication, the PagerDuty Shadow AI Survey, published in June 2026, asked 1,250 office professionals in non-IT roles at organisations with revenue above $500 million across Australia, Japan, the UK and the US, and found that two thirds had used AI tools at work despite company policy restrictions. Shadow AI can be a tool put in place by a team or business unit without support from the technology team, or personal AI used by individuals on a work or personal device. Often it is the free version, which has no controls over data usage. Any shadow AI sits outside technology managed contracts, limits and reporting, so both the spend and the risk are invisible. Publishing clear standards is a good start: what business purposes personal AI can be used for, often education, advice and feedback on generic situations, and how it can be accessed. There should equally be guidance on what personal use of corporate AI is permitted, including what, if any, protection there is for personal information entered into a corporate AI chat interface.

Underneath all of these sits a question of ownership. If it isn't clear whether IT, finance or the business units consuming AI own the bill, the levers above often do not get used.

Ownership raises the harder question of value. Controlling cost is only half the picture, and without a view of outcomes it is difficult to justify any cost at all. This is where a lot of AI chargeback falls down. Allocating spend across cost centres by headcount or seat count produces a number, but no value measure. A budget holder can see what they have been charged and still have no way of knowing whether it is reasonable, and no lever to change it. In my experience the result is usually either a monthly argument about the allocation or an arbitrary cap imposed because the figure can’t be explained.

Defining value measures can be challenging as it can mean looking at outcomes at a more granular level, to ensure that the value can be linked to the AI capability. Some examples would be ‘cost per contact handled’ for a contact centre, ‘cost per case processed’ for a claims or case handling team or ‘cost per user story delivered’ for engineering. None of these are perfect, and the engineering one in particular is contested, but a number with a unit attached can be argued about productively in a way that an allocation cannot.

Of course, this only works where the outcome is countable and the spend is attributable to users or to systems calling the APIs. For general assistant use spread across a whole organisation, there is often no objective value measure and inventing one can impact productivity in the wrong way. In those cases showback with a usage pattern behind it is a more helpful starting point to drive discussion.

Thinking back to the bank statement, I’d suggest the standard for AI bills should be the same, that invoice recipients need to know:

• Rough monthly outgoing rather than to-the-penny predictability
• What changes they can make to impact the bill
• That they would recognise anything on there that has not been agreed to