How to Choose a Water Meter Data Management Platform

Choosing a water meter data management platform is not only a software decision. The platform determines how reliably meter readings are collected, how data reaches billing systems, how quickly abnormal consumption is identified, and whether existing meters can remain part of the metering infrastructure.

For utilities and submetering companies, the best evaluation starts with the meter estate and data requirements, not the dashboard. This guide explains how to define the scope, test compatibility, evaluate billing and analytics, and run a pilot before committing to a platform.

Key Takeaways

• Start with the meters, communication technologies, billing systems, and data requirements already in use. A platform should be able to support the infrastructure you intend to keep or have integrations via API.
• Legacy meters can often stay in service. Pulse converters place existing mechanical meters on the same data path, so confirm what a platform supports before assuming replacement.
• Understand whether you need meter data management (MDM), Head-End System (HES) functions, or both. The required software layer affects the shortlist and integration scope.
• Test the full data path. Reliable ingestion matters, but the platform should also handle missing readings, meter replacements, billing exports, alerts, permissions, and historical data.
• Treat leak detection and water loss analytics as separate capabilities. Some events can originate in meters, while other anomalies and balancing calculations are produced in software.
• Test meter data management platform in the real project together with meters and communication.

Evaluation area	What to confirm	Practical test
Meter compatibility	Supported meter models, payload formats, interfaces, and communication technologies	Provide sample data from legacy and current meters
Data completeness	Expected readings arrive and missing or late data is visible	Compare expected intervals with received intervals
Billing integration	Data can reach the existing billing or ERP system in the required format	Process one complete billing cycle
Alerts and analytics	The platform clearly identifies which events come from devices and which it calculates	Trigger or simulate selected alert conditions
Water balance	Master meter and downstream consumption can be compared by a defined area	Build one sample zone and review the resulting discrepancy
Security and access	Hosting, access control, security assurance, data location, and audit practices are documented	Review security documentation and user permissions
Data ownership	Historical data can be exported in a usable format	Request an export of pilot data

What is a water meter data management platform?

A water meter data management platform collects, validates, stores, and prepares consumption data for use in billing, reporting, alerts, and analysis. A Head-End System (HES) sits closer to the field devices and handles functions such as device communication, provisioning, configuration, and command exchange.

Some products provide these functions separately, while others combine them. Mainlink, for example, describes its smart metering platform as a combined MDM and HES environment that collects, validates, analyzes, and exports meter data while supporting multiple meter brands and communication technologies. Its published materials list LoRaWAN, NB-IoT, Sigfox, and Wireless M-Bus and describe an AWS hosted environment built to process several billion meter readings per day.

This distinction matters because a utility that already has the communication and device management layer may need a different platform scope from an organization replacing its full smart metering infrastructure. Smart metering typically integrates meters, communication networks, data management software, and user interfaces into a single connected system.

Before requesting demonstrations, prepare an inventory of meter manufacturers, models, interfaces, firmware versions, communication technologies, expected reading frequency, billing interfaces, and applicable regulatory requirements.

How should you test meter and data compatibility?

Start with representative field data, not only new devices in a controlled demonstration.

Ask each vendor to process sample payloads from legacy and current meter models. Check whether meter identifiers, timestamps, units, register values, status information, and relevant events are decoded correctly. Also ask how the system handles duplicated, delayed, and missing readings.

Ask specifically about meters that will not be replaced. Pulse converters can bring installed mechanical meters onto the same platform without changing the meter base, which is often the difference between a phased rollout and a full replacement program.

Keep communication performance as a separate test. A meter installed in a basement or remote chamber may create a network coverage challenge, while payload processing is a software compatibility question. External antennas are designed for meters in pits and obstructed spaces, so a coverage failure is not always due to a platform limitation.

For mixed estates, documented support is more useful than a broad claim that a platform works with any vendor. The vendor should be able to identify which meter models and data formats are already supported and explain the process for adding another device.

How do you test billing integration?

A platform is useful only if validated consumption can move into the systems that need it.

Take a real district, property, or customer group and process one complete billing cycle. The test should use the actual billing or ERP interface where possible, whether that is an API, scheduled file transfer, or another supported method.

Meter replacements deserve a separate test. Replace a meter during the sample billing period and confirm how the system links the old and new devices, records the final register, and prevents the new register value from being interpreted as a consumption error.

The expected result is not a visually correct dashboard. It is consumption data that the billing team can accept without recurring manual correction.

How should alerts and leak detection be evaluated?

Do not assume that every leak or device alert is created in the same layer.

Some meters can generate events based on locally configured thresholds, while platforms can also calculate alerts from consumption patterns, communication status, or data received from several devices. Mainlink’s utility AMI solution combines configurable alert thresholds on the meter with leak detection, network and device health monitoring, consumption analytics, and water loss tools calculated in the platform.

During the evaluation, create a list of all alerts that matter to operations. For each one, identify where it originates, what data it uses, whether the threshold can be changed, and who receives the notification.

The pilot should run long enough to include normal reading patterns, a full billing cycle, missing data conditions, and actual operational events. At Mission Terrace, a deployment delivered by Meternet using Mainlink’s system detected six water leaks within the first two months after 404 ultrasonic meters were installed across 202 apartments. That case shows why an evaluation should include real operating conditions, not only a short software demonstration.

How should you weight the evaluation criteria?

The importance of each criterion depends on the application, existing infrastructure, and operational priorities. Rather than giving every requirement equal weight, start by identifying the capabilities that are critical to the success of the project.

Data reliability, system integration, security, and scalability should generally be treated as fundamental requirements. A platform may offer advanced dashboards and analytics, but these provide limited value if meter data is incomplete, integrations are difficult to maintain, or the system cannot reliably support the required number of endpoints.

The weighting should then reflect the specific use case. For example, a utility deploying AMI across a large service territory may place greater emphasis on scalability, interoperability, cybersecurity, and network monitoring. A property owner or submetering provider may give greater importance to data completeness, leak detection, portfolio management, reporting, and integration with existing business systems.

A practical way to evaluate platforms is to classify requirements as critical, important, and desirable, and compare solution providers against the same criteria. This prevents attractive secondary features from outweighing capabilities that directly affect the reliability and long-term operation of the metering system.

How do you evaluate water loss and balancing analytics?

A useful test is to build a zone that can be checked manually. Mainlink’s utility materials pair non-revenue water tools with district metered area monitoring, which turns a one time zone check into a continuous one.

If a master meter records 1.06 million gallons during a defined period and downstream meters total 900,000 gallons, the measured difference is approximately 160,000 gallons, or 15% of the master meter volume. The platform should make that difference visible and allow the utility to investigate it.

The difference should not automatically be labeled as a physical leak. It may reflect real losses, meter inaccuracies, data timing differences, authorized consumption that was not billed, or other data and billing issues. Mainlink’s guide to non revenue water explains NRW as the difference between system input volume and billed authorized consumption and separates it into real losses, apparent losses, and unbilled authorized consumption.

This is also why data quality matters. The American Water Works Association Free Water Audit Software is designed for water balance assessment and provides a data grading framework to help utilities evaluate the reliability of audit inputs. A platform demonstration should therefore answer not only what a number is, but where it came from and how reliable the underlying data is.

Water loss is a material operational issue. A 2025 Bluefield Research analysis of more than 2,400 utility water loss audits across 11 US states reported that 19.5 percent of treated drinking water was lost before reaching customers or was improperly billed, representing more than 6.4 billion dollars in uncaptured annual revenue.

What mistakes should you avoid?

The first mistake is evaluating the interface before the data path. Compatibility, validation, export, billing integration, and handling of missing data determine whether the platform works in daily operations.

The second is testing only new meters. Existing meters may remain in service for years, particularly during a transition from AMR to AMI, so legacy compatibility should be proven before a larger rollout.

The third is to judge performance only by a network average. A strong overall read rate can still hide specific buildings, basements, or remote sites with persistent gaps. Review completeness by device, location, and time period.

The fourth is ignoring exit requirements. Confirm what data can be exported, in what format, and whether those rights are included in the contract.

Frequently Asked Questions

Is meter data management software the same as billing software?

No. Meter data management prepares and validates consumption data. Billing software applies tariffs, account rules, taxes, and other charges to produce an invoice for the resident. The two systems are commonly integrated.

Can one platform support both utility AMI and multifamily submetering?

It can, provided the platform supports the required account hierarchy, meter types, permissions, billing exports, and workflows. The evaluation should use a sample structure that reflects the intended deployment.

What does vendor agnostic mean when comparing platforms?

It means that platform is capable to integrate and read different brand meters.

How much historical data should be migrated?

There is no universal period. The decision should reflect billing dispute requirements, regulatory retention, seasonal analysis, reporting needs, and the cost of moving older information. Utilities should also decide whether they need only validated readings or raw device data.

Where to Go From Here

A strong platform evaluation follows the data from the meter to the final operational use. Start with the installed meter estate, define which software layers are needed, test real data, complete a billing cycle, verify alerts and water balance functions, review security, and confirm data export rights.

The platform should fit your current metering infrastructure while leaving room for future meters, IoT sensors, and integrations. That is a more reliable basis for selection than the most polished demonstration.