Explaining Cloud and AI Spend to a CFO

“Beware of little expenses; a small leak will sink a great ship.”
— Benjamin Franklin, The Way to Wealth (1758)

Explain cloud and AI spend to your CFO as a cost per unit of what the business sells, forecast it as a range with named drivers, and show committed spend separately from variable spend. Do those three things every month, in the same format, and the bill stops being a debate. Skip them, and finance will eventually manage the bill for you, with a blunter instrument than you would choose.

Most engineering teams do something else. They treat the cloud bill as a technical artifact and explain it in technical terms: which service grew, which instance family, which region. When finance pushes, the answer is "growth", or a cost-cutting sprint that removes ten percent and quietly returns within two quarters. Neither answers the question the CFO is actually asking, which is whether the business got more expensive to run or just bigger.

Picture a Series B company whose cloud line has grown steadily for a year and then jumps 40% in one month, the month a new AI search feature shipped. The CFO's email asks two things: why, and will it keep happening? A screenshot of the billing console sorted by service answers neither. The CFO does not care that the cost sits in a vector database rather than in compute. They care about margin, runway and whether next quarter's plan still holds.

Talk in unit costs, not invoices

A total bill moves with growth, so on its own it tells finance almost nothing. What they need is the cost of serving one unit of what the business sells. Pick the unit that matches the revenue model: cost per customer per month for subscription software, cost per transaction for a payments business or a marketplace, cost per thousand API calls for a developer product. For AI features the unit is usually cost per answer, per document processed or per conversation.

With that number, the 40% jump becomes a different sentence: "Customers grew 30%, and cost per customer rose by a few dollars a month because the new search feature makes a model call on every query." Now the CFO can set the figure against the plan's price, check it against gross margin and ask the follow-up that matters. Will the per-customer cost come down as the feature is tuned, and by when?

Engineering leaders often resist this, and the objection deserves a fair hearing. Allocation is never exact. Shared clusters, observability and the platform team's tooling serve every product, and any rule for splitting them is partly arbitrary. That is true, and it matters less than it seems. Finance allocates rent and shared headcount with imperfect rules every quarter and the business still runs. What makes an allocation useful is that it is written down and stable, so the trend means something. An imperfect unit cost tracked for a year beats a precise one calculated once for a board meeting.

Getting the number is mostly plumbing: costs tagged or allocated by product and environment, and usage data (customers, transactions, model calls) in the same place as the bill. The FinOps Foundation framework covers the mechanics, and its FOCUS specification gives billing data from different providers a common shape, which starts to matter once you buy from more than one cloud or model provider. The tooling is not the point, though. The unit cost is the output finance needs, and it belongs in the same place as the other unit economics in a board report built on decisions rather than vanity metrics.

AI spend needs extra care, because one cost per answer hides several moving parts. A single user question can trigger retrieval, two or three model calls, a retry and an evaluation pass. Prompts grow as features mature. Model prices change, sometimes down, sometimes up because the team moved to a larger model to fix a quality problem. Report cost per answer as one number and keep the breakdown ready, since the CFO's next question will be why it moved. Teams that already run AI features as production systems with proper telemetry have most of this data; the remaining work is joining it to the bill.

Forecast in ranges and name the drivers

A single-number forecast for cloud spend is a promise you will break. Usage depends on sales, on customer behavior and on features nobody has built yet. Give finance a range with the drivers named: "Between X and Y next quarter. The low end assumes current customer growth and no change in how the AI feature is used. The high end assumes the enterprise pilot converts and those users query at the rate the pilot users did."

Finance teams sometimes push back on ranges, and their reasoning is fair. Budgets are single numbers, and a range can look like engineering avoiding commitment. The answer is to give both: a planning number for the budget and the range around it, with the drivers that would push the result to either end. The budget gets its number, and the CFO learns which business events to watch. A result inside the range is a forecast that worked rather than a miss to explain, and a result outside it points straight at the driver that moved.

Ranges are wider for AI features than for steady infrastructure, and it is better to say so plainly than to hide the uncertainty in a padded number. A new feature has no usage history, and per-user consumption is uneven: Anthropic’s cost guidance for its own coding assistant says per-developer costs “vary widely” with model choice and usage patterns, and it added weekly limits in 2025 aimed at a small minority of subscribers running it around the clock. Say what you will measure in the first month and when you expect the range to narrow. This is the same discipline that goes into budgeting for a new product feature, applied to running the feature rather than building it.

Separate committed spend from variable spend

Finance thinks in two buckets, and cloud spend fits them once it is sorted. Committed spend is contracted regardless of usage: reserved capacity, savings plans, committed-use discounts, enterprise agreements with an AI provider that carry a minimum. Variable spend is on-demand usage that rises and falls with the business.

The two carry different risks. Commitments lower the unit price and raise the floor: if usage drops, you pay anyway. Variable spend keeps you flexible and costs more per unit. How much to commit is a financial decision as much as a technical one, so it belongs in a shared conversation, not in a console setting one engineer changed in March. Bring finance a short view: how much of next year's expected baseline the commitments cover, what the discount is worth, and what you would owe if usage landed at the low end of the range. Framed that way, it becomes an asymmetric bet with a known upside and a bounded downside, which finance knows how to evaluate.

AI makes this sharper. Provider minimums, reserved throughput and prepaid credits are all commitments, and they are easy to sign during a pilot while enthusiasm is high. Treat them the way finance treats any other contract with a floor. The same reasoning applies to choosing the provider in the first place: the build, buy or wait decision at each stage includes what leaving would cost, and a multi-year minimum is part of that cost.

Make it a recurring conversation

Trust with finance comes from repetition, not from one good presentation. A short monthly review does the job: the unit cost trend, actuals against the forecast range, any change to commitments, and the one or two things engineering is doing to bend the curve. Keep the format fixed so the CFO learns where to look, and bring bad news before it shows up in the ledger.

There is a reasonable case against this, usually from leaders at smaller companies: a monthly cost review is overhead, and engineering time is better spent on the product. At seed that is often right, which is why the stage call below matters. Past that point the review costs an hour a month. The alternative is a CFO who learns about spend from the invoice and responds with a hiring freeze or an across-the-board cut, and either one costs far more than the hour.

What good looks like. The CFO can explain the cloud and AI cost trend to the board without calling you. They know which business events move it, and they have seen engineering take cost out when it mattered. When you ask for budget for a platform investment, the request lands with someone who already understands your numbers, which is most of the work in making the data-driven case for growing a team.

What bad looks like. Finance learns about spend from the invoice. Every increase is explained as growth, with no unit cost to back it. Cost-cutting happens in panics, usually by switching off things that were there for a reason. The relationship turns into a negotiation, and technical decisions start getting made in spreadsheets by people who cannot see the trade-offs.

How it changes by stage

Seed. Cloud spend is usually small next to payroll, and the CFO is often the CEO. Know the monthly infrastructure and AI burn, know roughly what one customer costs to serve, and avoid long commitments while the product is still changing shape. Engineering time spent on cost tooling at this stage is usually a poor trade. A spreadsheet updated once a month is enough.

Series A and B. Gross margin starts to matter for the next raise, and investors will ask about it. This is when unit costs earn their keep. Allocate cost by product, start the monthly review with whoever owns finance, and make the first deliberate commitment decisions on a baseline you now understand. If AI features ship at this stage, track cost per answer from the first day; retrofitting it later is painful. Shared metrics help here too, because KPIs that product and engineering own together turn cost into a product trade-off rather than an engineering problem to be policed.

Later stage. The conversation becomes formal. Budgets are set annually, departments see showback or chargeback for what they consume, and commitments are large enough to negotiate seriously. Forecast accuracy becomes a metric finance tracks. A dedicated FinOps function often appears, and the engineering leader's job shifts to owning targets and trade-offs rather than producing reports.

At every stage the underlying skill is the one behind a CTO who understands how the business makes money: translating the technical system into the numbers the leadership team runs the company on. Cloud and AI spend is one of the few places where that translation is literal.

The question for your next leadership meeting: if the cloud bill jumped 40% next month, could you tell the CFO within a day how much of it was growth and how much was the business getting more expensive to run?