I checked 25 invoice lines — and my own device was wrong

My gas bill is in cubic metres. What I pay for is kilowatt hours. Between the two sits a conversion that the bill prints but never explains.

So I did the arithmetic myself. Not on one line — on all 25 invoice lines from July 2024 to May 2026.

The result first: the bill is correct. Largest deviation across two years: 0.252 kWh out of 1539.728 kWh. That is 0.016% — pure rounding, which the grid operator itself points out.

Something else had been calculating wrongly. My own meter reader.

The formula has exactly two steps

Nm³ = Bm³ × conversion factor
kWh = Nm³ × calorific value for the month

Bm³ is the operating cubic metre — what the meter counts. Nm³ is the standard cubic metre: the same gas under standard conditions.

The meter measures a volume, not energy. How much gas sits in one cubic metre depends on the pressure and temperature it was measured at. That is exactly what the conversion factor corrects for.

The conversion factor: yours, not a generic one

Mine is 0.9470, and it is unchanged across all 25 lines.

It follows from the installation data: where the meter sits, the measuring pressure, and the altitude the grid operator uses for the district. A meter in someone else’s basement has a different one.

A side observation that cost me half an hour: the altitude on the bill is not the altitude my Home Assistant derives from the building’s coordinates. Both are correct. They are different things — a billing figure of the grid operator and a terrain elevation — and neither can be derived from the other.

Take the conversion factor from your own bill. Not from a table on the internet.

The calorific value: monthly since 2024

This is the part that makes an annual bill hard to follow from the outside. Since 1 January 2024 the grid operator uses a monthly actual calorific value per calorific district — no longer a value fixed once a year.

Across my 25 months:

	Calorific value	Month
Highest	11.585 kWh/Nm³	August 2024
Lowest	11.407 kWh/Nm³	February 2026
Spread	1.56%

1.56% sounds like nothing. On an annual consumption of 10,000 kWh that is around 156 kWh — and more importantly, the error is not random. Anyone using a single annual figure is systematically off in one direction in winter and in the other in summer.

The official monthly values come from the grid operator. Wiener Netze publish them on their gas calorific value page and as a PDF.

And now the device

A reader head sits on the meter and counts the pulses — that story is in 50 cubic metres off. It counts reliably. But it also displays kilowatt hours and euros, and for that it needs the same two numbers the bill uses.

It took them roughly right:

	Conversion factor	Calorific value	kWh per Bm³
Device	0.96	11.23	10.7808
Bill (April 2026)	0.9470	11.412	10.8072

Look at those two rows carefully. The device’s conversion factor is too high, its calorific value too low. In the product the two errors largely cancel each other out.

Two wrong numbers that partly cancel look more right than one wrong number.

What remains is 0.2 to 1.3% depending on the month. Across the 1005.4 m³ measured so far, around 26 kWh. No disaster — but enough that the device’s euro display is simply not the bill.

And that is the trap: a value that is off by 1% never stands out. It only stands out when you hold it against something.

What I built from this

Three decisions, and the third matters most to me.

The conversion factor is fixed in the package. It does not change as long as the meter hangs where it hangs.

The calorific value lives in an input I update monthly. Not hard-coded. A value that changes every month does not belong somewhere you will overlook it next time.

The device value stays. I do not overwrite it. Instead a separate sensor runs alongside and continuously reports the deviation between device and official calculation.

A value corrected in silence cannot be checked later. All you see from then on is the result of the correction — not how large it was, and not whether it still holds.

What I did not build: an automatic monthly query for the calorific values. It would be feasible, but it would need the customer number alongside the metering point number, and for twelve numbers a year that tinkering is not worth it to me. Typing one number a month is more honest than an automation I do not maintain.

What I’d suggest

1. Take the conversion factor from your own bill. It depends on where your meter sits. A number from the internet is somebody else’s.
2. Recalculate a single line. Two multiplications. If one checks out, as a rule they all do — and you finally know what the numbers mean.
3. Don’t trust your reader’s kWh display. It calculates with assumptions somebody entered at some point. Check the two numbers it uses.
4. Update the calorific value monthly — or deliberately use an average and write down that it is one. Either is fine. What is not fine is taking an annual figure and treating it as exact.
5. Leave the wrong value in place and report the deviation. Then next year you can still see whether your correction factor still fits.

So what?

For weeks I checked the meter, checked the reader head, checked the data transmission. I checked the bill last — because I quietly assumed the error was there.

It was in my own display. And it had been there since the day I set it up.

That is the same pattern as with the Blink cameras and the sensor on the radiator: I had a number, it looked plausible, and I failed to ask the obvious follow-up question.

Here that question would have been: where does my device get its calorific value from?

Doing the arithmetic yourself is not about distrusting the grid operator. In my case it was about distrusting my own display — the one I look at every day.