A spend number invites exactly one question. Is it too big? That is the only question a total permits, and it is the question that loses. When IT arrives at the budget meeting as a dollar figure, a large one, growing, the CFO's entire available move is to test whether the figure could be smaller. Not better. Smaller. The number has no denominator, so it has no meaning beyond its own size, and a number whose only property is size can only be attacked on size.
Change one thing and the meeting changes. Report the same dollars divided by something the business actually produces (a transaction, a served account, an onboarded institution), and you have handed the room a ratio instead of a total. A ratio can fall while the total rises. A ratio has a trend. A ratio invites the question you want, which is not "is this too big" but "why did this move, and is it moving the right way." Stop reporting IT spend, start reporting IT unit economics, and the person who used to interrogate your budget starts defending it.
I should be honest about my vantage. I do not own the enterprise IT P&L. I run security and DevOps at a company that serves more than 1,500 financial institutions, and I report the return on that slice to a board, which is exactly the seat from which you learn that a number without a denominator is unwinnable. Everything below is how I reason about the reporting layer from there. It is a method, not a claim to have run the whole thing.
The denominator is the argument, not the number
The part of the metric that changes the conversation is not the numerator. Everyone can produce the numerator; it is on the invoice. The argument lives entirely in the denominator, because the denominator is the claim you are making about what IT is for. Divide spend by servers and you have said IT is a server operation. Divide it by transactions and you have said IT is how the business runs.
So pick a denominator the company already counts without you. The good ones are the business events the CEO already reports and the CFO already models.
- Cost per transaction. For anything that processes volume, the cost of moving one unit of work through the system, trended as volume grows.
- Cost to serve. The annual cost of keeping one customer, account, or institution running on the platform, whether or not they do anything new this year.
- Cost per customer. The fully loaded technology cost of the next logo, which is the number the growth model needs and the one sales never sees.
- Cost per unit of the thing you actually sell. A decisioned request, a processed file, a completed onboarding. Whatever the CEO puts on the growth slide, put your cost underneath it.
The wrong denominators are the ones internal to IT: cost per server, cost per seat, cost per ticket. They feel rigorous and they are worse than useless in this room, because they divide an IT cost by an IT unit and keep the conversation inside the function, answering a question nobody outside it was asking. A denominator the business already tracks pulls your budget out of the department column and makes it a component of a number the whole executive team owns together. That relocation is the point.
Report the slope, not the level
Once the number has a denominator, the level barely matters. The slope is the story.
A unit cost that falls as volume rises is operating leverage, and operating leverage is the thing a growth-stage finance team is most trying to prove. It is what a public SaaS company means by gross-margin expansion, and what a sponsor is underwriting when it models a business scaling faster than its cost to run it. When you can show that serving the ten-thousandth institution costs less than the thousandth did, you are not reporting a cost trend. You are reporting the mechanism by which the company gets more profitable as it grows, which is a slide the CFO wants and did not know IT could supply.
A flat or rising unit cost as you scale is also a story, a worse one, worth telling on purpose. It signals that the architecture has a ceiling, or that the business model does, and the earlier that surfaces the cheaper it is to act on. The slope does not always flatter you. It converts your budget from a snapshot the CFO can only cut into a trajectory the CFO has to reason about. Put unit cost and volume on the same chart, month over month, and let the two lines make the argument. If they diverge, volume up and unit cost down, you have stopped presenting a cost and started presenting margin.
Put the number where the CFO already keeps score
The mechanism that actually makes the CFO defend your budget is not persuasion. It is placement.
In a software or fintech business, a large share of infrastructure spend does not sit in operating expense at all. It sits in cost of goods sold, which makes it a direct input to gross margin. I will stay in my lane on the accounting; where a given dollar lands is a controller's call, and the classification tests are specific enough that I would not want to rule on them in an essay. But the shape is not subtle. If the cost of running the product scales with the product, it belongs to the margin story, and the margin story is the one the CFO reports to investors, to the board, and to whoever holds the equity.
That is why the reporting choice is really a partnership choice. When you report cost per transaction, you are not handing the CFO an IT metric. You are handing them a component of their own gross margin, the number they defend to the street or to the sponsor every quarter. Now cutting your budget carelessly has a cost that lands on them: trim the wrong dollar, cost-to-serve rises, margin compresses, and the variance shows up in the CFO's report, not yours. You do not win the budget by advocating for it. You win it by making your unit cost a term inside a number the CFO is already accountable for. A CFO who understands that your team is a lever on gross margin treats you as a line to protect, and makes the case upward better than you could, because it is now their case.
Marginal cost, not average cost
Average unit cost wins the framing argument. Marginal unit cost wins the growth argument, and they are not the same number.
The average is total spend over total units. It is honest about where you are today and it is the right figure for the trend line. But when the business asks the only question that matters in a growth plan (what does it cost to serve the next thousand institutions, not the average of the last thousand), the average will quietly mislead you, because it blends the fixed platform you already paid for with the variable cost that actually moves when you add load. The two behave nothing alike as you scale, and reporting them as one number hides your best evidence.
So split it. Report the fixed base, the platform and the controls and the run-rate that exists whether you add one customer or ten thousand, apart from the variable cost that tracks volume. The marginal cost of the next unit is the one that belongs in the growth model, and it is almost always well below the average, because the expensive part is already built and paid for. That means the honest version of your story is better than the blended one, not worse. Report only the average and you undersell your own operating leverage to the one audience most inclined to reward it.
You cannot report what you did not instrument
All of this is downstream of one unglamorous prerequisite. The number has to be real, which means it has to be attributed where the cost is incurred, not reconstructed from the invoice at quarter-end.
A metric reverse-engineered from a bill once a quarter is a number you will hedge on the moment a director pushes, and hedging is how you lose the room. Build the attribution in and the unit economics are a query you run before the meeting. Bolt it on afterward and every reporting cycle becomes a forensic exercise that arrives late and lands soft.
The clearest version I have built is inside AgentOS, our governed internal agent platform. Because every agent runs through a control plane, the platform measures cost against a task, a team, and an agent as the work happens rather than inferring it later from an aggregate bill. The reportable metric that produces is not "what did this cost last quarter." It is "what does one unit of this agent's work cost, and which direction is it trending": a number I can put in front of a board and defend, because it was measured, not guessed. Reporting quality is downstream of instrumentation quality, and the reporting is where the instrumentation finally pays for itself.
Change the denominator, change the conversation
If you change one thing about how your function reports, change this.
- Pick a denominator the CEO already counts, and divide your spend by it before anyone asks you to.
- Report the slope, not the level: put unit cost and volume on one chart and let the divergence carry the argument.
- Land the number inside gross margin, where the CFO already keeps score, so defending your budget defends their margin.
- Instrument at the point of consumption, so every number you report is one you can hold under questioning.
Do that and the budget meeting stops being a negotiation about your size and becomes a conversation about your leverage. That is a better meeting, and it is a better job.