I once inherited a cloud cost dashboard with 34 tiles, six filters and a refresh that ran every fifteen minutes. It was, by any technical measure, an excellent piece of work. In the four months before I took it over, it had been opened by someone outside the FinOps team exactly nine times. The bill had gone up 21 percent over the same period.

Nothing was wrong with the numbers. What was wrong was the assumption underneath it, which is that visibility causes action. It does not. Visibility creates the possibility of action, and then a completely separate set of design decisions determines whether that possibility ever gets used. Part 6 ended by saying most of the value of showback is delivered or wasted in the reporting. This is where that happens.

What makes a cost report actionable

Here is the test I apply to every cost report before it ships. Hand it to the person it was built for, let them read it for sixty seconds, and ask them what they are going to do. If the answer is a specific verb attached to a specific resource, the report works. If the answer is that spend went up, the report is a mirror, and mirrors do not change anything.

Four properties separate the reports that pass that test from the ones that do not. The first is a named owner on every line. A total is not actionable, because nobody owns a total. The second is a comparison, because a number without a baseline carries no information: 42,000 this month means nothing until you know it was 31,000 last month and 33,000 forecast. The third is granularity that reaches an object somebody can touch, which usually means a resource identifier, a cluster name or a service, not a category called Compute. The fourth is a stated next step, even a weak one, because the gap between seeing a number and knowing what to do about it is where most reports die quietly.

The FinOps Foundation calls this capability Reporting and Analytics, and describes it as one of the most important and critical of the FinOps capabilities, supporting almost every other one. That is not a promotional claim. Allocation feeds it, forecasting depends on it, anomaly detection is a special case of it, and every optimisation conversation starts with a report somebody trusted. The Foundation is also explicit that reporting here means dashboards, data feeds and APIs, not only documents, which matters because the most effective cost reporting I have shipped was not a report at all. It was a line in a pull request comment.

That idea has a name in the Framework maturity model. At the run level, analytics results are pushed into the dashboards and work queues that engineering teams already use, described as putting the data in the path. It is the single highest leverage change available in this capability, and it is mostly an integration problem rather than an analytics problem.

Reports for four audiences

The single most common design mistake in this capability is building one dashboard and expecting four different jobs to use it. An engineer wants to know whether the change they shipped yesterday cost anything. A finance analyst wants to know whether the month will land inside the budget. A product manager wants cost per customer. A leader wants a trend and a small number of decisions. Those are four different questions with four different refresh rates, and no amount of filtering turns one view into all of them.

The Framework treats this as a defining property of the capability, listing context specific analysis curated by persona role as an output and requiring that every persona has access to appropriate reporting data. It also lists data sensitivity as something you have to decide deliberately: not every audience should see every salary adjacent or customer identifiable figure, and deciding that after the first accidental disclosure is worse than deciding it now.

My rule of thumb is that cadence should match the speed at which the audience can act. Engineers can act daily, so they get daily. Finance acts on a monthly close cycle, so daily numbers only create noise and false alarms for them. Leadership acts quarterly on structural decisions, and giving them a weekly figure invites them to react to variance that has no meaning at that resolution.

Persona groupings follow the FinOps Framework personas. Cadence and delivery are my own recommendations based on how quickly each audience can change spend.

Where the numbers come from on AWS, Azure and Google Cloud

Every provider gives you two tiers of access, and knowing which tier you are on decides how far your reporting can go. The console tool is fast, free and limited. The detailed export is slower to set up, gives you every row, and is the only thing you can build real reporting on.

On AWS, the console tool is Cost Explorer, which shows month to date spend, a forecast for the month, daily unblended cost and a set of saved reports, all in US dollars only. The detailed route is Data Exports, which delivers Cost and Usage Report 2.0, known as CUR 2.0, and lets you choose the columns, filter rows, and cut the export size before it lands in your storage bucket. AWS also publishes a FOCUS export through the same Data Exports feature. My recommendation is to enable both the CUR 2.0 export and the FOCUS export from day one, because they cost storage and nothing else, and backfilling a period you failed to export is not always possible.

On Azure, the console tool is Cost Analysis inside Microsoft Cost Management, and the detailed route is a scheduled cost export to a storage account, which can also be produced in FOCUS format. On Google Cloud the equivalent is the Cloud Billing export into BigQuery, which is the standard route and where most Google Cloud reporting is genuinely built, since the console reports are thin by comparison.

One practical note that costs people a month if they miss it. All three exports are configured going forward, and the useful history only starts accumulating from the day you switch them on. If you are starting a FinOps practice this week and you do nothing else, turn on the detailed exports on all three providers before you write a single line of reporting logic. The reporting can wait. The data cannot be recovered.

flowchart LR
  A[Provider billing exports] --> B[Ingest and normalise]
  B --> C[Enrich with tags and business data]
  C --> D{Who is asking}
  D -->|Engineer| E[Cost beside the deploy]
  D -->|Finance| F[Variance to budget]
  D -->|Product| G[Cost per customer]
  D -->|Leadership| H[Trend and coverage]
  E --> I[Action taken and logged]
  F --> I
  G --> I
  H --> I
  I --> C

Does one schema beat three?

Yes, and this is one of the few places in FinOps where the answer is not conditional. Before FOCUS, reporting across three clouds meant three schemas, three sets of column names, three definitions of what a discount is, and a normalisation layer that your team maintained forever. FOCUS, the FinOps Open Cost and Usage Specification, is an open specification that defines what a billing dataset has to look like, so that a query written once works across providers that conform to it.

The specification moves quickly. Version 1.3 was ratified on 4 December 2025 and added a dedicated contract commitment dataset, allocation columns that expose how a provider split shared costs, and the recency and completeness metadata mentioned earlier. Version 1.4 was ratified on 4 June 2026, adding 2 datasets, 47 columns and 6 attributes, with new invoice detail and billing period datasets so that accounts payable, finance and FinOps can reconcile from the same data. The Foundation states that 1.4 contains zero incompatible changes, so existing implementations upgrade without rewriting queries.

The trade off worth naming is that FOCUS conformant exports are not always as complete as a provider native export for that provider specific detail. My approach is to keep both: build the cross cloud reporting and every executive view on FOCUS, and drop to the native export when you are investigating something provider specific such as a particular EC2 pricing edge case. The Framework describes combining datasets into one source location, using FOCUS, as run level maturity. That is accurate, and it is now reachable in a quarter rather than a year.

Metrics that belong on every cost report

A cost report should carry a small, fixed set of numbers that appear in the same position every time, so that a reader learns where to look. Adding a metric is easy and removing one is politically hard, so be strict at the start.

Five earn a permanent slot in my reports. Total spend against forecast, because it frames everything else. Unallocated spend as both a currency amount and a percentage, because it is the honest measure of how much of your reporting is guesswork. Change against the previous period, split into rate change and usage change, since a bill that rose because you bought more is a completely different problem from one that rose because a discount expired. Commitment coverage and utilisation, which Parts 12 and 13 cover in depth. And at least one unit cost, meaning spend divided by a business quantity such as active customers or completed transactions, because it is the only metric on the list that can improve while total spend grows.

The Framework sets tagging compliance above 90 percent as a measure of success for this capability, and I would treat that as a floor rather than a target for reporting purposes, because a report built on 85 percent coverage will be challenged on its coverage every time somebody dislikes its conclusion. Below are the four numbers I track on the reporting itself, from a practice I worked with through a year of build out.

Illustrative figures from one practice over three quarters, on a monthly cloud bill in the high five figures. The last row is the one I would keep if forced to drop the other four.

How do you know the reporting is working?

Not by the bill going down, which is the answer everyone reaches for and the one that will mislead you. Spend moves for reasons that have nothing to do with your reporting, including a product launch, a migration, a pricing change or a seasonal peak. Attributing a fall in the bill to your dashboard is exactly the kind of causal claim a FinOps practitioner should be suspicious of.

Measure the behaviour instead. The Framework offers two measures of success I lean on constantly: reduced investigative time for analysis of usage and cost reporting questions, and self service reporting available to all core personas. Both are observable without any assumption about causation. Track how long a question takes to answer, and track how many people answer their own.

The third signal is the one I trust most, and it is in the table above. Who found the last anomaly? If the FinOps team finds every one, your reporting is a monitoring system with two operators. When teams start noticing their own spikes before you do, the data has genuinely arrived in their path, and that is the moment the capability changes character. It stops being a service you provide and becomes something the organisation does.

Build one report per persona and delete the ones nobody opens

The recommendation, stated plainly. Turn on the detailed billing exports on every provider today, including the FOCUS export where it is offered. Spend a week writing the semantic layer, meaning the agreed definitions of spend, team and environment that every view will read from. Then build exactly four views, one per persona, each answering the single question that persona actually asks, and deliver each one into a place that audience already looks rather than a portal you have to persuade them to visit. Instrument all four, and delete anything that is still unopened after two quarters.

What you should not do is build the 34 tile dashboard. It is more satisfying to make, it demonstrates more skill, and it will be ignored, because the number of tiles a report has is inversely related to the probability that anyone acts on any of them.

Part 8 takes the same data forward into forecasting and budgeting, which is where reporting stops describing the past and starts committing you to a number. The groundwork sits in Part 3 on the Framework and Part 5 on allocation, and every part so far is indexed on the Cloud FinOps guide.

One thing to do this week: open your most heavily promoted cost report, find out how many distinct people opened it in the last 30 days, and if you cannot find that number, that is your first piece of work.

References

• Reporting and Analytics capability, FinOps Framework, FinOps Foundation
• FOCUS Specification, versions 1.3 and 1.4, FinOps Foundation
• Exploring your data using Cost Explorer, AWS Cost Management User Guide
• What are AWS Cost and Usage Reports, AWS Data Exports User Guide
• Cost and Usage Report 2.0 table dictionary, AWS Data Exports

Monetary figures, session counts and quarterly metrics are illustrative and chosen to show realistic movement. Framework wording, FOCUS version dates and provider export behaviour were verified in July 2026 and change over time.

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