How to replace a council billing system without billing errors

Councils bill for a wide range of things: commercial waste, trade services, rents and licences, room hire, care charges, recharges to other public bodies. Many of these sit in an ageing billing system that a small number of people understand, often with years of workarounds layered on top.

Replacing that system is rarely the hard part. The hard part is replacing it without sending out a wrong invoice. A single batch of incorrect bills can cost months of goodwill with customers, create a backlog of credit notes and draw attention from members and auditors.

This article sets out the method we use to make the switch safely. None of it is exotic. It is a sequence of disciplined steps, each of which reduces the chance of surprises at go-live.

Start with the pricing rules, not the screens

The first job is discovery, and the most important output of discovery is a complete, written record of how charges are actually calculated.

That means going beyond the tariff schedule. In most organisations, the real pricing logic lives in several places at once:

• The published fees and charges schedule
• Configuration in the current system
• Spreadsheets used to calculate adjustments before data entry
• The knowledge of the officers who run the billing cycle

We document every charge type with its basis (fixed, per unit, per lift, per hour, per period), its proration rules, discounts and exemptions, VAT treatment, rounding behaviour and billing frequency. Where the current system behaves differently from the written policy, we record both and ask the service owner which is correct. Those conversations are far cheaper now than after go-live.

Profile the data before you design anything

Before designing the new configuration, look hard at the data you already hold. Data profiling means running structured checks across customer records, accounts, contracts, open balances and transaction history to understand what is really there.

Typical findings include duplicate customers, accounts with no active service, services with no price, inconsistent address formats and historic charge codes that nobody uses any more. Each finding needs an owner and a decision: cleanse at source, transform during migration, or leave behind.

Profiling also tells you whether the pricing rules you documented are consistent with the history. If the data shows charges that the rules cannot explain, there is a rule you have not yet found.

Design the configuration to match the rules

With the rules and the data understood, design the configuration of the new system. We favour a design where:

• Each customer agreement is represented as a contract with clear start dates, end dates and charge lines
• Prices come from maintained price lists, not values typed onto individual accounts
• Exceptions are explicit and visible, rather than hidden in manual overrides

This is the point to simplify. Charge codes that exist only for historic reasons can often be retired. But every simplification needs sign-off from the service and from finance, because it changes what customers will see on their invoices.

Build the integrations first

Billing systems rarely stand alone. They post to the general ledger, pass debtors to the income management system, receive service data from operational systems and feed payment and recovery processes.

We build and test these integrations early, before the main migration effort, for two reasons. First, integrations are where the most time is lost when left late. Second, you cannot properly rehearse a migration or run a parallel billing cycle without them. A test invoice that never reaches the ledger tells you very little.

Agree interface specifications with each system owner, test with realistic volumes, and confirm how errors are reported and corrected on both sides.

Rehearse the migration, and reconcile every time

Migration should never be a single event. We run several full rehearsals, each one using a fresh extract from the live system and the same scripts that will be used at cutover.

After every rehearsal, we reconcile. That means producing reports that compare the old and new systems on:

• Record counts by type: customers, accounts, contracts, charge lines
• Open balances, in total and by customer
• Contract values and billing schedules
• Any records rejected or transformed, with reasons

Every difference is either explained or fixed. Rehearsals also give you an accurate timing for the cutover window, which matters when billing staff need to know how long the system will be unavailable. This is core business systems work, and it rewards patience.

Run billing in parallel and compare line by line

This is the step that gives the most confidence and is the one most often cut when time is tight. Do not cut it.

We aim to run at least one full billing cycle in both systems before switching over, and to explain every difference. The comparison happens at invoice line level, not just at total level. Totals can match while individual customers are wrong in opposite directions.

Differences usually fall into a few groups: a pricing rule configured incorrectly, a data issue carried over from migration, a deliberate change the service agreed to, or an error in the old system that is now corrected. The last group needs particular care. If the new system is right and the old one was wrong, the service needs to decide how and when to tell affected customers.

Cut over at a period boundary

Choose a cutover point that aligns with a billing period end and, ideally, a financial period end. This keeps the old system responsible for everything up to a clear line, and the new system for everything after it.

Plan the cutover as a rehearsed runbook: final extract, migration, reconciliation, integration checks, sign-off, and only then switching on. Agree in advance who makes the go or no-go decision and on what evidence. Keep the old system available read-only for queries and audit.

Plan for hypercare

The first few billing cycles after go-live deserve extra attention. During hypercare, we keep the delivery team close to the billing and finance teams, review each billing run before invoices are released, monitor integration queues daily and track every query from customers.

Hypercare ends when the service is confident running cycles independently, the support model is in place and open issues are closed or formally handed over, not on a fixed date chosen at the start of the project.

Talk to us

If your council is planning to replace a billing system, our contract management, billing and invoicing solution page explains how we approach it. To find out more about how we deliver for public bodies, see our public sector page or get in touch.