Getting ready for the questions finance will ask
For a shockingly long time, token spend was able to climb to six figures in a quarter without much of the formal approvals that something like new headcount typically required. Finance departments have finally seemed to take notice.
This means your next AI budget request may be reviewed in the same way a new hire would be. You should be expecting three core concerns from finance: What will this budget deliver, and by when? What else could this money buy? How will we know it’s working before the money is gone?
Get your answers right and you get the budget. Get them wrong and every team’s token spend gets capped, including the engineers already getting real value from it.
What finance expects an AI budget to deliver
Most of what you spend on tokens is everyday usage across the whole team, and finance will judge that over time on cost per outcome. An increase is different. If you are asking for a notable jump, it probably pays for a few specific bets that can succeed or fail, and those get released in stages, as the evidence section below explains.
Spend alone says almost nothing about either one. The same monthly token bill could belong to your strongest engineer or to someone who needs help, and the bill can’t tell you which.
How do you justify a six-figure AI token budget?
Justifying a six-figure AI budget comes down to proportion: whether the amount is the right size for the work it pays for.
Executive sign-off tells finance the work is aligned with goals. It doesn’t tell them the spend is proportionate, and nobody expects a precise return on R&D, but they do expect you to argue your ask well. It is the same conversation engineering leaders have always had about a roadmap: with this budget, here is what I can deliver, and with more, here is what else.
Structure it with a cost per outcome, not a total. Start with what a shipped feature, a completed migration, or a retired class of incidents costs today in engineering time and tooling. Then show the AI-assisted version with tokens included. Tokens, tools, and people all feed the same outcomes, so price them together, and treat outcomes per dollar across all three as the number to watch. If you don’t have that baseline, say so, and make building it part of the first stage of work. A rough cost per outcome beats a total with nothing to divide it by.Write success as outcomes with dates, then, for your most expensive discrete bets, propose a checkpoint after the first tenth of planned spend. Say now what you expect to have seen by then, and offer to refactor the total ask if the results aren’t there. A staged release also gives you the evidence to ask for more later, which matters because some teams are underspending rather than overspending.
What should you measure to justify AI spend?
Be careful about what you count.
Spend, usage, and volume of code are inputs, and they say little about results. What finance wants to see is what got delivered: the Jenkins migration finished, a feature in front of a design partner by mid-May, review turnaround cut on one named workflow. Code sitting on a laptop is not an outcome. Code in production and in front of a customer is.
Outcomes are the shared unit that ties engineering activity to business value, and they are the one thing engineering and finance can read the same way.
Alternatives and offsets
Where should AI token spend come from in your budget?
When you ask finance to fund more AI token spend, the question they put back to you is which existing line gives way. Finance will always start with the money itself, and what they are really asking is what you are willing to give up.
If the spend comes out of an existing budget, the honest answer is usually hiring: a backfill that waits until Q3, two open requisitions that slip by a quarter. Name them, with dates. If it sits on top of a number you already committed, expect to be asked for an offset, either a cost you are cutting or revenue the work brings in. “It’s strategic” won’t allay their concerns.
Bring a one-page view of your whole engineering budget either way. A six-figure ask sounds daunting on its own but feels much smaller beside a payroll line in the millions.
Is AI spend cheaper than hiring engineers?
Finance may want to treat a hire and a token budget as substitutes, and they mostly aren’t. A new engineer adds one person’s output to one team, after a quarter of recruiting and another of onramp. Tokens go to everyone you already have, on every project they touch. So the question worth answering is whether your current team ships more per engineer-month with the budget than without it, and that is easiest to show when spend on tokens, tools, and people sits in one view.
If AI comes out more expensive per outcome, meaning the cost of each shipped feature or completed migration with tokens included, and you still think it is right, argue it on speed or on avoiding a permanent cost. Spend will rise over time on any team that is using AI well. What finance should want to see is outcomes growing faster than the bill.
How to show an AI budget is working
What does finance see before the rest of an AI budget is released?
Finance departments tend to dislike the all-or-nothing request because nobody learns whether it worked until the money is gone. Staged release is what makes the request easier to say yes to.
Write success as outcomes with dates, then, for your most expensive discrete bets, propose a checkpoint after the first tenth of planned spend. Say now what you expect to have seen by then, and offer to refactor the total ask if the results aren’t there. A staged release also gives you the evidence to ask for more later, which matters because some teams are underspending rather than overspending.
How do you measure whether AI spend worked?
At the end of the quarter someone in finance is going to ask what the budget did, and the answer is only as good as the numbers you wrote down before you started. Get the baseline on paper now, along with the outcomes you promised and the dates you promised them for.
Lines of code merged won’t help you here. What you want to know is whether work reaches production faster than it used to and whether it stays there, so look at the time from first commit to production, how much of what shipped had to be reworked, and whether change failure rate and incident counts held steady or improved.
Check spend against milestones every week and keep a dated record of what shipped. Name one person accountable for the whole number, and decide in advance what happens when someone hits a spending threshold. Look at what they are producing before deciding anything, since a flat cap penalizes the people pushing furthest and approving every increase without a look is no better. If you’re going to miss, say so early, because a short explanation in week eight goes over much better than a long one in week thirteen.
What if the results of AI spend are mixed?
Mixed results are a likely outcome for AI spend, and a quarter can end with some outcomes delivered, others missed, and no clear verdict from finance. Two of three outcomes ship, and cost per outcome drops on one workflow but not another. Finance can fairly say that is not a win, since the criteria were set up front.
So agree in writing, before you spend anything, what “mixed but probably worth it” looks like. Something like two of three deliverables plus a documented drop on a named workflow gives both sides a test to apply later, instead of arguing from memory.
How Faros connects AI spend to results
This is the problem we think about at Faros, across every layer of the stack. Engineering organizations now spend on tokens, tools, and people at once, and most cannot say what any of it produces. We call the practice Token Engineering: observing, optimizing, and governing token use so that it maximizes outcomes instead of tokens. Contact us to see what your AI budget is producing, and to walk into your next finance review with outcomes and cost per outcome already on paper.
