WATER SERVICE PROVIDERS · GUIDE 05

A water utility's first thirty days in mWater

Four weeks from an empty account to a billing run that reconciles.

Most utility software pilots fail quietly. Nobody rejects the system. The provider sets it up, enters part of the customer list, and then the reading round slips, the billing run is done in the old spreadsheet because it is faster this month, and six weeks later there are two registers and neither is trusted.

The way through is to produce something the provider can show a manager at the end of every week. This guide sets out four weeks, each ending in a concrete output. It assumes one scheme, one meter reading route, and one person who owns the work. Everything here is configuration, so no development is needed and nothing needs to be purchased.

Before week one

Settle the six record decisions in Guide 03 first. The important ones for the next month are the separation of customer, connection, and account, and which chart of accounts the provider will use. Both are expensive to change once billing has run.

Gather four things: the current customer list in a spreadsheet, the current tariff order, a list of staff who will use the system and what each does, and a source meter reading for the scheme if one exists.

Week 1. Create the system and set the financial structure

The goal this week is a configured system with nobody's data in it yet.

1. Create a free mWater account and an organization for the provider.
2. Create the water system, or open the existing one, and set the organization as its manager.
3. Open Customer Management and run the three-step setup.
4. Choose the chart of accounts. Take the simplified structure for a small scheme, the standard structure where audited statements are expected within three years.
5. Enable the meter reading module. Enable full accounting only if the provider will use payables and financial statements, since it can be switched on later.
6. Set the billing day and the currency code. Use the same billing day the provider already uses, so the first cycle can be compared with the last manual one.

Show at the end of the week: the configured system, the chart of accounts, and the billing day, confirmed against the provider's existing practice.

Week 2. Load customers, connections, and tariffs

This is the week where the work actually is. Expect the customer list to be wrong, because every customer list is.

1. Transcribe the tariff order. Create each tariff with its fixed fees and meter rates, set consumption bands for tiered rates, and set effective dates on all of them.
2. Prepare the customer spreadsheet against the import template. Customer code and account code are required and must be unique. Tariff name, route name, and water asset code are optional but save considerable work later.
3. Import customers. Include opening balances for customers who already owe money, with the balance date, so arrears carry over rather than starting at zero.
4. Create meter reading routes and assign customers to them. Start with one route.
5. Link customer accounts to connections in the asset register wherever the connection is already recorded. Where it is not, note the gap rather than skipping it.

Expect these problems. Duplicate customer codes, two accounts against one meter, customers who moved years ago, and connections in the field with no entry in the list at all. The last group is the most valuable finding of the whole month, because those are connections being supplied and never billed. Record them and open accounts for them.

Show at the end of the week: the customer count imported, the count of duplicates resolved, and the count of unbilled connections discovered.

Week 3. Run one reading round in the field

The system is now worth testing against the conditions it has to survive.

1. Set permissions for the staff who will read meters, and restrict each reader to their route.
2. Install the mWater app on the readers' own phones and confirm each reader sees only their route.
3. Brief the readers. The app lists customers in order of nearness, and records date, previous reading, current reading, calculated volume, and an optional photograph.
4. Run the round with the connection switched off for the whole day, then synchronize at the end.
5. Review the readings. Investigate any reading lower than the one before it, any zero on an occupied connection, and any account with no reading at all.

Photographs of the meter face are worth insisting on in the first round. They settle disputes, and they let a supervisor check readings without returning to the field.

Show at the end of the week: the share of accounts on the route read on time, and the list of readings that needed investigation.

Week 4. Bill, collect, and open the overview

The final week turns the month's work into the figures a manager will use from now on.

1. Let the billing run generate on the billing day. Print one bill and check it against a bill from the previous manual cycle.
2. Add the provider's logo, bill title, and footer text so the printed bill is recognizable to customers.
3. Record payments as they are received. mWater does not move money, so payments recorded here are a note that payment was made through whatever channel the provider uses.
4. Open the customer overview page. It shows total accounts receivable, collection rate, active customer accounts, and meters read in the last thirty days, with a map of connections and outstanding balances by age band.
5. Compare the billing run against the previous cycle. A difference is expected, since unbilled connections were added in week 2. Explain the difference rather than adjusting it away.

Show at the end of the week: the first billing run, the arrears list by age band, and the difference from the previous cycle with the reason for it.

What to do when something goes wrong

Four problems account for most of what goes wrong in a first month, and each has a standard response.

• The import is rejected. Column headers must match the template exactly, in order and in name. Check for a trailing space before checking anything else.
• Bills do not match the old system. Compare one customer line by line. The cause is almost always a tariff band boundary or a missing opening balance, not the billing run.
• Readers cannot see their customers. Confirm the reader is part of the organization that manages the system, and that the route assignment was saved.
• Two accounts appear for one meter. Close the account that has no payment history and carry the balance across, rather than deleting either.

After thirty days

One route billing correctly is a working system. Extending it is repetition rather than new work.

1. Add the remaining routes, one per cycle, so a failure never affects the whole provider.
2. Complete the asset register so every account links to a connection, which makes register completeness measurable.
3. Start the four monthly measures in Guide 04, using the first billing run as the baseline.
4. Turn on the fault workflow so operational work sits alongside the commercial records.

Providers that reach the end of a second clean billing cycle rarely go back. The point at which the system becomes the record rather than a copy of the record is the point at which the pilot has succeeded.

Explore mWater

Everything in this guide is available on a free account, with unlimited users and no license fee. Implementation and support services are paid and optional.

• Create a free account: The mWater platform
• Full reference for every step above: Customer and billing management
• Importing existing records: Importing site data
• Implementation support and training: Work with mWater

Related guides

This guide covers the first month. The others cover the category, the decision, the records, and lost revenue.

• What is a water utility management information system?
• How to choose a water utility management system
• From assets to accounting: the records a water service provider needs
• Non-revenue water: where the water and the money go

mWater · Water service provider series