My flat tells me the electricity bill in advance

An electricity bill that surprises you is almost always a bill for something you did three months ago. My setup turns that around: it projects the running month forward and tells me where the bill is heading — not what it was.

This runs in Kapfenberg and in Merano. Two countries, two completely different tariff models, the same underlying idea.

What actually arrives

On the last day of the month at 23:50 a notification comes through. It contains:

• the month’s consumption,
• the expected bill,
• the split into cost components,
• and in Kapfenberg the solar contribution, if any.

On top of that, the running projection to month’s end during the month. That is the part that changes a decision — the monthly report on the last day is only the confirmation.

Why the projection is not simply “times 30”

This is the mistake almost every consumption app makes. An electricity bill consists of parts that behave completely differently:

• Volume-dependent: the energy price, the grid usage price, and the taxes and levies attached to them. That scales with consumption.
• Fixed: the standing charge and the grid provision component. Those fall due once, whether the month is half over or not.

Double the running total on the 15th and you count the fixed part twice and alarm yourself for nothing. The projection scales only the volume-dependent part and adds the fixed part once.

One thing matters here: “grid costs” is not a fixed block. On my bill the grid share is the largest item of all — and most of it hangs on the kilowatt hours consumed. Book grid as a standing charge and you are calculating in the wrong place.

How I know the formula is right

A forecast that has never been checked against a real invoice is a number with decimal places and nothing else. Hence the reconciliation:

Item	Formula	Invoice
Energy	9.844	9.84
Taxes	2.657	2.66
Grid	13.048	12.89
Total	25.55	25.39

Beyond that, all 14 available invoices were recalculated. The sum of the individual items hits the invoice total to the cent every single time — so the item list is complete, no hidden position is missing.

The only deliberate deviation is a seasonal discount on the grid usage price that applies during the day from April to September. The formula does not model it: in the invoice checked that was 16 cents, or 0.6 per cent. Building a third metering chain for that is not worth it. From April to September the forecast therefore runs high by that amount; from October to March the deviation is zero. Anyone needing more precision now knows where it is missing.

A trap in passing that I nearly fell into: the detail tables on the invoice are net, the figures in the price sheet are gross. Mix the two and you are 20 per cent out, and then you go looking for the error in the measurement.

What is in the two homes

	Kapfenberg	Merano
Metering	Shelly Pro 3EM, netted	Shelly EM
Tariff	smartWEEKEND with peak/off-peak	Alperia with ARERA components
Notification	push to iPhone	Signal
Speciality	separate peak/off-peak counters	solar contribution in the billing

That the same principle models two such different tariff worlds is for me the real proof: it is not the device that decides, but whether you rebuild the price model properly.

Where the figure ends

• It is an estimate, not an invoice total. The projection takes consumption so far and carries it forward. A cold week or a visitor shifts it.
• The measurement is not at the calibrated meter. Consumption comes from a summation over the clamp meter, not from the official register. A separate sensor therefore runs alongside showing how far peak plus off-peak diverge from the total count. I look at it regularly — a divergence that grows is the first sign of a metering problem.
• The first partial month reads low. Counting starts at zero. Start mid-month and you get a forecast for half a month and believe you use little.
• One assumption is still unverified. That all thirteen public holidays really count as cheap time only follows from the wording of the tariff. The first month in which that can show at all is October 2026, when a holiday falls on a working day.
• There is no budget alarm mid-month. What exists is the running projection and the monthly report. A notification at “80 per cent of budget reached” is not set up — that would be a separate build.
• Netted is not the same as consumed. With solar in the house, the netted measurement is what crosses the meter, not what the appliances drew.

So what?

The benefit is not in saving money but in not being startled. On the 20th I know whether the month is going to be expensive, and I can still change something — move the laundry into the off-peak window, run the air conditioning differently. After the bill arrives, every insight is worthless.

If you pull a single value into your dashboard, make it this one: expected monthly total, updated hourly. Everything else is decoration.