Utility Customer Information and Billing System Replacement: Why a Rate Ordinance Nobody Told IT About Sends Out 12,000 Wrong Bills

The ordinance passed in May, IT found out on 20 June

A municipal utility bills 60,000 customers for electric, water, sewer and refuse on one statement. In May the council passes a rate ordinance effective 1 July: a new third tier on residential water, a change to the low income discount from a flat credit to a percentage, and a franchise fee recalculated on a different subtotal. The billing supervisor finds out in the third week of June, when someone forwards her the ordinance.

The legacy system can hold the new tier. What it cannot do is prorate the tier boundaries for a customer who moved in on 12 July, because its rate tables assume a whole billing period. The workaround that gets used is a flat allocation, which puts several thousand accounts into the wrong tier by a few units. Nobody notices until August, when the complaints start and the finance director asks whether the July distribution to the water fund was right. Correcting it means a manual rebill for every affected account, which the system supports one account at a time.

This is the shape of utility billing failure. It is almost never a crash. It is a tariff the system cannot express, a workaround applied under time pressure, and a correction cost measured in staff weeks plus statutory refund interest.

Problem one: the rating engine is the whole system, and it is the part vendors treat as configuration

Read any CIS demo script and rating gets ten minutes. In reality it is where the money is and where every implementation overruns. A single residential electric bill can carry a customer charge, an energy charge across seasonal blocks, a time of use split with holiday calendars, a power cost adjustment that changes monthly, a net metering credit with carry forward and an annual true up, a low income discount, a franchise fee, a state tax and a municipal tax, and the order of operations between the fee and the taxes is set by ordinance rather than by convention.

Then there is the commercial side. A demand ratchet that bills the higher of current demand or a percentage of the peak in the preceding eleven months requires the system to reach backwards into history every cycle. A customer who changes rate class mid period needs two calculations stitched together. Standby and interruptible rates carry conditions tied to events. None of that is exotic in utility terms and all of it is where packaged rating models start requiring vendor services.

The requirement that decides your architecture is re-rating. Commission orders and council ordinances arrive with retroactive effect more often than anyone admits, and rate cases settle months after the rates took effect. If your rating logic cannot be versioned by effective date and replayed over a period that already billed, every retroactive change becomes a manual project. Build that capability first and the rest of the system gets easier.

Problem two: disconnection is legally dangerous and is coded as a report

The disconnect list is generated by a query. In most legacy systems it is a query somebody wrote a decade ago that filters on balance and age. What it usually does not fully encode is the layer of consumer protection sitting on top: medical certification holds, weather related moratoria that vary by state and by season, notice periods with specific delivery requirements, payment arrangements that must suppress the account, deposits on hand that offset the arrears, and third party notification for elderly or vulnerable customers.

Every one of those is a rule with a date and a source, and getting one wrong is not a billing error, it is a household without water and a story. In our experience this is the single most under specified area in CIS replacement projects, because it lives in the billing supervisor's head and in a binder of commission orders rather than in the requirements document.

What a build should do is make each protection a first class rule object with an effective date, a source citation and a test, and then make the disconnect candidate list a deterministic output that can be explained account by account. When a customer or a council member asks why an account appeared on that list, the answer should be a rendered chain of rules, not a database query someone has to interpret.

Problem three: conversion is the project, not a phase of it

Utilities consistently plan conversion as a workstream and then discover it is the critical path. What has to move is not just customers and balances. It is deposits with interest accrued under state rules, budget or levelised billing plans mid cycle with their own accumulated variance, payment arrangements with remaining instalments, service orders in flight, meter and service point history, decades of consumption used for estimation and for high bill investigations, collection status, bankruptcy flags and lien history.

The legacy extract will be incomplete, and the gaps are found by reconciliation rather than by inspection. Plan for at least three full mock conversions with a financial reconciliation at each, meaning the sum of converted balances ties to the legacy trial balance to the cent, and a sample of complex accounts is manually recalculated in both systems. Utilities that skip mock conversions go live and spend the following year finding accounts whose budget billing plan silently reset.

Where Oracle, SAP, NISC, Harris, SEDC and Gentrack actually fit

Oracle Utilities Customer Care and Billing is deep and it is the right answer for large investor owned utilities with the implementation budget to match. The caution is proportion: implementation and configuration routinely cost a multiple of licence, and mid sized utilities underestimate that ratio badly.

SAP S/4HANA Utilities is the same shape of decision. If your organisation already runs SAP and the finance integration is the priority, it makes sense. If it does not, adopting SAP to bill water is an enormous amount of platform for the problem.

NISC iVUE is genuinely strong for electric cooperatives, and its integration with the wider cooperative ecosystem is a real advantage. The trade is that you adopt their operating model, and utilities with unusual local tariffs or a municipal multi commodity bill find themselves at the edge of what the model expects.

Harris Advanced Utility Systems and SEDC both serve the mid market and cooperative space competently, and their strength is that they know this domain deeply. Their architecture is older, so extension tends to route through services rather than through an API your own team uses, which becomes the constraint once you want a modern customer portal or your own analytics.

Gentrack is capable and is strongest where markets are deregulated and where water billing is complex, reflecting its heritage. In North American municipal power it is a less common fit.

Notice the pattern. Every one of these is a reasonable purchase for the customer, account, receivable and service order machinery. What none of them does cheaply is express a tariff written by your council last month.

The hybrid that usually wins

Here is our opinion, stated plainly, and it costs us revenue to say it. A full ground up CIS replacement is rarely the right call below roughly 80,000 customers. The boring 80 percent of a CIS, meaning customer records, accounts receivable, cash posting, service orders and collections, is commodity functionality that a package does well and that you should not pay to have rebuilt.

What you should build is the rating and determinant service, exposed as an API the package calls or feeds, holding your tariffs as versioned rule sets with effective dates, capable of re-rating any period on demand, and testable with a regression suite of real accounts. Alongside it, build the customer facing layer, because self service, usage presentment, payment arrangements online and high bill explanations are where customer satisfaction actually moves, and packaged portals are consistently the weakest module in the suite.

That combination gives you the flexibility where your requirements are local and the stability where they are not. It also means the next rate ordinance is a configuration change your own team makes in a week instead of a vendor change request quoted in months.

What this costs and how long it takes

Across the enterprise systems Digital Heroes has delivered, the bands for this category look like this. The rating and determinant service with tariff versioning, re-rating and a regression suite runs $200,000 to $450,000 over 5 to 8 months. A customer self service and presentment layer on top of it runs $80,000 to $180,000 over 3 to 5 months. A full custom CIS spanning customer, receivables, payments, service orders, arrears, disconnect workflow and multi commodity billing runs $700,000 to $2,000,000 across 12 to 24 months, with conversion frequently a quarter of that total on its own.

What drives cost in this specific domain: the number of commodities on one statement, because each adds its own rate structures and its own fund distribution. Net metering and distributed generation, since export credits with carry forward and annual true up are a separate calculation problem. Prepay programmes, which change the entire billing cadence. The age and quality of the legacy extract. And how many of your rules exist only as institutional knowledge, which you discover during the first mock conversion.

How to choose a developer for utility billing work

Give them your three most awkward tariffs and ask them to model the calculation before you sign anything. If they do not ask about proration on partial periods, about the order of fees and taxes, or about what happens on a rate class change mid cycle, they have not billed a utility.

Ask how they would re-rate 40,000 accounts for a period that already invoiced. The answer should involve versioned rule sets and a replay path with a reconciliation report, not a script and a maintenance window.

Ask them to describe the disconnect protections in your state without prompting. They will not know them all, and that is fine, but they should immediately treat medical holds, weather moratoria and payment arrangements as rule objects rather than as filters in a report.

Ask about mock conversions and insist on at least three with financial reconciliation to the cent. A developer who proposes a single conversion rehearsal is planning to find your data problems in production.

Ask who owns the repository and the infrastructure accounts, and put it in writing before kickoff. At Digital Heroes the client owns the code from the first commit. Your next step: take the last three rate ordinances your council passed and time how long each one took to appear correctly on a bill. If the answer is measured in months, the rating engine is where your money should go first.