A district metered area is a hydraulically isolated zone of a water network, commonly 500 to 3,000 connections, with every inlet and outlet metered. Meter the boundary and you can account for the water crossing it. That is the whole idea, and it predates every piece of software sold to support it.
The method that does the work is night flow analysis. Between roughly 02:00 and 04:00 legitimate demand falls to its floor, so whatever is still flowing into the district is mostly leakage. Track the minimum night flow against the district's own baseline and a new burst shows up as a step change within a day or two.
Every product in this market implements that same calculation. What separates them is everything around it.
Three ways utilities actually do this
SCADA plus a spreadsheet
Flow meters report to SCADA, someone exports the night window monthly, and the numbers go into a workbook with last year's figures alongside. This is more common than vendors admit, and for a utility with a dozen districts it is not indefensible.
It fails on latency and on memory. A burst that starts on the 3rd is found on the 30th, which is 27 days of water. And the institutional knowledge of what each district's normal looks like lives with whoever maintains the workbook.
A commercial non revenue water platform
Buy a platform and you buy the calculation, an alerting engine, a hosted store for the meter history and, usually, an implementation team. For a utility with no analytics capability and a board that wants a number next quarter, that is a real answer.
The trade is that the district logic, the baselines and the alarm thresholds live inside a product you license. When the contract is up for renewal, so is your loss reporting. For a utility working under a funded programme with a fixed end date, that is a question worth asking in procurement rather than at handover.
Analytics built on your own data
The third option is a timeseries store for the meter history, the night flow calculation written down as code, and a hydraulic model of the network in EPANET or an equivalent to turn a flagged district into a shortlist of candidate mains.
This is more work upfront and it is the only one of the three that leaves you owning the result. We have written separately on choosing the timeseries database underneath, which is the decision that usually determines whether this approach stays affordable at scale.
What none of them do
Night flow analysis identifies the district. It does not locate the pipe. Pinpointing is still acoustic loggers, correlators and a crew, and no analytics platform removes that step. A vendor demonstration that moves straight from a dashboard alert to a repaired main has skipped the expensive part.
Nor does any of this separate real losses from apparent losses. Under the IWA water balance, meter under registration and billing errors sit in the same non revenue water total as physical leakage, and they are fixed by different departments with different budgets. A platform reporting a single percentage is reporting the sum of two unrelated problems.
How to choose
Three questions settle it more reliably than a feature matrix.
- How many districts, and how often do the boundaries change? Under about twenty stable districts, disciplined use of what you already have goes a long way. Above that, or with boundaries that move as the network is rezoned, manual handling stops scaling.
- Are your meters trustworthy? Night flow analysis on uncalibrated boundary meters produces confident nonsense. Meter verification is the prerequisite, not the follow up, and it is where the first months of any honest programme go.
- Who holds the result in five years? If the work is donor funded and hands over to a municipal counterpart, a licensed platform transfers a subscription. Code and a documented method transfer the capability.
That last question is the one we are usually brought in on, and it is why we build these as decision support systems rather than selling a dashboard.
