Replacing a utility customer information and billing system

Reference article · 5 min read

A customer information system, or CIS, holds far more than bills. It carries customer and premise records, the meters attached to them, the rate assigned to each service, the calculation that turns a read into a charge, the receivable that results, the collection steps when that receivable ages, and the payment channels that clear it. Replacing one touches the meter shop, the call center, field crews, and finance.

Most replacement projects begin with a specific blocker: the current system cannot support a tiered conservation rate, cannot move from bimonthly to monthly billing, cannot consume interval data from a new AMI deployment, or cannot bill a new stormwater fee. The blocker is real, but scoping around it alone is how a utility ends up with a system that prices water correctly and cannot produce a defensible shutoff notice. Scope the whole chain, from the read to the general ledger entry.

Document the rate structures before writing requirements

Pull every current ordinance, resolution, and rate schedule, plus anything the governing body has signaled it wants next. For each, write out the arithmetic the way a biller would perform it by hand, then test requirements against that arithmetic rather than against a feature checklist. Structures that routinely strain a CIS:

• Tiers and thresholds. Whether tiers reset each cycle, prorate for short or long cycles, and vary by customer class or meter size.
• Derived charges. Sewer billed on winter average water use, stormwater billed on impervious area, fire line charges, irrigation-only accounts.
• Pass-throughs and adjusters. Fuel or purchased power adjustments, surcharges, franchise fees, and utility taxes, each with its own rounding rule and bill line.
• Special programs. Budget or levelized billing, senior and income-qualified discounts where local authority permits them, and net metering or other distributed generation credits.
• Effective dating. Rates need effective dates, and the system must re-bill retroactively when a rate is applied late or corrected.

Trace the path from meter to bill

The metering program and the CIS are separate systems with a contract between them. Decide explicitly what a meter data management system does and what the CIS does, and require the interface to be documented rather than discovered during testing. Specify:

• Read import with validation, estimation, and editing rules your staff can see and adjust.
• Meter exchanges mid-cycle, register rollover, multipliers, and compound or multi-register meters.
• Remote disconnect and reconnect where meters support it, including who may issue the command and what the audit record keeps.
• Alarms that create work rather than noise: leak, tamper, no read, and zero consumption at an occupied premise.

Settle cycles, prorations, adjustments, and estimates

These are the areas where a new system most often produces different results from the old one, and where customers notice.

• Cycle calendar. Route and cycle structure, bill window, due date calculation, and what happens when a run slips.
• Prorations. Move-ins, move-outs, transfers, and mid-cycle rate changes. Choose the method and require the vendor to implement yours, not their default.
• Estimates and true-up. How an estimate is flagged on the bill and how the correction appears once an actual read arrives.
• Adjustments. Reason codes, approval thresholds by dollar amount and role, leak adjustment policy, and reporting finance can reconcile. Keep cancel and re-bill, a full reversal, distinct from a credit adjustment.

Delinquency and customer protections

Collection functions carry legal exposure, so they deserve as much requirements attention as rating. Notice content and timing, shutoff restrictions, deposit rules, weather and medical protections, and a utility's lien authority are set by a mix of state law, local ordinance, and in some cases regulatory orders, and they change. Confirm current rules with your counsel and build the workflow to match rather than accepting a vendor's default configuration.

Capabilities to specify: aging and late fee calculation, notice generation with proof of notice retained on the account, field order creation and result posting, deposits and any required deposit interest, payment arrangements with automatic default handling, third-party pledges from assistance agencies, bankruptcy and dispute holds, write-off, and collection referral.

Payments, the portal, and the return trip to finance

A CIS replacement is also a payments project. Specify the channels you actually operate: web portal, IVR, autopay, in-person cashiering, lockbox, kiosk, and third-party walk-in networks. For each, require the posting file format, the timing, exception handling for returned items, and the reconciliation report.

Card acceptance brings PCI DSS scope, so ask where cardholder data lands and whether tokenization keeps the CIS out of it. Convenience fee and surcharge practices are constrained by card network rules and by law in some states, so verify before assuming. On the back end, require a daily deposit and revenue file the finance system can consume without manual keying, plus reporting for unbilled revenue, refunds, and balances that may fall under state unclaimed property rules.

What to ask vendors, and what to put in the contract

1. Bill a sample of your own accounts, including the messiest, during the demonstration using your rate schedules.
2. Name the meter data systems and payment processors already interfaced, and state what those interfaces do not cover.
3. Describe the conversion approach for balances, deposits, arrangements, and notes, and say how many cycles of billing history convert.
4. Commit to parallel billing across multiple cycles with a documented variance threshold before cutover.

In the contract, tie payment milestones to accepted parallel bill runs rather than to installation. Require data export in a documented format during the agreement and at termination. Fix pricing for interfaces and environments, and require that routine rate table updates be configurable by your staff instead of billable change orders.

HQT works with state and local agencies on systems engineering and software projects, including requirements definition and integration for utility billing and customer information systems.

Frequently asked questions