IT Finance needs a new approach for the AI era. Cost now moves continuously across more providers and AI services than any spreadsheet was meant to hold, and AI tools and agents can finally work collaboratively: answer questions, evaluate scenarios, and act on spend as it happens. But that only works when they have a coherent model to reason over, and most organizations don't. The logic that makes up a cost model is scattered across siloed, disparate tools and spreadsheets, and whatever they don't capture lives in a few key people's heads. An AI can't make sense of a model in that state, and the people who need it increasingly can't either.
This is the next piece in our series on building a cost model that can answer what technology delivers for the business. We started with attribution, assigning every cost to the team, product, or service that owns it, then allocation, distributing shared costs to the teams that consume them. This piece is about the model's form. People trust a number when they can see and understand the logic behind it. The whole organization, not just finance, has to be able to consume the model itself, not only the figures it produces. In that form, it becomes usable by everyone who relies on it, and by the AI now working alongside them. That is what Finance as Code enables.
The cost model is a black box, even to the people who own it
A spreadsheet has no memory and no guardrails, no matter how carefully it's constructed. Explaining how a number was produced means reverse-engineering the file: opening cells, tracing references across sheets, reconstructing logic someone wrote months ago and may no longer remember. There's usually no record of what changed since last quarter, because the file holds only its current state, and reproducing how an allocation was modeled earlier can take weeks, if it's possible at all.
This is where trust breaks down. A model can pull in every cost source and attribute every dollar correctly and still fail here, because no team trusts or wants to carry a number they can't explain. When the person who owns the model leaves, the methodology goes with them, and defending a challenged figure becomes an investigation rather than a lookup. The data underneath can be flawless; if the logic on top is opaque and unversioned, the whole model inherits that fragility.
The stakes rise with scale: a central IT Finance team can't make a large organization's spending efficient and aligned on its own. That happens only when every team can see how its own numbers were produced, and a black box shows them nothing.
This isn't only a spreadsheet problem. A few months ago, a FinOps leader at one of the major investment banks, a public company and major cloud consumer in one of the most heavily regulated industries there is, told me what they'd discovered earlier in the year:
"Someone changed a business mapping months ago, and the whole company had been getting the wrong chargebacks ever since."
It was a few clicks in a web interface, with no review or record of who changed it, when, or why. By the time anyone noticed, months of chargebacks were wrong, and they had to revert every one, redo the mapping, and reissue them backdated across the business. We've all made a version of this mistake in a spreadsheet and caught it months too late; what stings is that they were paying for one of the big-name FinOps tools, and it still came down to ad-hoc UI clicks instead of a mature process for evolving the model with full audit capabilities.
Build the cost model like software
Engineering teams solved a similar problem decades ago. The fix is to manage the cost model the same way. Keep its logic in version control, where every change is recorded with an author and a reason. Review changes before they take effect. Tag released versions so you can reproduce any past model state exactly. Develop risky changes in isolation, iterate, and prove them before they reach the live model. These are ordinary practices on any competent software team, and none of them exist in a spreadsheet.
Applied to a cost model, they change what it is. Its rules, mappings, and allocations become versioned logic with a full history behind them, not a file whose current state is all you have. The model turns into something the organization can inspect and defend, and something an AI can integrate with.
How StitcherAI does it
The tools in this category build a cost model too, but a shallow one: a basic model kept current mostly by clicking through a UI, because none of them has a harness able to construct anything more complex. A few let you generate cost dashboards from configuration and market it as "FinOps as Code," but that configuration describes the output, the reports and the views, while the model underneath is still just a set of mapping rules (marketed as business mappings or virtual tags). It's a start, but modern IT environments demand far more.
StitcherAI works differently. Our focus is the cost model itself: one that is accurate, defensible, and matched to how your organization is actually structured, and we define the entire model as code. Here, "code" means declarative configuration, plain settings that describe the model, editable visually or through an AI prompt. Every dataset brought in, every attribution and allocation rule, every AI mapping, every FOCUS conversion, every artifact or forecast the model generates, and every governance control on top of it is defined this way, versioned and inspectable, with an author, a reason, and approvers behind each change. You no longer need a team of finance-literate data engineers, the rare unicorns most companies can't hire, to stand up a custom cost model.
Because the model is code, the result depends on two things: the model version that ran and the data it ran against. If the data doesn't change, a past period recomputes exactly: March's numbers come from re-running that month's logic against that month's data. When a rule turns out to have been wrong for a closed quarter, the correction is a recorded revision, and the original and the corrected result both stay on the record.
"No other platform builds the cost model this way."
Any change to the model is a diff. Adjust an allocation rule or a FOCUS conversion, and the exact lines that moved are visible, so someone can review and approve the change before it reaches the model everyone relies on, or apply it directly where speed matters more. And before a change lands, StitcherAI can measure its effect: it can run the proposed change or what-if scenario against a baseline and show the delta (a model swap, a service scaling up, a platform re-split) without touching the numbers the organization runs on.
Because the whole model is code, it can be edited by AI agents in plain language. You describe what you want: bring in this dataset, allocate this platform by tokens, correct last quarter's mapping. The agent makes the change as code, whether or not you know StitcherAI, finance, or the individual providers. The result is a cost model complex enough to be accurate and defensible, and simple enough that anyone can change it by saying what they need.
Why it compounds
When the model is transparent and every change is explained, teams start to treat its numbers as their own rather than something finance hands down. A team that can trace a cost back to a rule it can read will take responsibility for the costs it produces, because it can see where each number came from and correct it when it's wrong.
That responsibility turns into contribution, because the model is consumable and versioned. Platform owners, finance, business, and engineering can each work on the part they know best, in parallel, while review, approvers, and isolated testing keep every change governed. The model stops being one team's artifact that everyone else waits on and becomes something the whole organization develops together, and the more hands that shape it safely, the better it fits the business and the more widely ownership spreads.
That same openness is what makes the model useful to AI. An agent can answer a question, test a scenario, or act on spend only when the logic behind the numbers is explicit and versioned; the property that lets a person trust a number is the one that lets an agent operate on it. As the model grows, every rule and every recorded change adds to what both can draw on.
Bill to business
Finance as Code lets an organization trust its own cost numbers over time, as the model changes, as people come and go, as the business reorganizes around it. The methodology stays visible and safe to change, so the model keeps pace with the business instead of ossifying. A figure still holds up when someone has to defend it, and you can reproduce any past period exactly: an auditor asking how a number was derived eighteen months ago gets a precise answer.
That is the difference between a cost dataset people reactively query and a cost model they build on, for the teams that rely on it and the AI now working alongside them.
Interested in seeing what a cost model like this looks like against your own estate? Let's talk!