How Azure Calculates Your Cloud Emissions and How to Report It in Power BI

Sustainability reporting used to be a job for the annual report team and nobody else. That has changed fast in Australia. With mandatory climate disclosure now landing on larger companies and their suppliers, a lot of businesses suddenly need to put a number on their carbon footprint, and a chunk of that footprint lives in the cloud. If you run workloads on Azure, Microsoft gives you emissions data you can pull straight into Power BI. The obvious next question, and the one almost nobody asks before they publish a chart, is where does that number actually come from.

The Microsoft documentation on the Azure emissions calculation methodology covers the mechanics. What I want to do here is explain what it means in practice, based on the reporting work we do for clients, and be honest about where the data is solid and where you need to be careful before you stake a disclosure on it.

Why cloud emissions are their own category

There is a mental model that trips people up. If you run a server in your own building, the electricity it burns shows up on your power bill, and that is clearly your emission. You bought the power, you used it. When you move that same workload to Azure, the electricity is now Microsoft's power bill in a Microsoft data centre. So whose emission is it?

The answer, under the greenhouse gas accounting rules everyone reports against, is that it is still yours. It becomes a scope 3 emission, the category that covers everything in your value chain that you do not directly own or control. Your cloud usage is a purchased service, and the emissions from running it belong in your footprint even though the physical electricity meter is somebody else's. This is exactly why Microsoft built the emissions data in the first place. They know their enterprise customers have to account for this, and they are the only ones with the data to work it out properly.

What actually goes into the number

The calculation is more involved than "how much power did the servers use". Microsoft starts with the energy consumption of the infrastructure your workloads ran on, then applies a set of adjustments to turn raw kilowatt hours into a carbon figure that reflects reality on the grid.

The first big factor is where your workload runs. A virtual machine in a data centre powered largely by renewables produces far less carbon per compute hour than the same VM in a region still leaning on coal. This matters a lot for Australian customers. The Australia East region in New South Wales and the Australia Southeast region in Victoria sit on grids with their own emissions profiles, and those profiles are different from, say, a Nordic region running on hydro. If your architecture team picks a region purely on latency, they may be quietly signing you up for a higher carbon number than you needed.

The second factor is the carbon intensity of the grid at the time. Grid intensity is not a fixed number. It moves through the day and the seasons as the mix of solar, wind, gas and coal shifts. Microsoft accounts for this rather than applying one flat annual average, which is more accurate but also one of the reasons your figures move around month to month even when your usage is flat.

The third piece is the share of shared infrastructure allocated to you. A data centre has cooling, networking, and overhead that is not tied to any single customer. Your slice of the total energy has to include a fair portion of that shared load, not just the raw draw of your VMs. This overhead is captured in the facility's efficiency, and it is part of why the number is bigger than a naive calculation of your compute alone would suggest.

Then there is the accounting method Microsoft uses to reflect its renewable energy purchases. This is the part that generates the most confusion and, frankly, the most scepticism, so it deserves its own explanation.

Market-based versus location-based, and why it matters

There are two accepted ways to account for the emissions of purchased electricity, and they can produce very different numbers for the same workload.

Location-based accounting looks at the physical grid your data centre draws from and applies that grid's average carbon intensity. It answers the question "what did the local grid actually emit to power this". It ignores any clean energy contracts the operator has signed.

Market-based accounting factors in the renewable energy that Microsoft has purchased through power purchase agreements and renewable energy certificates. Microsoft has bought a very large amount of renewable energy globally, so its market-based figures are dramatically lower than its location-based ones. This is the number that lets cloud providers talk about running on clean energy.

Neither is wrong, but they answer different questions, and this is where I see reporting teams get burned. If you report only the market-based figure because it looks better, and your auditor or a regulator asks for the location-based view, you can look like you cherry-picked. Serious climate disclosure increasingly expects both. When we set up emissions reporting for a client, we make sure the model captures whichever basis Microsoft provides and that the report clearly labels which one is on screen. A carbon number with no method label is close to meaningless, and worse, it is a governance risk.

Getting it into Power BI

The practical side is straightforward, which is part of the appeal. Microsoft surfaces this data so you can bring it into Power BI and build proper reports rather than screenshotting a portal dashboard once a quarter. Once it is in a semantic model you can slice emissions by subscription, by service, by region, by team, and track the trend over time.

That last point is where the real value sits. A single carbon number is a compliance artefact. A trend line, broken down by which workloads and which teams are driving it, is a management tool. We have built reports where a client could see that one non-production environment left running around the clock was responsible for a surprising slice of their cloud emissions, and turning it off outside business hours cut both the carbon and the bill. That is the kind of insight that only shows up when the data is in a tool people actually look at. This is squarely the sort of reporting we build in our Power BI work, and it pairs naturally with cost reporting because the same usage data drives both.

If your data estate is broader than a few subscriptions, and it usually is once finance, operations and sustainability all want a view, this is also where a proper data platform earns its keep. Stitching Azure emissions together with the rest of your operational data is the kind of thing our Microsoft Fabric and data work is built for, so the sustainability report is not a standalone island that someone rebuilds by hand every reporting cycle.

The honest caveats

I like that Microsoft publishes this data, and it is genuinely more rigorous than most of what passes for carbon accounting. But you should go in with your eyes open.

The numbers are estimates, not meter readings. There is real modelling in the grid intensity and the infrastructure allocation, and estimates carry uncertainty. That is fine for management insight and it is accepted for disclosure, but do not treat a cloud emissions figure as if it has the precision of a bank balance. It does not.

The data also lags. You are not getting real-time carbon, you are getting a figure for a period after that period closes. That is normal for emissions accounting, but it does mean this is a reporting and trend tool, not a live dashboard you tune your architecture against minute by minute.

And the methodology evolves. Microsoft refines how it calculates this over time, which is a good thing, but it means a restated historical figure can differ from what you reported last year. If you are producing formal disclosures, keep a record of the methodology version behind each published number so you can explain a change rather than being caught out by it.

The last caveat is the biggest, and it is not technical. Cloud emissions are one line in your total footprint, and for most Australian businesses they are a small line. If your buildings, fleet, travel and supply chain dwarf your cloud usage, then polishing the cloud number to three decimal places while ignoring the big items is effort in the wrong place. Get the cloud reporting right because it is easy and it is asked for, but keep it in proportion.

Where to start

If you are staring down a climate disclosure obligation for the first time, the sensible order is to get the data flowing and visible before you worry about perfecting it. Pull the Azure emissions data into a Power BI model, get it trending, label the accounting basis clearly, and put it in front of the people who make architecture and cost decisions. The insights and the improvements follow from visibility.

If that sounds useful but you would rather not work out the plumbing yourself, that is the kind of thing we do all the time. Have a look at our business AI and data services, or get in touch and we will help you turn the raw Azure emissions feed into reporting your finance, operations and sustainability people can all actually use.