Checking an electricity bill line by line, when the price changed every fifteen minutes

  • Tested on firmware v1.2.1
  • Intermediate

The statement arrives with a total on it. You have a feeling about whether that total is right, and nothing to put next to it.

That asymmetry is the whole problem. Your supplier has a number built from readings you never saw, using prices you took on trust. You have a month of memories.

If your own meter kept the price it applied to every period, you have a second account to put beside theirs — not a proof that the bill is wrong, but a way to find out where the two part company.

What you have that the statement doesn't

The hub logs every closed 15-minute period's applied price, with where that price came from, and keeps it for 40 days. Download it from the Prices page as CSV.

⚠️ Do the download at the end of the month, not when the bill arrives. Forty days sounds like plenty against a monthly statement, and it is not: a 31-day month plus three weeks of billing delay is about 52 days, so by the time the envelope lands, the first dozen days of that month have already left the log. There is no way to get them back afterwards — so the habit that makes this article usable is exporting the CSV when the month closes, while the whole of it is still there.

For a bill older than that, what remains is the energy, not the prices: the hourly and daily records are still in the hub's history, but the price applied to each period is gone.

Behind that sits the measurement itself: 60 days of hourly records per point, about 13 months of daily ones and 3 years of monthly ones. So the price log is the thing that expires first, and it is still the one that outlives a monthly bill — which is why it is the anchor for this exercise rather than the history.

Each row tells you three things that a statement never does:

  • which period it was, to the quarter of an hour;
  • what price was applied to it;
  • where that price came from — your source, your backup, a price pushed in from Home Assistant, the hour's mean, or your tariff plan's zone rate.

That last column is the one people skip and then come back for. A period priced from your plan rather than the market means the market price was missing at that moment — which is not an error, but it is a different number from the one you were expecting.

Read it in this order

Not "compare the totals and see". Totals are the last thing to look at, because every kind of mistake lands in them and they all look alike.

1. Check the magnitude first. If your figure is out by roughly a factor of a thousand, you have a unit problem, not a tariff problem — a price entered or pushed per megawatt-hour instead of per kilowatt-hour. Nothing else behaves like that, and no amount of tariff fiddling will fix it.

2. Then the direction. The size of the gap tells you which mistake it is:

  • too high by roughly the VAT share — an all-in price with your contract's components filled in as well, so the components are counted twice;
  • too low by much more than the VAT share — a spot price with the components still empty: what is missing is the grid fee, the taxes and the levies and the VAT on them, which together are far larger than VAT alone.

If the gap is big and downwards, do not go looking for a subtle fault: that shape is the price kind, and the formula is where it is laid out.

3. Then the fixed part. A gap of roughly your standing charge means nothing is wrong at all. The hub prices energy, per kilowatt-hour. A daily or monthly fixed amount is not in its figures and cannot be put there.

4. Only then, the periods. Open the log for the day that looks strangest and read the source column. A run of periods priced from the plan tells you the fetch failed then; a run at the hour's mean tells you the 15-minute / hour's-mean setting is doing what you set it to.

Four gaps, and what each one means

Your month differs from the statement by… What it is
about a factor of 1000 units — a price per megawatt-hour somewhere
about the net-to-gross difference the price kind, or a component entered with VAT already in it
about your fixed charge nothing: that part was never counted
a little, with no pattern two honest measurements of the same house, in different places

The last row is not a disclaimer. The hub sums what your clamps measured at the points you set as the supply; your supplier measures at its own meter, with its own clock and its own period boundaries. Those two will never agree to the last watt-hour.

What a match actually proves

Less than it feels like, and it is worth being clear about.

If your figures line up with the statement, you have evidence that your configuration is right — the price kind, the components, the zones, the currency. It means the cost figures you look at every day are built on the same arithmetic your supplier uses.

What it does not prove is that the statement is correct. You have checked your model against their result; both could be wrong in the same direction if, say, the tariff you entered is not the tariff you are actually on.

And it does not work the other way either: a gap is a question, not a finding. Every gap above has an innocent explanation, and three of the four are about your own setup rather than theirs.

What this will not settle

  • It is not an audit. The hub's figures are not a prediction of a line on a statement, and nothing in the app presents them as one.
  • Your supplier's statement is the authority on what you owe. If you believe it is wrong, their process — not a CSV — is what settles it, and your own figures are what you bring to that conversation.
  • It does not cover anything that is not energy. Fixed charges, meter rentals, levies billed per day: not in the hub's arithmetic at all.
  • It does not change what is already recorded. A period keeps the price that was applied to it. Fixing a setting changes what happens next, not what happened last month.

Where to read more