WATER SERVICE PROVIDERS · GUIDE 03
Six decisions to settle before entering any data.
A service provider that starts entering customers on the first day usually rebuilds the register within the year. The reason is rarely the software. It is that six decisions were left implicit, and every record entered before they were settled has to be revisited once they are.
This guide follows one chain from the pipe in the ground to the arrears report, names the six decisions that shape it, and states what each decision costs to change later. It is the operating half of the series. Guide 02 covers choosing a system, and this guide covers designing the records that system will hold.
Everything a provider does commercially runs along a single chain. Each link is a record, and each arrow is a relationship the system has to hold.
A break anywhere in the chain shows up at the end as a number nobody trusts. The six decisions below each protect one or more links.
The asset register is the foundation, and its scope is the first decision. A provider can record the network at the level of the source, the scheme, the pipe section, or the individual connection. Each level supports different questions.
Recording at connection level is what makes the commercial chain possible, because a customer account has something physical to attach to. Recording at pipe section level is what makes maintenance planning possible, because failures can be ranked. Most providers need both, and the practical order is connections first, network second, since connections unlock billing.
Sanitation providers face the same decision with different assets. Containment, emptying points, transfer stations, and treatment sites take the place of connections and mains. Recording containment consistently is what allows a provider to report on a whole service area rather than on the customers it currently serves.
Cost of changing later: moderate. Adding detail to an asset register is normal. Changing the level at which assets are identified means re-surveying.
The most common structural error is treating the customer and the connection as one record. They have different lifespans. A connection outlives its customers. A customer may hold several connections. A property changes tenants while the meter stays.
Three records solve this cleanly. The customer is the party. The connection is the infrastructure. The customer account is the relationship between them, and it is the account that carries the balance, the tariff, and the readings. When a tenant changes, the provider closes one account and opens another against the same connection, and the connection keeps its full history.
This separation is also what makes register completeness measurable. Connections with no active account are supplied and unbilled, and that comparison is only possible when the two are distinct records.
Cost of changing later: high. Splitting a merged customer and connection record after two years of billing means reconstructing which balance belonged to which occupant.
Every provider needs an accounting structure behind the customer records, even if it never produces a financial statement, because a customer balance is an accounting entry. The question is how much structure.
The five account types are the same either way: assets, liabilities, equity, revenue, and expenses. What differs is how finely each is divided. A provider that expects to be audited within three years should start with the standard structure, because migrating transaction history between charts of accounts is slow and error-prone.
One account is mandatory regardless of size. The accounts receivable account is what records money customers owe for water already supplied, and without it there is no arrears figure.
Cost of changing later: high. Transactions are posted against accounts, so restructuring the chart means restating history.
Tariffs are where a system either matches the provider's legal reality or forces the provider to approximate it. Before configuration, take the current tariff order and identify four things: the customer categories, the fixed charges, the volumetric rates, and the consumption bands.
Dates on tariffs are the detail providers skip and later regret. A tariff that was simply overwritten when rates changed makes every historical bill unreproducible, which is the first thing an auditor or a disputing customer asks for.
Keep the billing day the same across all tariffs. Bills generated on different days for different customer categories cannot be reconciled against a single monthly production figure, which breaks the non-revenue water calculation described in Guide 04.
Cost of changing later: low if dates were used from the start, high if they were not.
Permissions look like an administrative detail and behave like a design decision, because they determine whether staff can do their jobs without sharing an account. Shared accounts destroy the audit trail, and the audit trail is what resolves disputes.
Map permissions to real jobs rather than to seniority. A working set for most providers separates reading meters, recording charges, recording payments, managing customers, viewing accounting, and managing transactions. A meter reader needs the first and nothing else. A cashier needs to record payments but not to alter customers. A manager needs to view accounting without necessarily posting transactions.
Where staff work in defined areas, restrict them to their meter reading routes. A reader who sees only their own route works faster, and a reading entered against a customer on another route becomes impossible rather than merely unlikely.
Assign administration to roles and teams rather than to named individuals, so access survives staff turnover. A provider whose only administrator has left is a provider without a system.
Cost of changing later: low. Permissions are the one decision on this list that is cheap to revise.
Commercial records and operational records are usually designed by different people at different times, and the join between them is left out. It should not be, because the fault record is what connects a broken asset to the customers who stop paying for a service they are not receiving.
A workable fault workflow has five steps, each attributed to a role. Report, review, assign, repair, verify. The record stays open until an authorized person verifies the outcome, which prevents the common failure where a repair is completed in the field and the report stays open for months.
Attach the fault to the asset, not to a free-text location. A fault attached to an asset builds a failure history. A fault described as "near the market" builds nothing, and the provider loses the ability to rank assets by how often they fail.
Cost of changing later: moderate. The workflow can be redesigned, but historical faults attached to text rather than assets cannot be recovered into a failure history.
Write down six things before entering any data. This is the document to hand an implementation partner, and the one to check the system against after three months.
Three of these six are expensive to change once billing has run for a year. Settling them takes a morning.
mWater holds all six of these decisions as configuration rather than custom development. A provider can choose a simplified or standard chart of accounts, build fixed, volumetric, and tiered tariffs with effective dates, link customer accounts to connections in the asset register, restrict staff to meter reading routes, and run a fault workflow against assets.
This guide covers the records. The others cover the category, the decision, lost revenue, and the first month of operation.
mWater · Water service provider series