Two Columns, One Invoice: Building a Carbon Ledger Your UK Cloud Team Can Defend

Your finance business partner can tell you what the estate cost last month down to the penny, split by cost centre, tag and team. Now ask the same person how many kilograms of CO2e the same estate emitted. There's usually a pause, then a reference to the provider's sustainability page, then a sentence that starts with "well, they say they're 100% renewable."

That's not a moral failing. It's a data gap. And it's one you can narrow considerably in a quarter without hiring a consultant or buying a platform.

The claim and the wire are two different things

Cloud providers publish two flavours of the same fact. Market-based accounting lets them count renewable energy certificates, power purchase agreements and unbundled guarantees of origin against their consumption. Location-based accounting ignores all of that and asks a blunter question: what did the local grid actually deliver, at the moment your workload ran?

Both are legitimate under the GHG Protocol. They answer different questions. Market-based tells you what the provider paid for. Location-based tells you what your region drew. A UK region running heavy compute at 6pm on a cold January evening is pulling from a grid mix that is nothing like a national annual average, and certainly nothing like a global corporate claim.

When procurement, or a customer's supply chain questionnaire, or your own board pack asks "what does our cloud emit", they are almost always asking a location-based question. The provider's headline figure is usually a market-based one. That mismatch is where most carbon conversations go sideways.

What the portals give you, and what they don't

The three big hyperscalers all ship a free carbon dashboard now: AWS's Customer Carbon Footprint Tool, Azure's Emissions Impact Dashboard, Google Cloud's Carbon Footprint report. They are genuinely useful — and genuinely limited.

Three constraints bite every time. First, granularity: you typically get emissions by service or region, not by workload or tag, so you can't hand a team its own number. Second, lag: figures often arrive a quarter or more behind the invoice, which makes them hard to tie to a decision you made last month. Third, modelling: much of the data is estimated from spend or usage patterns rather than metered, and the methodology notes are worth reading twice before quoting the output in a board paper.

Use the portals for trend. Don't use them as your only answer to "which of our services is the problem".

Building the second column

The goal is modest: a spreadsheet beside the invoice, refreshed quarterly, that converts usage into an estimate with the working shown. Four steps.

1. Get energy, or approximate it. Some providers expose kWh per service. Where they don't, build a proxy from instance family, hours and a published or vendor-supplied power figure. Write the proxy down. A crude but documented conversion beats a sophisticated number with no provenance.

2. Apply a grid factor for the region. The National Grid ESO carbon intensity API publishes half-hourly and annual figures for the UK, and regional breakdowns. Use the annual average for a backward-looking report; use half-hourly data if you're modelling a shift in when batch jobs run. Don't lift a figure from a blog post written several years ago — the UK grid has been decarbonising quickly and stale numbers flatter or punish you unfairly.

3. Multiply by the provider's power usage effectiveness. If they publish a PUE for the region, use it. If they don't, assume somewhere between 1.2 and 1.5, and label it as an assumption in bold. That number carries real weight — it's the overhead of cooling and distribution — and guessing silently is how a carbon report loses credibility.

4. Record the boundary. What's in: compute, storage, managed databases. What's out: embodied emissions in the hardware, networking between regions, support contracts, the laptop the developer is reading this on. Whatever you choose, choose it once and keep it.

The assumptions register is the actual deliverable

One tab. Every input gets a source, an owner and a date. Provider PUE — sourced, dated. Grid factor — sourced, dated. Conversion proxy — sourced, dated. When better data arrives, you swap the input and the total moves, and you can explain precisely why it moved. That's the difference between a number and a guess wearing a suit.

This register is also what makes the figure defensible externally. "We estimate 40 to 70 tonnes for the financial year, location-based, UK regions only, excluding embodied emissions" is a sentence an auditor, a customer's procurement team or a non-executive director can work with. "About 50 tonnes" is not.

Four habits that keep it honest

Report a range, not a decimal point. Your inputs are estimates; carry that uncertainty through rather than burying it.

Never net off offsets in the second column. If your organisation buys credits, that's a third column, clearly labelled, and it does not reduce the emissions figure.

Restate when the boundary changes. If you add a new subsidiary or move a workload to a different region, restate prior quarters so the trend line means something.

Refresh on the same cadence as the invoice. Quarterly is plenty. Annual is where these exercises go to die.

The questions worth asking at renewal

Five, and none of them are unreasonable: can you give us a location-based figure for our specific regions; what is the methodology and is it externally assured; how granular is the data by account, tag or service; what is the publication lag; and what is excluded from the number. A provider who can answer all five is worth the premium. One who can't has told you something useful too.

The point of the second column isn't a pledge or a press release. It's a brake. It's the thing that makes someone pause before moving a workload to whichever region is cheapest that week, and ask what it does to a number that now appears in the board pack. That's a decent return on a spreadsheet.