Turning a CSV of findings into an Azure cost report finance will act on
You have run the checks. There is a folder of CSVs. Somewhere in it is about 140 dollars a month of avoidable spend, which is either a rounding error or a meaningful percentage of the bill depending on the company.
The failure mode from here is not technical. It is sending a spreadsheet to someone who has thirty minutes between meetings and expecting them to derive a decision from it. A good azure cost report does the deriving for them.
What an azure cost report needs to do
Three things, in this order, and the order is the point.
Say what it does not know, first. Reservations, savings plans, enterprise agreement discounts and Hybrid Benefit all change the real figure, and none of them are visible in the resources you queried. If the caveat is in a footnote, somebody in the meeting will find it and it will look like you were hiding it. If it is the first paragraph, you are the person who understands the limits of their own numbers, which is a much better position to hold.
The wording that has served me: these figures are for prioritising work rather than for billing.
Rank by monthly cost, descending. Not by resource type, not by subscription, not alphabetically. The reader wants to know what to look at first and there is exactly one correct sort order for that question.
End in decisions, not data. Split every finding into recommended, deferred, or ignore, with a reason on the deferrals. A report where all 40 findings are "recommended" has not been triaged and shifts the whole judgement onto the reader. A report where 12 are recommended, 9 are deferred pending a conversation with a named person and 19 are noise has done the work.
Three formats, three audiences
Sending one audience another audience's format is how good findings get ignored.
HTML for whoever decides. Caveats at the top, findings ranked by cost, the recommended and deferred split, and totals at the bottom. Self-contained so it survives an email gateway that strips external references. This is the artefact that goes to a client or to finance and gets forwarded.
Markdown for whoever does the work. One block per finding, with the resource ID and the check that produced it, paste-ready into a ticket. No narrative. The person clearing the backlog does not need the caveats because they are not the one deciding.
A digest for the channel. Four lines. Total monthly cost of open findings, the change since the last run, the top three by cost, and a link to the full report. Nobody reads a report in Teams. They read a number, notice whether it moved, and click if it did.
The numbers have to be right in the boring direction
One thing will destroy the credibility of every subsequent report, and it is not being slightly wrong. It is being wrong in a way that flatters the exercise.
If you understate the saving, somebody acts, the saving turns out to be larger, and you look conservative. If you overstate it, somebody acts, the saving does not appear on the invoice, and every number you produce afterwards gets checked by hand.
That is the practical reason disk tier pricing matters so much to this. A flat per-GB estimate understates a Premium disk by roughly 3.7x, which sounds like the safe direction to be wrong in until you realise it makes the whole cleanup look not worth doing. Eight findings totalling 137.26 a month is an afternoon's work with an obvious answer. The same eight findings reported as 40 dollars a month gets deferred, and correctly so.
Structure that works
For anything longer than a page:
- One paragraph of scope. Which subscriptions, which date, what was checked, what was not.
- Caveats. Three or four lines. What could move these numbers.
- Headline. Total monthly cost of findings, and the count.
- Recommended. Ranked by cost, with the action for each.
- Deferred. With the reason and, where possible, the name of the person the decision needs.
- Ignore. Briefly, because listing what you deliberately did not raise is what stops somebody else raising it next quarter.
- How to re-run it. The command, so the improvement is verifiable without you.
That last section is the one people leave out, and it is the difference between a report and a dependency. If the client can re-run the checks next month, the number becomes a metric. If they cannot, it was a one-off observation and it expires the day you leave.
Reconciling against actual spend
A findings report is a projection. At some point somebody sensible will ask whether it happened.
Cost Management is the right source for that, not your own tooling. Export actual billed cost for the resource types you acted on, for the month before and the month after, and compare. Microsoft's Cost Management export documentation covers scheduling those exports to storage, which is worth setting up before you need the comparison rather than after.
Expect the actual saving to differ from the projection, and expect to be able to explain why. Usually it is a reservation you did not know about, a resource somebody recreated, or a price change. All three are fine answers. Not knowing is not.
White-labelling, if you are billing for this
If you are a consultant or a managed service provider, the report is a deliverable rather than an internal document, and a report carrying somebody else's brand is not much use.
AzClean Reporting produces all three formats from toolkit CSVs or any CSV where you can name the cost and resource columns, with white-labelling and the recommended and deferred thresholds as parameters. The thresholds matter more than they sound: what counts as worth doing differs between a startup and a company with a change board, and hardcoding that judgement into a tool is how you end up arguing with your own report.
The tagging note covers the other half of this, which is being able to attribute the spend you did not eliminate.