Stuart A from Boulder, CO. Xcel Energy territory. Found something strange on a brewery client. They are on the SG-TOU rate with on-peak 9am-9pm. I pulled their 15-minute interval data and compared it to their production logs. The peaks on the interval data consistently show up one hour later than the actual equipment startup times. If they start the mash tun at 5am, the interval data shows the demand spike at 6am. Every single day, one hour off. I think the TOU meter is programmed to Mountain Standard Time but Colorado observes daylight saving time. So for 8 months of the year the meter clock is one hour behind actual local time. This means the last hour of their evening production — 8pm to 9pm local time — is being billed as on-peak when it should be off-peak because the meter thinks it is 7pm to 8pm.
TOU meter programmed with wrong time zone — peak charges off by one hour
Stuart, the daylight saving time issue with TOU meters is a known problem that should not still be happening in 2019 but here we are. Older TOU meters were sometimes programmed in standard time year-round because they lacked automatic DST adjustment. If the billing system does not compensate, customers get one hour of misallocated peak charges for 8 months every year. This has been litigated in multiple states.
I have seen this exact issue in Xcel Colorado territory before. It affected a whole batch of meters installed between 2008 and 2012. Xcel acknowledged the problem and was supposed to have reprogrammed all affected meters by 2015. Sounds like they missed some. Stuart, when was your client meter installed?
Carl, the meter was installed in 2011. So it fits right in that window. If Xcel acknowledged the problem and was supposed to fix it, my client should have been corrected years ago. This strengthens the case significantly.
The financial impact of a one-hour shift depends on what happens during that hour. If the client has heavy load running from 8-9pm that the meter thinks is 7-8pm (still on-peak under the meter clock), there is no impact. But if the client has load from 8-9pm that should be off-peak but the meter assigns to on-peak because it thinks it is still 7-8pm during DST months... actually wait. Let me think about this again. If the meter clock is MST and local time is MDT (one hour ahead), then when the actual time is 9pm (end of on-peak), the meter thinks it is 8pm (still on-peak). So the meter would record 8-9pm local time as on-peak when it should be off-peak. Is that right Stuart?
Pete, you have it exactly right. During DST months (March to November), the hour from 8pm to 9pm local time is being billed as on-peak because the meter thinks it is 7pm to 8pm. My brewery runs the bottling line from 7pm to 10pm most weekdays. So one full hour of bottling line demand — about 95 kW — is being charged at the on-peak rate instead of off-peak. The rate differential is about $0.04/kWh plus the demand charge allocation. Over 8 DST months per year, this adds up to roughly $3,800 annually.
And if the meter has been wrong since installation in 2011, that is 8 years of $3,800 per year — over $30,000 in cumulative overcharges. What is the Colorado lookback period?
Yuri, Colorado allows a 4-year lookback on utility billing errors. So the recovery is capped at about $15,200 even though the total error is much larger. Still a great case.
Filed the dispute with Xcel including the interval data analysis showing the consistent one-hour offset, the 2011 installation date matching the known batch of mis-programmed meters, and Carl''s reference to Xcel''s prior acknowledgment of the DST issue. Xcel responded within two weeks — they verified the meter clock error, replaced the meter, and agreed to rebill the full 4-year lookback. Credit to the account: $15,840. Slightly more than my estimate because the rate differential was larger in some months.
Stuart, nice work. And thanks for confirming there are still mis-programmed meters out there from that batch. I am going to check my other Xcel TOU clients who were installed in that 2008-2012 window.
This is a perfect example of why interval data analysis is essential. You cannot find a one-hour timing error by looking at monthly bill summaries. You need the 15-minute data to see the pattern. Good detective work Stuart.