Retail Energy Supplier Billing Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a build scoped for two utilities get rebuilt for the third?

The first integration is always underestimated because it looks like a standards project. The transaction sets are published. The 814 handles enrollment, change and drop, the 867 carries usage, the 810 is the invoice, the 820 is the remittance, and the 824 reports application level problems. A developer reads that and quotes an EDI integration. What they have actually quoted is one utility's implementation guide.

Then the third utility arrives with a different switch timing rule, an account number format with its own check digit, a different name match tolerance, and a rejection code set that maps to nothing you already hold. The cheapest looking response is to copy the working integration and change it. Two years later you are maintaining several divergent codebases and the person who wrote the second one has left.

The fix is structural and it belongs in the first release, not the second. One canonical internal transaction model, one service point lifecycle, and a dialect adapter per trading partner that translates in and out. Adding a utility then becomes mapping, testing and certification against that partner, which is a few weeks of work rather than a project. Scope the first release around your two largest utilities deliberately, prove the adapter pattern against both, and leave the remainder on your current process until the pattern has survived a live certification with a real partner.

What goes wrong when you migrate an existing book of service points?

Most suppliers arrive at a build with a book stored as a status column. Each service point has a current state, updated by whichever process ran last, and no record of how it got there. Migration then looks trivial, because there is one field to copy. It is the most expensive assumption in the project.

The lifecycle is a state machine. A service point is submitted, accepted, pending, scheduled, flowing, on hold, dropped by supplier, dropped by customer, dropped for non payment, rescinded inside the cooling off window, or returned to the provider of last resort. Every transition has a source transaction, a date and a consequence for forecasting, settlement position and commission clawback. Copying the current status forward throws all of that away, and you discover the loss the first time a commission audit or a settlement dispute asks what the book looked like on a date in the past.

Do two things instead. Rebuild history from the transaction archive rather than the status field, replaying 814 responses and 867 deliveries against the new state machine so the book is reconstructable at any past date. Then reconcile the rebuilt book against three counts you can pull today: contracts signed, service points that flowed, and service points billed. Where those numbers disagree is where migration will hurt, and finding it in week four is far cheaper than finding it in month nine.

Why do utility EDI and remittance integrations break after launch?

They break because none of it was ever static. Utilities publish bulletins. An account number format changes, a new rejection reason code appears, a switch window moves, a test environment is retired. None of that reaches your system unless somebody reads the bulletins and somebody converts them into mapping changes. Most suppliers have neither role defined, so the first sign of a change is a queue quietly filling with rejections.

The second failure is monitoring the wrong layer. A 997 acknowledges that a file arrived and is loud when it fails, so it gets watched. The application level rejection is the one that says an enrollment actually failed, and it is quiet. A system that alerts on transport failures and reports application rejections as a monthly percentage will let a bad batch sit for weeks.

Remittance is the third. Under purchase of receivables the 820 arrives netted, partial, or carrying chargebacks for accounts that left the programme, and cash application logic written for the clean case falls over in month two.

Build the monitoring before the integration. Every trading partner gets an expected file calendar, so a file that does not arrive raises an alarm rather than producing a quiet zero. Exception queues rank by money at risk rather than arrival time. And bulletin review is a named responsibility with a weekly slot, not something the team gets to.

What happens when state renewal and disclosure rules are not covered?

Enrollment gets built. Billing gets built. The regulatory layer gets deferred because somebody described it as paperwork, and it is where the complaints and the penalties actually live.

Renewal notice timing, the content required in a disclosure statement, the length of the rescission window, how a variable rate change must be communicated, and what happens to a customer who ignores a renewal notice all differ by state. A supplier in six markets runs six rule sets, and the differences are not cosmetic. Hardcode any of it and you have a code change every time a commission amends a rule, which means you are late every time.

The slamming exposure is sharper. When a customer complains they never authorised the switch, you have a short window to produce the enrollment evidence: the consent artifact, the third party verification recording or its reference, the timestamps, the channel and agent identity, and the exact contract terms presented. A supplier who has to ask a broker for that evidence has already lost the argument.

Treat both as first class. Renewal and disclosure rules become configuration with an effective date per state, so a change is a data edit you can test against last month's population. Enrollment evidence attaches to the service point lifecycle at the moment of signing, is retained to the longest requirement in your footprint, and is producible in minutes by a service representative rather than by a project.

Should you build custom or configure what you already own?

If you are under roughly 15,000 residential customer equivalents in one or two markets, stay with EC Infosystems and put the money into acquisition. The fixed cost of running your own EDI operation, including certification with each utility and someone monitoring every bulletin, will exceed what owning it returns at that volume. That answer does not change because a developer told you a build costs less than the invoice. The invoice is not the number you are comparing against.

Configure rather than build in two more cases. If your product set is plain vanilla fixed price offers, there is nothing distinctive in the plumbing worth owning. And if your gap is enterprise billing depth rather than market process, Hansen Technologies is built for that, while Gentrack is designed around deregulated retail rather than adapted from a regulated utility product and is a serious option once you have scale to absorb the implementation.

Build when you are in three or more markets and adding another one waits on a vendor's release calendar. Build when your commercial model is the differentiator, for example demand response participation, a bundled solar or hardware product, or index products with a customer facing hedging story. Build when you cannot answer a lender's question about margin by channel and vintage, because that answer needs your data in your shape. A hybrid is often correct: keep the vendor running EDI in your smaller markets while you own the book, the margin model and the exception queues.

How do hidden costs get into the quote?

Retail energy quotes go wrong in predictable places, and every one of them is visible before you sign if you ask.

• Certification is treated as testing. It is a scheduled process on the utility's calendar with their availability, and it can add weeks per partner that no developer controls.
• Dual bill markets are quoted as an invoice template. They are invoice production, sales and use tax by jurisdiction, payment processing, dunning and collections.
• Historical usage is assumed to arrive in one shape. Utilities differ on whether it comes on request or automatically, at what granularity, and how corrections are transmitted. Corrections are the part that breaks billing.
• Purchase of receivables is quoted as a payment import. Partial remittances, netting and chargebacks are the real work, and finance finds them in month two.
• ISO settlement is quoted as a data feed rather than as a monthly reconciliation with the variance decomposed into known causes, which is the only version that is useful.

The honest bands from Digital Heroes delivery experience are $90,000 to $200,000 over 14 to 20 weeks for a first release covering the canonical transaction model, adapters for your current utilities, the lifecycle state machine and financially ranked exception queues, and $250,000 to $600,000 over 9 to 15 months for a full platform adding purchase of receivables accounting, settlement to billed reconciliation, dual bill invoicing and renewal management. A quote well below the lower band has left out one of the five items above.

What separates a build that works from one that fails here?

Four things, and all of them are decided before code starts.

The first is whether the team can explain, unprompted, the difference between a 997 and an 824 and what it means operationally when only the first is monitored. A team that cannot will rebuild the silent failure you are paying to remove.

The second is the shape of the first release. Two utilities, the canonical model, the lifecycle state machine and the exception queues, live in production, beats a full platform designed for six markets that has never touched a real certification. Certification is where assumptions die.

The third is who works the queues. Software that ranks exceptions by money at risk is worth nothing if nobody is accountable for clearing them daily. Name the person and put the daily open count on a report a director reads, before launch rather than after.

The fourth is ownership. You should own the repository, the cloud accounts, the mappings and the full transaction archive, in writing before kickoff. At Digital Heroes the client owns all of it from the first commit. Your transaction history is the evidence in a settlement dispute, a slamming complaint and a sale process, and it should never sit somewhere you cannot extract it from.

A useful first step takes a morning. Pull three numbers for last quarter: contracts signed, service points that flowed, service points billed. If they do not reconcile, you have found the business case and the first release scope in the same exercise.