Utility Billing and CIS Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does tariff rating get treated as configuration when it is engineering?

Every customer information system demo gives rating about ten minutes and shows a rate table with tiers in it. That framing sets the expectation that tariffs are data entry, and it is why so many of these projects overrun in exactly the same place.

Look at what one residential electric bill actually carries: a customer charge, energy across seasonal blocks, a time of use split with a holiday calendar, a power cost adjustment that moves 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, with the order of operations between the fee and the taxes set by ordinance rather than by convention. On the commercial side a demand ratchet reaches eleven months back into history every cycle. A customer who changes rate class mid period needs two calculations stitched together.

The specific thing that catches people first is proration. A customer moves in on the twelfth of the month, and tiered block boundaries have to be scaled to a partial period. Many packaged rate models cannot express that, so somebody applies a flat allocation as a workaround, several thousand accounts land in the wrong tier by a few units, and nobody notices until complaints arrive two cycles later.

The fix is a scoping rule you can apply for free. Take your three most awkward tariffs to any prospective vendor or developer and ask them to model the calculation on a whiteboard before you sign. If proration, fee and tax ordering, and mid-cycle class changes do not come up unprompted, they have not billed a utility.

What goes wrong with customer information system data conversion?

Utilities plan conversion as a workstream and then find it is the critical path. The reason is that the hard objects are not customers and balances, which convert fine. They are the ones carrying state.

Deposits with interest accrued under state rules. Budget or levelised billing plans caught mid cycle with an accumulated variance that has to survive the move. Payment arrangements with remaining instalments and a promise date. Service orders in flight. Consumption history that estimation routines and high bill investigations depend on. Collection status, bankruptcy flags and lien history, where getting it wrong has legal consequences rather than accounting ones.

These fail silently. A budget billing plan that resets to zero variance looks perfectly healthy in the new system, and the customer finds out at the annual settle-up when the catch-up amount is wrong. Inspection does not reveal it. Only reconciliation does.

Plan at least three full mock conversions, each ending with the sum of converted balances tied to the legacy trial balance to the cent, plus a manually recalculated sample of the ugliest accounts you have in both systems. Pick those accounts deliberately: a net metered customer on budget billing with a deposit and an active arrangement is worth twenty ordinary ones. Utilities that rehearse once go live and spend the following year finding accounts whose plans quietly reset.

Why do payment, meter data and ledger integrations break after launch?

Three integrations cause most post-launch pain, and they break for different reasons.

Payments break on exceptions rather than on the happy path. Lockbox files with a customer number that no longer exists after a premise consolidation, a kiosk posting twice, a payment received against an account that closed yesterday, a chargeback arriving three weeks later. If the posting logic has no explicit path for unidentified cash, it either rejects the whole file or dumps money into a suspense account nobody reconciles.

Meter data breaks on volume and on gaps. Interval reads from an advanced metering infrastructure head end arrive late, arrive twice, or do not arrive at all for a subset of meters, and the estimation and validation rules that decide what to bill are usually the least tested code in the system. A missing day silently becomes an estimate, and the customer sees it as a spike next month.

The general ledger breaks on distribution. Multi commodity utilities distribute revenue to separate funds, and the mapping from a billing determinant to an account is the thing auditors ask about. A change to a fee calculation that nobody told finance about shows up as an unexplained variance a quarter later.

The prevention is unglamorous: an exception queue with a named owner for each of the three, a daily reconciliation report that ties billed revenue to posted revenue, and automated tests built from real files rather than clean samples.

What happens when disconnection rules are coded as a report?

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

Each of those is a rule with a date and a source, and it usually lives in the billing supervisor's head and in a binder of commission orders rather than in the requirements document. This is the most under specified area in customer information system replacement projects we see, and the consequence of getting one wrong is not a billing error. It is a household without water and a story with your name on it.

Make each protection a first class rule object with an effective date, a source citation and a test. Then generate the disconnect candidate list deterministically, so any account on it can be explained by a rendered chain of rules rather than by someone interpreting a query. When a council member calls about a specific address, the answer takes a minute. Just as importantly, when a moratorium date changes, one rule changes rather than four reports.

Should you build custom or configure what you already own?

Below roughly 80,000 customers, buy the package and build only around it. We say that knowing it costs us revenue. Customer records, accounts receivable, cash posting, service orders and collections are the same at every utility, a package does them well, and paying to rebuild them is capital spent reaching parity.

NISC iVUE is genuinely strong for electric cooperatives and its fit with the wider cooperative ecosystem is real. Harris Advanced Utility Systems and SEDC know the mid market and cooperative space deeply. Oracle Utilities Customer Care and Billing is the right depth for large investor owned utilities that have the implementation budget to match, and the caution there is proportion rather than capability. SAP S/4HANA Utilities makes sense if you already run SAP and finance integration is the priority. Gentrack is strongest where markets are deregulated and water billing is complex.

What none of them does cheaply is express a tariff your council wrote last month. So configure the package for the ledger machinery, and build the rating and determinant service plus the customer facing layer, which is consistently the weakest module in every suite. Build the whole thing only when you bill several commodities on one statement under locally set ordinances and no product has priced your tariffs without a services contract.

How do hidden costs get into the quote?

Conversion is the first and largest. A proposal that lists data migration as a line item without naming the number of mock conversions and the reconciliation standard is hiding the biggest number in the project. Insist on three rehearsals with a tie to the cent, and expect conversion to be a quarter of a full replacement budget.

Parallel billing is the second. Running two full billing cycles where both systems produce statements and every difference is explained account by account is not optional, and it consumes your billing team at exactly the moment they are also learning a new system. Budget the overtime.

After that: each additional commodity on one statement, because each brings its own rate structures and its own fund distribution; net metering and distributed generation, since export credits with carry forward and an annual true up are a separate calculation problem; prepay programmes, which change the billing cadence entirely; and the rules that exist only as institutional knowledge, which surface during the first mock conversion and are always more numerous than anyone predicted.

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

Ask how the team would re-rate 40,000 accounts for a period that already invoiced. The answer you want involves versioned rule sets, a replay path and a per-account delta report. The answer that tells you to walk away is 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. What matters is whether they immediately reach for rule objects with effective dates rather than filters in a report.

Insist on a regression suite built from real accounts, not synthetic ones. A rating engine is only as trustworthy as the set of ugly bills it reproduces exactly, and that suite is what lets your own team change a tariff in a week rather than raising a vendor change request.

Settle ownership before kickoff, in writing, including the repository, the schemas and the rule definitions. Then do one thing this week that costs nothing: take the last three rate ordinances your council passed and time how long each took to appear correctly on a bill. If the answer is measured in months, you now know exactly where the money should go first.