A water utility's revenue depends on a chain that usually spans three disconnected systems: what was distributed, what was metered, and what was billed. Where those are reconciled by hand, the gap between water supplied and revenue collected is discovered late and is difficult to attribute. Connecting them makes losses visible by area and by period rather than as a single unexplained figure at year end.
Where it usually breaks.
Readings that arrive too late to bill on
Meter readings collected on paper and entered days later, so billing runs on estimates and the correction arrives as a customer dispute rather than an invoice.
Distribution and revenue in separate ledgers
Volume distributed sits in one system and revenue in another, so non-revenue water is a number somebody calculates annually rather than a figure anyone can act on.
Collections without a customer picture
Payment history, disputes and disconnection status held separately from the account, so the person on the phone cannot see what the customer is actually asking about.
What the system does.
Built on Precedence Core, configured to how this sector actually operates rather than to a generic template.
About Precedence Core- Meter readings captured at the point of reading
- Billing generated from consumption, on a defined cycle
- Customer accounts with full payment and dispute history
- Distribution volume reconciled against billed consumption
- Non-revenue water reported by area and period
- Collections and disconnection status on the account record