I'm working on a TOU billing dispute with Nashville Electric Service for a Schedule TOU-2 commercial customer. The interval data clearly shows their peak demand occurred at 2:47 PM on March 15th with 487 kW, but NES billed them based on a 3:15 PM reading of 392 kW. The 15-minute interval files I downloaded show 487, 485, 483, 479 kW from 2:45-3:00 PM, then it drops to the 390s. Their billing system somehow missed the actual peak and locked onto a lower 15-minute period. Has anyone successfully challenged TOU peak period misidentification?
Time-of-Use peak identification errors - Nashville Electric
Paula, that sounds like a billing system software issue where the TOU peak search algorithm isn't scanning all 15-minute intervals correctly. Black Hills Energy up here in Rapid City had similar problems with their new billing system rollout. The peak demand window search was getting truncated or offset by timezone issues. Document everything with screenshots of the actual interval data versus what they billed. Most utilities will correct these once you can prove their system made an error.
I've seen this with Dominion Virginia Power (now Dominion Energy) on their Schedule GS-3 TOU customers. Their billing system was applying daylight saving time adjustments incorrectly to the peak search window. A 2:47 PM actual peak was getting recorded as 3:47 PM in their system, which put it in the wrong TOU period entirely. Cost our client about $15,000 in peak demand charges. Dominion eventually fixed their billing software but it took six months of back-and-forth.
Out here with Rocky Mountain Power in Salt Lake, we always request the complete 15-minute interval dataset for the entire billing period, not just the summary report. Their Schedule 23 TOU billing sometimes shows peak demand that doesn't match the highest 15-minute reading in the raw data. Usually it's a matter of the peak search looking at the wrong time window or ignoring certain intervals marked with quality codes. The raw data tells the real story.
Paula, definitely challenge this. Duke Energy had similar billing software issues where their peak demand search algorithm was only looking at the top of each hour instead of scanning all 15-minute intervals. We caught it by comparing the billed peak time against a sorted list of all interval readings for that billing period. The actual peak was 15 minutes before what they billed. Saved our client $8,200 in demand charges after Duke corrected their system.
This is exactly why we always download the Green Button data in addition to the utility's billing summary. Georgia Power Schedule PL-1 customers down here in Savannah have had similar peak identification issues. The Green Button XML files contain all the raw 15-minute interval readings with timestamps. When there's a discrepancy, we can sort the data ourselves and identify the true peak demand period. It's become standard practice for any TOU billing audit.
Thanks everyone for the advice. I've requested the complete Green Button dataset from NES and will compare it against their billed peak. The more I look at this, the more it seems like their billing system is only checking hourly peaks instead of true 15-minute intervals. If that's the case, every TOU customer could be affected. Will definitely escalate this through their regulatory affairs group if the data confirms the billing error.
Paula, you might also want to check if NES is properly handling demand resets or meter maintenance events. Tucson Electric Power had an issue where scheduled meter maintenance was creating false peak readings in their interval data. A meter reset at 3:15 PM would show a brief spike that got recorded as peak demand, even though the actual load was much lower. TEP eventually had to review and correct thousands of TOU bills once they identified the problem.
Great point about meter resets Patricia. Oncor down here in Dallas had the same issue with their Advanced Metering Infrastructure. Meter communication resets were creating artificial demand spikes that showed up as interval peaks but weren't real load. The billing system couldn't distinguish between actual demand and reset artifacts. Always check the meter event codes when you see suspicious peak readings that don't match the load profile pattern.
Update: Got the Green Button data from NES and you were all right - their billing system was missing the true 15-minute peak. The actual peak was 487.2 kW at 2:47 PM but they billed based on 392.1 kW at 3:15 PM. NES acknowledged the billing software error and credited our client $4,850 for the demand charge difference. They're now reviewing all TOU-2 accounts for similar errors. Thanks for all the guidance on this one!
Excellent work Paula! This is exactly the kind of detailed analysis that protects our clients. SCE&G here in Charleston has been pretty good about TOU billing accuracy, but we always verify the peak identification against the raw interval data. Your case will help other auditors know what to look for when TOU billing seems off. Definitely worth documenting this methodology for future reference.