Non Revenue Water Software: How to Prove Where the Treated Water Actually Went

Why non revenue water is an accounting problem before it is a leak problem

A distribution superintendent knows the number. Somewhere around a fifth of what the plant produces never turns into a bill. He also knows what happens next: someone asks whether that is leaks or meters, and the honest answer is that nobody can say with confidence, because the annual water audit was assembled in a spreadsheet by a consultant in February using production totals from one system, billed consumption from another with a different read cycle, and estimates for everything in between. The audit has a validity score attached that politely says most of the inputs are guesses. That document then justifies, or fails to justify, a capital programme worth millions.

The vendor landscape is genuinely good at pieces of this. TaKaDu detects network events from SCADA. Asterra flies satellite analysis over your service area and returns likely leak polygons. Echologics and Aquarius Spectrum do acoustic detection and correlation. Xylem Visenti works the pressure and network side. Every one of them will hand you findings. What none of them owns is the balance: the ledger that says of the volume produced last month, this much was billed, this much was authorised but unbilled, this much was lost to meter under-registration, and this much actually left through a pipe. Without that ledger, every vendor finding is an anecdote and every capital request is a lobbying exercise.

The framework already exists and you should use it. The AWWA M36 method and the water balance it defines separate apparent losses, which are meter inaccuracy, data handling error and unauthorised consumption, from real losses, which are physical leakage on mains, services and storage. Some states require it: California's SB 555 obliges urban retail water suppliers to file validated annual water loss audits. The problem is not the framework. The problem is that most utilities compute it once a year, by hand, from data they cannot easily reconcile, so the framework never becomes an operating tool.

Problem 1: the water balance is an annual event, so it never drives a decision

An annual audit tells you the size of the problem twelve months after you could have acted on it. Worse, an annual number cannot separate a burst that ran for six weeks in October from a slow structural drift in meter accuracy, because both show up as one figure in the same box.

The AWWA free workbook is a fine instrument and it was never meant to be an operations system. It takes inputs you type. It has no connection to your SCADA historian, your billing system, or your work orders, which is why the validity scores on most submitted audits are low in exactly the places that matter.

What a custom build does: compute the balance monthly, by zone, from source data rather than typed inputs. Production comes from the historian. Billed consumption comes from the billing system with the read cycle offsets handled properly, which is the single most common source of nonsense in hand-built audits. Unbilled authorised consumption stops being a guess when hydrant permits, main flushing and firefighting draw are logged against a volume estimate at the time they happen rather than reconstructed in February. Then the annual submission is a report you run, and the validity scores climb because the inputs stopped being estimates.

Problem 2: district metered area data and billing data do not live in the same time or space

DMA flow arrives every fifteen minutes. Billing arrives monthly or bimonthly on staggered cycles, aggregated by account, and the accounts do not map cleanly onto the DMA boundaries because nobody drew the zones to match the billing routes. So the comparison everyone wants, what went into this zone versus what was billed in it, requires a spatial join and a time reallocation that a spreadsheet cannot do.

This is why minimum night flow analysis is so widely recommended and so rarely used properly. The technique is sound: in a zone with mostly residential demand, the flow at three in the morning is close to the leakage rate plus a small legitimate night use allowance. Doing it well requires clean zone boundaries, reliable zone metering, an estimate of legitimate night use based on your own customer mix, and someone watching the trend rather than a single night.

What a custom build does: hold the zone as a real geographic object with the accounts inside it, allocate billed consumption to the zone and to time using the read dates you actually have, and compute minimum night flow with a legitimate use allowance derived from your own low-consumption accounts rather than a textbook figure. Then a zone-level loss trend exists, and it moves when a burst starts. That trend is what turns a survey crew from a rota into a targeted resource.

Problem 3: apparent losses are invisible because your meters lie quietly

Real losses make noise and eventually surface in the street. Apparent losses do not. An aging positive displacement meter under-registers low flows first, so it keeps recording something plausible while missing an increasing share of actual use. Multiply a small under-registration by 40,000 meters and it becomes one of your largest single loss components, and it looks exactly like nothing on any dashboard.

The leak detection vendors have no view of this at all, by design. The billing system does not either, because from its perspective the meter reported a number and the number was billed. Utilities discover the scale of it during a meter replacement programme when consumption jumps and customers complain about bills that were previously too low.

What a custom build does: track the meter fleet as an asset population with install date, make, size, cumulative registered volume, and test results. Then flag accounts whose consumption pattern has drifted downward in a way inconsistent with the neighbourhood, which is the signature of under-registration rather than conservation. Test sampling gets planned by cohort so the results are statistically usable rather than opportunistic. The replacement case then gets built on the recovered revenue per meter class, which is an argument a finance director will accept, instead of on an age threshold, which is an argument they will not.

Problem 4: vendor findings arrive in five formats and die in a folder

Satellite analysis returns polygons. Acoustic loggers return correlations with coordinates and confidence values. Correlator crews return a form. A resident reports water in the street. Each arrives in its own format, on its own schedule, to a different person, and the loop between a finding and a repair and a confirmed volume recovered is almost never closed. So next year you cannot say which detection method actually paid, and you re-buy on the basis of the sales meeting.

What a custom build does: one finding object with a source, a location, a confidence and a status, fed by whatever the vendors send. Field investigation results attach to it. If a leak is found and repaired, the repair record carries an estimated flow rate and duration, so the recovered volume is estimated and compared against the zone's actual balance change. Over a year you get the answer that matters: cost per verified leak and per recovered volume, by detection method, in your system. That number decides next year's contract, and no vendor will ever compute it for you.

Problem 5: prioritising mains work needs economics, not leak counts

The pipe with the most breaks is not automatically the pipe to replace. The right target is the pipe where the annual cost of leakage plus break repair plus service disruption exceeds the annualised cost of replacement, adjusted for criticality and for whatever the street is going to cost you in restoration.

Asset management platforms model condition and consequence, and they generally do it without any live connection to your loss data. Meanwhile pressure management, which is often the cheapest real intervention available, needs zone-level analysis of pressure against leakage response and hardly ever gets modelled at all.

What a custom build does: bring break history, zone loss trend, pressure data and replacement cost into one prioritisation that produces a ranked list with the reasoning shown per segment. When a council member asks why 4th Street is ahead of their street, the answer is a page, not a defence. Pressure reduction candidates get identified where the zone's night flow responds strongly to pressure, which is a cheap win most systems have several of and nobody has looked for.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A focused first release covering an automated monthly water balance by zone from source systems, real versus apparent loss separation, minimum night flow analysis, and a prioritised survey target list runs $60,000 to $130,000 and ships in 12 to 16 weeks. A full platform adding vendor finding ingestion and payback tracking, meter fleet testing economics, pressure management analysis, capital prioritisation and the state audit submission runs $150,000 to $350,000 phased over 6 to 12 months.

What pushes cost up: the state of your zone metering, because a build cannot compute a balance for zones that are not properly metered or whose boundaries are not actually closed, and discovering that is common. Billing system integration, especially with older municipal systems where read cycle handling is undocumented. The number of separate pressure zones and any interconnections with neighbouring systems. And AMI rollout timing, since a system mid-migration between manual reads and AMI has two consumption data models to reconcile for a couple of years.

What keeps cost down: start with your three or four worst zones and one year of history. If the build cannot explain those zones, adding twenty more will not help.

Build versus buy, and when buying is right

Buy, or stay manual, if you serve a small system, your audit validity scores are already decent, and your losses are within a range you can live with. An acoustic survey contract every couple of years plus the AWWA workbook is a rational programme and a build would be an expensive way to formalise a number you already trust.

Also buy the detection technology rather than building it. Satellite, acoustic and correlation work are specialised and the vendors are good at them. You are not building a leak detector. You are building the ledger the detectors report into.

Build when two or more of these are true. You serve above roughly 30,000 connections. Your annual audit is prepared by an outside consultant and nobody internally can defend its inputs. You have district metering that produces data nobody analyses systematically. You are spending real money on detection contracts without any measurement of what they returned. Or you are entering a funded multi-year loss reduction programme where the reporting obligation alone will consume a staff position.

Our position: loss reduction programmes fail on measurement, not on technology. A utility that can compute a defensible monthly balance by zone will find leaks with almost any detection method, and a utility that cannot will buy detection forever without moving the annual number.

How to choose a developer for non revenue water software

Ask them how they will allocate billed consumption to a zone and to a month when read cycles are staggered and do not align with zone boundaries. This is the question that separates people who have done water work from people who have built dashboards. A vague answer means the balance will be wrong in a way nobody notices for a year.

Ask how they will represent legitimate night use, and whether they intend to derive it from your own low-consumption accounts or take a figure from a manual. The second answer is a shortcut you will pay for in false alarms.

Ask what they have integrated. A SCADA historian, a municipal billing system and an AMI head end are three different problems, and the billing system is usually the one that takes the longest.

Ask how vendor findings and repair outcomes get linked, and whether they will compute cost per recovered volume by detection method. If that is not in the plan, you are buying a dashboard rather than a decision tool.

Ask who owns the code and the infrastructure before kickoff, in writing. At Digital Heroes the client owns the code from the first commit.

The right first move is to 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.