I'm working on a complex Georgia Power Schedule PL-1 audit for a manufacturing client in Atlanta and finding multiple issues with how their interval data is being processed for billing. The customer has significant load shifting capabilities and has been actively managing their usage to avoid peak demand periods, but Georgia Power's billing doesn't seem to reflect their actual load profile. Their 15-minute interval data shows they're successfully avoiding the 1pm-7pm peak window most days, yet they're still being hit with peak demand charges of $18.92/kW. The math just doesn't add up when I compare their interval usage to the billed amounts. Anyone else auditing Schedule PL-1 accounts and seeing similar discrepancies?
Georgia Power Schedule PL-1 interval billing discrepancies
Greg, Georgia Power's PL-1 schedule has some tricky provisions around seasonal adjustments and coincident peak calculations that might explain what you're seeing. Are you accounting for the system coincident peak factor? Sometimes customers think they're avoiding peak periods but they're still contributing to the system peak, which affects their billing demand calculation.
Pete's onto something with the coincident peak issue. I've seen similar confusion with large commercial accounts where customers focus on avoiding their individual peak but don't realize they're still subject to system-wide peak adjustments. Georgia Power might be applying a capacity factor based on the customer's load during the utility's actual system peak hours, regardless of when the customer's individual peak occurs.
That's a great point about coincident peak. I need to get Georgia Power's system peak data for the billing periods and see if the customer was drawing significant load during those specific intervals. The PL-1 tariff language around coincident peak is pretty convoluted - it references both individual customer peak and system contribution factors. This could definitely explain the disconnect between their load management efforts and the actual bills.
Greg, I'd also double-check the demand measurement window. Some utilities use rolling 15-minute averages while others use fixed interval periods. If Georgia Power is using a rolling average and your client has short-duration high-demand events, those might be getting smoothed into adjacent intervals and affecting demand calculations in ways that aren't obvious from the raw interval data.
Also worth checking if Georgia Power has any demand response or interruptible provisions built into Schedule PL-1. Some utilities offer demand charge reductions in exchange for load shedding rights, but then apply penalties or adjustments if the customer doesn't perform when called. The billing might reflect adjustments related to DR program participation rather than just straight interval usage.
Good catch Glenda - this customer is enrolled in Georgia Power's Interruptible Service program which gives them a $2.40/kW credit on demand charges in exchange for load shedding capability. But looking at the bills, it seems like the credits aren't being applied correctly. They should be getting about $1,020/month in IS credits but I'm only seeing $340/month. This might be a separate billing error on top of the demand calculation issues.
Greg, that's turning into a pretty complex audit with multiple billing components to verify. Make sure you're documenting each issue separately - coincident peak calculations, interruptible service credits, and any demand measurement methodology questions. Georgia Power is generally good about fixing billing errors once they're properly documented, but you'll need clear evidence for each component of the discrepancy.
Thanks Clyde. I'm building a comprehensive analysis with separate sections for each billing component. Found additional issues with the customer's power factor calculations too - their interval data shows they're maintaining 0.95+ PF but getting billed penalties for poor power factor. This account has at least $15,000/year in billing errors across multiple rate components. Going to file a formal complaint with Georgia Power once I finish documenting everything.
Greg, excellent detective work! This is exactly the kind of comprehensive audit that saves customers real money. $15K annually is substantial and shows why detailed interval data analysis is so critical on these complex commercial rate schedules. Georgia Power has been pretty responsive to well-documented billing complaints in my experience, so you should get a good result if your analysis is solid.
Randy's right about Georgia Power being responsive to legitimate complaints. I had a similar Schedule PL-1 case last year where multiple billing components were wrong and they issued a $32,000 refund once the errors were proven. The key is having ironclad documentation and showing your work on every calculation. Don't let them dismiss any part of your analysis without a detailed response.
Update: Filed the complaint with Georgia Power yesterday with 47 pages of supporting documentation covering all the billing discrepancies. Their initial response acknowledges receipt and they've assigned a senior analyst to review the case. Expecting this to take 4-6 weeks to resolve given the complexity, but confident we've got solid evidence for each claimed error. Will post results once it's settled.
Great work Greg! 47 pages shows you did your homework thoroughly. That level of documentation usually gets the utility's attention and leads to faster resolution. Looking forward to hearing how it turns out - these complex commercial rate audits are some of the most challenging but also most rewarding when you find significant errors.
Couldn't agree more Glenda. Greg's thoroughness on this audit is impressive and should serve as a model for anyone working on complex Schedule PL-1 accounts. The multiple billing component errors he found - coincident peak, interruptible service credits, power factor penalties - show why you can't just look at one piece of the billing puzzle. You have to analyze every component of these commercial rate schedules to catch all the potential errors.