Octopus Energy lost our smart meter data for 17 months – now wants to bill on estimates

matt_drummer

Scot_39 said:

But certainly from day 1 of smart TOU - all 1/2 hourly billed tariffs on systems - import and export - that rely on regular comms - it should have really been the suppliers responsibility to track serious failures.  

Why?

The only tariffs that suppliers have to make available are those set out by OFGEM.

Anything else they offer is their choice and their rules apply, if you don't like the rules don't take the tariff.

You would think that anybody interested enough to install solar panels and battery storage and then choose a tariff to allow them to import and export at varying rates would be checking how it was going on a regular basis.

Why should the supplier be tasked with doing this for you.

And, in fact, they do alert you, because it becomes obvious when you get the next bill after the failure that something has gone wrong.

brianposter

matt_drummer said: if you don't like the rules don't take the tariff.

The law actually says that the T&C must be reasonable. The relevant clause may well be considered unreasonable both because it puts all onus on the customer and also because the relevant correct data is available.

Ildhund

Scot_39 said:

... the limit is widely reported here as being 13 months - 

That's the extent of the consumption data - half-hourly usage figures. Register readings as used for billing have a much shorter lifespan, if I understand SMETS2 correctly (a big IF, I should say):

5.7.5.13    Daily Read Log

A log capable of storing thirty one UTC date and time stamped entries of the Tariff TOU Register Matrix [INFO](5.7.5.34), the Tariff TOU Block Register Matrix(5.7.5.35), the Active Import Register [INFO](5.7.5.3) and the Active Export Register [INFO](5.7.5.2) arranged as a circular buffer such that when full, further writes shall cause the oldest entry to be overwritten.
[emphasis mine]

The let-out clause you quoted starts with "If we are unable to estimate the missing readings, ..." 13 months'-worth of usage data should be retrievable from the meter, assuming its battery hasn't run down.That's one of its principle functions (retaining stored data even when there's no power) along with keeping the clock running. Those data together with the latest readings should make it possible to estimate the missing readings for the past year, so §1.5 wouldn't seem to apply. Older than that will have to remain a mystery.
 

Scot_39

Estimation isnt the same as after normal event data recovery - thats still an actual real measurement.

I suspect the basis of  1.5 on estimtion or not -  is an acceptable  cummulative cost error risk basis - for both parties.  4 days in a month limits potential losses to both parties - repeating for weeks or in ops case months - increases significantly the risk of losses accumulating for both parties.  As the estimates could err either way leading to underbilling or overbilling. 


The OP was on a variable tou import (timed at low rate times) and export (timed at high rate times) tariff by the sounds of things.  Daily registers wouldn't replicate that.

And if the limit is 3m for export - and not the 13m for consumption as draft spec section referenced above in my earlier post - by now more than half tge total data is lost from meter cyclic buffers - including this summers high export numbers.

Cadwallon

Thanks for the thoughtful replies — I appreciate people taking the time to engage, even where views differ.

A bit more context may help explain why this wasn’t obvious to us at the time.

We are pensioners and downsized into this property around three years ago. It required extensive renovation before it became habitable, and as part of that we invested in solar PV and battery storage to reduce long-term energy costs and do our bit environmentally. After a lot of research and visiting working installations, we chose a GivEnergy system that had been developed to work specifically with Octopus’s half-hourly Flux tariffs, with the intention of buying electricity cheaply, exporting at higher-price periods, and broadly balancing out costs over the year.

The system has a live dashboard showing when we are importing and exporting, and that has always continued to operate correctly. We also checked bills carefully in the early months. Flux billing, however, is not like traditional bills with clear start/end readings and simple totals — the electricity element is effectively a net calculation based on half-hourly import and export data, and the presentation varied month to month. Sometimes there would be a gas-only bill, sometimes delayed generation credits, sometimes catch-ups or “still processing” notes.

What mattered to us was whether the overall outcome, ie bill totals, matched expectations — and they have. The monthly totals broadly aligned with what we expected from the system, including periods when we made use of Octopus free-energy events, for which we were explicitly credited. Nothing in the account suggested we were being billed on estimates rather than live data, and Octopus never notified us that half-hourly data had stopped flowing.

It was only in November 2025 that Octopus contacted us to say they had in fact lost electricity smart-meter data back in July 2024. Until then, both the bills and the account graphs appeared normal, which is why this wasn’t apparent earlier. The subsequent engineer visit in December confirmed the electricity meter would not communicate, but also coincided with the previously working gas smart meter stopping as well.

I fully accept that customers should check bills — and we did, along with the dashboard (we have exported and imported normally during the day) — but in this case there was nothing on the account to indicate a switch to estimated billing, nor any notification from the supplier that smart data was missing. My concern isn’t that technology fails (it does), but that a prolonged loss of smart data wasn’t detected or acted on by the supplier, and that the proposed resolution now relies on averaging that can’t reflect how an optimised half-hourly system actually operates.

I hope that clarifies our position. I’m not suggesting this is a common case, but it does highlight how opaque smart TOU billing can be when something goes wrong.

Thanks again to those who’ve contributed constructively.

QrizB

I'm not familiar with Flux billing, but many of the Octopus smart tariffs include full 30-minute data as part of the pdf bill.

Do Flux bills normally include this level of detail?

Cadwallon

QrizB said:

I'm not familiar with Flux billing, but many of the Octopus smart tariffs include full 30-minute data as part of the pdf bill.

Do Flux bills normally include this level of detail?

Thank you. Yes, a few early bills contained 30-minute data. However, that changed, and I gave up on detailed analysis of the bills after the first year because there was so much month-to-month variability, with catch-ups, omissions, and changes to previous totals. However, when I looked into the figures, they were fine, and this gave me confidence that the number crunching was working. After that, I concentrated on how much Octopus was charging me each month. Regular checks of the dashboard showed we continued to import and export as predicted during the day. I was expecting us to be in electricity credit and for that to cover our gas bills over the year. This is more or less what happened, so we were happy. I had confidence in the supplier. I was shocked to hear they must have been running on estimates and were now planning to destroy the true data held in the meter. I looked up whether it was possible to read the stored data directly from the meter, and this appears to be the case.

MattMattMattUK

Cadwallon said:

QrizB said:

I'm not familiar with Flux billing, but many of the Octopus smart tariffs include full 30-minute data as part of the pdf bill.

Do Flux bills normally include this level of detail?

Thank you. Yes, a few early bills contained 30-minute data. However, that changed, and I gave up on detailed analysis of the bills after the first year because there was so much month-to-month variability, with catch-ups, omissions, and changes to previous totals. However, when I looked into the figures, they were fine, and this gave me confidence that the number crunching was working. After that, I concentrated on how much Octopus was charging me each month. Regular checks of the dashboard showed we continued to import and export as predicted during the day. I was expecting us to be in electricity credit and for that to cover our gas bills over the year. This is more or less what happened, so we were happy. I had confidence in the supplier. I was shocked to hear they must have been running on estimates and were now planning to destroy the true data held in the meter. I looked up whether it was possible to read the stored data directly from the meter, and this appears to be the case.

They would not be planning to "destroy" anything. Sometimes data can be recovered from a non-communucating smart meter, other times it cannot be recovered, it depends on the specifics of the failure, e.g. Just comms, or something within the meter itself. 

I think there are obvious issues on both sides, but you only have yourself to blame for your failure to check the bills for more than a year.

QrizB

Cadwallon said:

QrizB said:

I'm not familiar with Flux billing, but many of the Octopus smart tariffs include full 30-minute data as part of the pdf bill.

Do Flux bills normally include this level of detail?

Thank you. Yes, a few early bills contained 30-minute data. However, that changed ...

I suspect that the loss of 30-minute data was the clue that showed comms loss with your smart meters, and is when your billing problems started.

An opportunity missed by both parties.

Qyburn

Cadwallon said:

A bit more context may help explain why this wasn’t obvious to us at the time.

How did your bills appear before and after Octopus stopped getting h/h data?  I'm not on Intelligent Flux so don't know the format - do they literally bill on net readings, or do they bill import and export separately albeit at the same unit rate?

For example here's the billing line from one of our bills, import only. How does that section of your bill appear, both before and after?