Non Revenue Water Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the zone boundary assumption break these projects so often?

A non revenue water platform computes almost everything from one premise: that water entering a district metered area is measured, and that the only ways out are through customer connections inside it. If a closed valve is open, or a boundary was never tested, that premise fails silently. The dashboard still renders. The numbers are still confident. They are simply describing a zone that does not exist.

This gets missed because zone boundaries live in GIS, and GIS is authoritative about geometry rather than about valve position. The map was drawn when the zones were designed, then a main break in 2019 required a valve to be opened and it was never closed again, and nobody updated anything because no system depended on it. The moment you build software that does depend on it, a five year old field decision becomes a data quality problem in a capital plan.

The fix is to treat zone validation as scoped project work, not as a prerequisite you assume is complete. Pick three or four problem zones, run a proper closure test on each, and only then compute. If the balance cannot be explained for four zones, adding twenty more will not help, it will only make the error harder to find. Write the validation into the statement of work with named zones and a named utility staff member responsible, because it needs field crews rather than developers.

What goes wrong when billing data is joined to zone flow?

This is the join that separates people who have done water work from people who have built dashboards. Zone flow arrives every fifteen minutes. Billing arrives monthly or bimonthly on staggered read cycles, aggregated by account, and the accounts do not map cleanly onto the zone boundaries because nobody drew the zones to match the billing routes.

Get the time allocation wrong and the balance swings for reasons that have nothing to do with water. A zone whose reads happen in the first week of the month will look different from one read in the last week, purely because consumption is being attributed to the wrong period. Utilities then chase a phantom loss increase that is an artefact of a read schedule.

An AMI rollout makes it harder before it makes it easier. A system mid-migration has two consumption data models running side by side, manual reads on one set of accounts and interval data on another, and reconciling them is real work that gets omitted from estimates constantly. The right approach is to allocate billed consumption to the zone and to the period using the read dates you actually have, hold the account-to-zone assignment as a maintained spatial relationship rather than a one-off export, and show the allocation method on the report so an engineer can see how a number was produced. Ask the question directly in the sales conversation. A vague answer means the balance will be wrong in a way nobody notices for a year.

Why do historian, billing and AMI integrations break after launch?

Three source systems, three different failure modes. The SCADA historian is usually the most reliable of the three and it fails through tag changes: a meter is replaced, the tag is renamed, and production for one zone quietly stops arriving while the dashboard shows the last good value. The billing system, often an older municipal package, fails through undocumented behaviour, particularly around estimated reads, adjustments and back-billed corrections that arrive months later and change history you already reported on. The AMI head end fails through volume and gaps, because interval data has genuine holes and a balance that silently treats a gap as zero consumption will invent a loss.

The defences are consistent. Alert on absence of data rather than only on values, since silence is the dangerous state in all three. Keep source data in a raw store before transformation so a retrospective billing adjustment can be reprocessed rather than argued about. Version the computed balance so last month's published number is reproducible even after the underlying data changes, which it will. And handle estimated reads explicitly as their own category, because treating an estimate as a measurement is one of the quieter ways an audit's validity score gets undermined.

What happens when the audit and reporting obligation is not covered?

Plenty of these builds produce beautiful internal analytics and then fail to produce the one document the utility is legally required to file. The AWWA M36 method and the water balance it defines are the framework regulators and funders expect, separating apparent losses, meaning meter inaccuracy, data handling error and unauthorised consumption, from real losses, meaning physical leakage on mains, services and storage. Some states go further: California's SB 555 obliges urban retail water suppliers to file validated annual water loss audits.

If the system's internal model does not map cleanly onto that structure, someone will still be assembling the submission by hand in February, which was the original problem. And a validity score is not decoration. It is the mechanism by which a reviewer decides how much weight to give your numbers, so a system that cannot evidence where each input came from will produce a submission that scores no better than the spreadsheet it replaced.

Build to the reporting structure from the first sprint rather than mapping onto it later. Every input should carry its source, its method and its confidence, so the submission is a report you run. Confirm your own state's format with the regulator rather than assuming the national method is sufficient, and make unbilled authorised uses such as hydrant permits, main flushing and firefighting draw loggable with a volume estimate at the moment they happen, because reconstructing them at year end is exactly where validity is lost.

Should you build custom or configure what you already own?

Two groups of readers should not commission a build. If you serve a small system, your audit validity scores are already reasonable, and your losses are within a range you can live with, the free AWWA audit workbook plus an acoustic survey contract every couple of years is a rational programme, and software would be an expensive way to formalise a number you already trust.

The second group should buy detection rather than build it. TaKaDu detects network events from SCADA, Asterra returns satellite-derived leak polygons, Echologics and Aquarius Spectrum do acoustic detection and correlation, and Xylem Visenti works the pressure and network side. These are specialised products and the vendors are better at them than a custom build would be. You are not building a leak detector.

Configure before you commission, too. Your GIS and asset management platforms hold network geometry, condition and consequence, and most utilities have never joined break history to zone geography in the tools they already pay for. If a week of configuration answers your prioritisation question, take the answer. The build case begins when you need the ledger those detectors report into: a defensible monthly balance by zone that separates real from apparent losses and tells you which detection method actually paid.

How do hidden costs get into the quote?

Five items go missing routinely. Zone validation, discussed above, which is field work rather than development but must be in the plan. Billing system integration with an older municipal package, where undocumented read cycle handling is the schedule risk rather than the technical difficulty. AMI transition work where two consumption models coexist. Meter fleet data assembly, because tracking the meter population as an asset with install date, make, size, cumulative registered volume and test results usually means building that dataset rather than importing it. And the state submission format, which is regulatory work requiring review, not a template.

The honest bands from Digital Heroes delivery experience are $60,000 to $130,000 for a focused first release over 12 to 16 weeks, covering the automated monthly balance by zone, real versus apparent loss separation, minimum night flow analysis and a prioritised survey target list. A full platform adding vendor finding ingestion with payback tracking, meter fleet economics, pressure management analysis and capital prioritisation runs $150,000 to $350,000 over 6 to 12 months. A quote materially under that band has usually assumed your data is cleaner than it is, and that assumption surfaces in month three.

What separates a water loss build that works from one that fails?

The projects that succeed start narrow and close the loop. Three or four zones, one year of history, and one output the distribution superintendent uses every week. The projects that fail try to model the whole system before anyone has confirmed a single zone balance, and they end up with a dashboard nobody defends in a meeting.

The second marker is whether findings and repairs are joined. Satellite polygons, acoustic correlations, crew reports and public complaints should land as one finding object with a source, a location, a confidence and a status, with the field investigation and the repair attached, and the repair carrying an estimated flow rate and duration so recovered volume can be compared against the zone's actual balance change. Without that, you cannot compute cost per verified leak by detection method in your own system, and no vendor will compute it for you. With it, next year's contract decision is arithmetic instead of a sales meeting.

The third is ownership and horizon. Loss reduction programmes are typically funded over five to ten years, which outlasts most software relationships, so the repository, the cloud accounts and the right to bring in another firm should be settled in writing before kickoff, along with an agreed data export format. At Digital Heroes the client owns the code from the first commit. The single best pre-project exercise costs nothing: take your last submitted water audit, sit a developer down with it, and go line by line asking where each number came from. The lines nobody can answer are the project.