The invoice lands in finance’s inbox. The resources that produced it were created by engineers, mostly on a Tuesday, mostly without a price in front of them. So when the bill is higher than planned, each side has a perfectly reasonable claim that it is the other side’s problem.
The FinOps Foundation’s answer is that this is not an either-or question, and its framework is specific about who owns which part.
Why finance alone can’t own it
Finance can see the total, set the limit and chase the variance. What it cannot do is change the number. That takes a decision about architecture, instance size, storage tier or whether a test environment needs to exist at the weekend.
The Foundation’s third principle puts those decisions with the people who make them: “Accountability of usage and cost is pushed to the edge, with engineers taking ownership of costs”, and it asks teams to “decentralize the decision making around cost-effective architecture, resource usage, and optimization.” It adds that technical teams “must consider cost as a first class metric from the beginning of the software development lifecycle.”
A bill owned only by the people who cannot change it is a report, not ownership.
Why engineering alone can’t own it
The opposite fails too. Engineers can reduce usage, but they do not set the company’s budget, decide which cost centre absorbs a shared platform, or negotiate when the forecast is due.
The Foundation’s budgeting capability gives those jobs to finance, which “drives budgeting” and defines “quotas, budgets, and execution thresholds”, sets when forecasts are due and how often they are updated, and works with the FinOps team on budgeting KPIs. Engineering’s part is to “monitor for cloud spend exceeding or trending toward exceeding budgets” and to obtain approval through budget owners for planned changes that will push spend up. That sentence only makes sense if someone else owns the budget.
Who owns what, in the Foundation’s framework
Here is the split, taken from the Foundation’s personas, budgeting and allocation pages:
| Decision | Who owns it |
|---|---|
| Budgets, quotas, execution thresholds | Finance |
| Forecast due dates and update frequency | Finance |
| Which organisational units receive costs; percentage splits of shared costs | Finance |
| Approving allocation strategies and budget variance thresholds | Leadership |
| How and when tags and metadata are applied to resources | Engineering |
| Watching spend against budget; finding optimisation opportunities | Engineering, with FinOps stakeholders |
| Naming standards, tagging compliance checks | FinOps practitioner |
| Rate and commitment optimisation | Centralised FinOps function, per the principles |
Two things stand out. First, the Foundation defines the Engineering persona as “responsible for designing, building, managing and optimizing technology infrastructure to achieve cost-effectiveness”, so cost-effectiveness is written into the engineering job description, not bolted on. Second, Finance is described as working “closely with FinOps Practitioners to quantify the business value of technology.” The word is “closely”, not “instead of”.
So who is accountable?
The Foundation’s budgeting page answers this with a structure rather than a department. Budgets “are allocated to budget owners, who are responsible for a defined scope of work”, and “teams and business units are responsible for managing their budgets.” The organisation commits to fund engineering or product owners at a set level; those owners provide value within it.
In practice that gives you one name per workload or product: a budget owner who can see the cost, can change the usage and answers for the variance. Finance sets the rules they work within. This is the idea behind “everyone takes ownership of their cost and usage”, which is how the Foundation describes FinOps itself.
The other half of the Foundation’s model is that ownership is shared, not scattered. Its fifth principle says “a centralized FinOps function encourages, evangelizes, and enables best practices in a shared accountability model”, and its introduction says FinOps “is not done by a single person or team.” The central team does not own your bill. It owns the data, the standards and the conversation.
How to set it up without a reorganisation
You do not need new org charts. You need four decisions, written down:
- Name a budget owner for each workload, product or cost centre. One person, not a distribution list.
- Give them the cost data. The Foundation’s fourth principle is that cost data should be “accessible, timely, and accurate”. An owner who sees last month’s number in the following month’s meeting is observing, not owning.
- Agree who sets what. Finance owns budget and forecast rules; engineering owns tagging and usage; leadership approves the allocation strategy. The table above is a fair starting point.
- Enforce the basics, don’t plead for them. Microsoft’s governance guidance recommends delegating enforcement to platform and workload teams, using a monitor-first approach, and enforcing tagging so costs can be grouped and allocated. Its example policies include requiring workload teams to set budget alerts at the resource group level.
The order matters. Budget owners and tags come first because allocation is what turns a single bill into several accountable ones.
Where Auris fits
Auris works with certified FinOps practitioners who help companies set up this sort of shared ownership: cost visibility, allocation rules and the reporting each team needs to manage its own number. If you want to see how an engagement works, the FinOps page explains it.
The bottom line
Don’t pick finance or engineering. Name a budget owner for each workload, let engineering own the usage and finance own the budget rules, and keep a central FinOps function supplying data both sides trust. The bill stops being someone else’s problem when it has exactly one name against each part of it.