A cost platform will not make you good at FinOps. I have watched three organisations buy the same well regarded tool inside the same financial year. One had more than ninety percent of spend allocated to a named owner within two quarters. The second is still arguing about whether the numbers in the tool match the numbers on the invoice. The third quietly stopped logging in after about six months, and nobody noticed until the renewal notice arrived. Same software, three outcomes, and the software was never the variable that moved.

This is the last part of the series, so it is the right place to deal with the two questions that get asked first and answered last: what should we buy, and how do we know if we are any good at this. Both have real answers. Neither answer is a vendor name.

What a FinOps tool actually does for you

Strip away the marketing and a FinOps platform does four things. It ingests billing data from one or more providers. It applies allocation logic so that a charge lands against a team, product or cost centre. It presents that allocated data to different audiences in forms they will actually read. And it detects conditions worth reacting to, such as an anomaly, an expiring commitment, or an instance that has been running at four percent utilisation since March.

Notice what is missing from that list. No tool decides that a workload should move regions. No tool negotiates with a product owner who does not want their environment shut down at night. The FinOps Foundation puts this plainly in its guidance on tooling: many tools automate or ease routine tasks, but they will not solve problems or engage your teams without a skilled team behind them. That matches what I see. The gap between the first organisation in my opening and the third was never a feature gap. It was that the first had a named person with the standing to say a change was happening, which is exactly the ground covered in Part 19.

The practical consequence is that tooling sits in the middle of a stack, not at the top of it. Below it is a data layer you are responsible for. Above it is an action layer that lives in your ticketing system, your infrastructure code and your review meetings. Buy the middle and neglect either end, and you get the beautiful dashboards that change nothing.

Native, third party, or built in house

Every organisation ends up with some mixture of provider native tools, commercial platforms, open source components and internally built reporting. The mix is not a statement about sophistication. It is a consequence of how many providers you run, how unusual your allocation rules are, and how much engineering time you can genuinely spare on an ongoing basis.

Native tools are underrated by people who have never seriously configured them and overrated by people trying to avoid a procurement conversation. They are free or close to it, they have the deepest possible knowledge of that provider’s own pricing constructs, and they are the fastest thing to stand up. They are also, by design, blind to everything outside their own provider, and their allocation models tend to stop exactly where your organisational structure gets interesting.

Building in house is the option most often chosen for the wrong reason. Teams build because the first version is genuinely easy: you have FOCUS formatted exports, a warehouse, and someone who can write SQL, so a decent allocation report takes a fortnight. The cost is not the fortnight. It is the ongoing maintenance as providers add services, change pricing constructs and revise export schemas, and the fact that the person who built it eventually changes jobs. Build when your allocation logic is genuinely unusual and central to how you run the business. Do not build to save a licence fee.

Here is the comparison I use when someone asks me to put numbers on it. These are illustrative figures for a mid sized estate at roughly 400,000 USD per month of cloud spend, using a fully loaded engineering cost of 120,000 USD per year, and they exist to show the shape of the trade off rather than to quote any vendor.

How to choose without running a six month bake off

Long tool evaluations are usually a symptom, not a process. When a team cannot decide between two platforms after four months of demonstrations, the real problem is almost always that nobody wrote down what the tool has to do. The Foundation’s guidance on tooling is blunt about this: there is no FinOps tool that is objectively the best, and different combinations suit different situations. That is not a cop out. It means the requirements have to come from your practice, not from a feature matrix.

The decision usually collapses to four questions, in this order. How concentrated is your spend across providers. Do you have clean normalised billing data. Can your allocation rules be expressed in what you already have. And do you have anyone who can maintain what you build. Work through those honestly and most organisations arrive at an answer in a fortnight.

flowchart TD
  A{Is more than 80 percent of spend on one provider} -->|Yes| B[Start with the native cost tool and stop]
  A -->|No| C{Do you get FOCUS exports from every provider}
  C -->|No| D[Fix the data layer first, revisit tooling in two quarters]
  C -->|Yes| E{Does allocation need logic the native tools cannot express}
  E -->|No| F[Report on the FOCUS data you already hold]
  E -->|Yes| G{Can you fund 0.7 of an engineer forever}
  G -->|No| H[Buy a commercial platform]
  G -->|Yes| I[Build, and staff it properly]
  B --> R[Reassess when a second provider passes 15 percent of spend]
  D --> R
  F --> R
  H --> R
  I --> R

The maturity model, and what the numbers mean

The FinOps Foundation describes maturity as Crawl, Walk and Run. The intent is to let an organisation start small and grow in scale, scope and complexity as business value warrants it, taking action quickly at limited scope so the team can judge whether going further is worth it.

The part people miss is that these stages apply to individual capabilities, not to the organisation as a whole. You can be at Run for anomaly detection and Crawl for unit economics at the same time, and that can be entirely correct. The Foundation states directly that an organisation’s goal should never be to achieve Run maturity in every capability, and gives a specific example: a team with Walk stage anomaly detection that already catches the few spikes it experiences should spend its effort elsewhere, because further maturing that capability adds nothing to the measure of success.

What makes the model usable rather than decorative are the sample thresholds published alongside it, drawn from community survey data. These give you something to measure against instead of arguing about adjectives.

How to assess your own maturity

Self assessment goes wrong in a predictable way. Someone scores the practice against every capability, produces a spider chart where most axes sit at Walk, presents it to leadership, and the meeting ends with a vague instruction to improve. Nothing changes because nothing was decided.

A better version takes an afternoon. Pick the six to eight capabilities that your organisation actually depends on this year. Score each one against the published thresholds, using real measurements rather than impressions. Then, for each, answer a second question that the chart never asks: what does the business lose if this stays exactly where it is. Most capabilities will produce a shrug. One or two will produce a real number. Those are the only ones that belong on next quarter’s plan.

Charting the gap between where you sit and the next threshold makes the conversation concrete, particularly with a finance audience who will recognise forecast variance immediately even if commitment coverage means nothing to them.

FOCUS and the end of lock in on cost data

FOCUS, the FinOps Open Cost and Usage Specification, is an open technical specification that defines a uniform format for billing data across vendors. It began in 2023 to give practitioners and tools a common schema instead of a different one per provider. The Steering Committee ratified version 1.4 on 4 June 2026, adding two datasets, 47 columns, six attributes and 17 glossary entries.

Two things in the 1.4 release matter for the tooling decision specifically. The new Invoice Detail and Billing Period datasets let finance and FinOps reconcile against the same data, which removes the most common source of the argument I described at the top of this article. And the release explicitly targets running FOCUS as a system of record, with new attributes covering correction styles, delivery mechanics and column completeness, so the dataset is predictable enough to be a primary source rather than a supplement. The 1.4 release also shipped with zero incompatible changes, so existing queries upgrade without rewriting.

My recommendation, and it is a change from what I would have said three years ago: make FOCUS formatted exports a hard requirement in any tool selection, and land those exports in storage you control before the tool touches them. If the platform disappoints you, you keep your history and your queries. That single decision converts a five year vendor commitment into something closer to a twelve month one, and it costs almost nothing to implement at the start. There is also a conformance programme for vendors, so you can ask for evidence rather than a claim. [VERIFY: the precise conformance badge naming and its current vendor coverage were not confirmed this run.]

A twelve month roadmap

Sequencing matters more than ambition. The order below reflects dependency, not importance, and it is the order I would give any organisation starting a practice from close to nothing.

Months one to three, make the bill legible. Account and subscription structure, tagging policy with enforcement, FOCUS exports landing in your own storage. This is the work covered in Part 5, and skipping it is why most practices stall in month seven. Target: allocation above 70 percent.

Months three to six, take the money that is sitting there. Commitment coverage and rightsizing produce savings quickly and buy political capital for the slower work. See Part 12. Target: coverage above 60 percent, with a documented commitment approval path.

Months six to nine, make it routine. Anomaly alerting with a named owner per alert, a monthly forecast that someone signs, and reporting that reaches engineering teams rather than only finance. Target: forecast variance below 20 percent.

Months nine to twelve, connect cost to value. Unit economics for at least one product, and cost review inserted into architecture decisions before deployment rather than after. This is where the 2026 Framework is heading with its new Executive Strategy Alignment capability, which formalises FinOps as a partner to executive decision making rather than a reporting function. If you get here, you are ahead of most practices.

One note on where the discipline is going. The Framework was updated in March 2026 to reflect that practitioners now manage far more than public cloud, with technology category guidance covering SaaS, data centre, data cloud platforms and AI. State of FinOps 2026 data has 98 percent of practices managing AI spend and 48 percent managing data centre cost and usage. Whatever you build this year, build it so it can accept a non cloud cost source without a rewrite. That is a design decision you make once, cheaply, at the start.

Buy the platform, own the allocation

Here is the recommendation, stated plainly. For most organisations running more than one provider and spending above roughly 200,000 USD a month, buy a commercial platform rather than building one, and insist on FOCUS exports landing in storage you control. Do not build unless your allocation logic is genuinely unusual and you can fund a maintainer indefinitely. Do not stay on native tools alone once a second provider passes about fifteen percent of spend.

And do not chase Run maturity across the board. Pick the two capabilities where the gap costs measurable money this year, close those, and let the rest sit at whatever stage is adequate. The organisations I have seen succeed were rarely the most mature on paper. They were the ones that could name, in currency, what their next improvement was worth, and had someone with the authority to go and get it.

That closes this series. Twenty parts, from what FinOps actually is through to the roadmap you are now holding. If you do one thing this week, measure your allocation percentage honestly and write the number down. Everything else in this series depends on it, and almost nobody knows it without checking. Then work back through the full series guide and pick the part that addresses your weakest number.

References

• FinOps Foundation, FinOps Maturity Model
• FinOps Foundation, FinOps Framework 2026
• FOCUS Specification, version 1.4
• State of FinOps 2026 Report

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts