Installed is not the same as integrated.

Rollout dashboards count meters in the ground. They rarely count whether the data those meters produce ever reaches a billing system intact, and that gap is where AMI programmes quietly lose their return.

India's Revamped Distribution Sector Scheme reports 20.33 crore smart meters sanctioned and 6.00 crore installed by early August, roughly 29.5% completion. That number is real and it is meaningful. It is also, on its own, the wrong thing to watch.

An installed meter is a physical fact. A meter whose readings are validated, exceptions resolved and data correctly routed to billing is an operational fact, and it is the second one that pays for the programme. Between the two sits a layer that rollout dashboards rarely show: the head-end system that manages device communication, and the meter data management platform that decides whether a reading is trustworthy before it ever reaches a customer's bill.

Two systems, two jobs

The head-end system talks to the meter fleet. It manages communication sessions, pushes firmware, and collects raw interval data at scale. The meter data management system does something different: validation, estimation and editing, long-term storage, and exception handling for the readings that do not make sense on first pass. Without that second layer, unvalidated head-end data flows straight into billing engines, and every anomaly the meter recorded becomes a customer's problem before anyone catches it.

This is why the UK's approach is instructive. A recent contract award for a Meter Data Management System to support AMI for roughly 135,000 business customers was procured separately from the head-end systems and communication networks, and it runs in parallel with a distinct procurement for smart water metering. That separation is not bureaucratic overhead. It is an acknowledgement that data management is its own discipline, with its own vendor market and its own failure modes, and that bundling it as an afterthought to installation is how programmes end up with meters that work and billing that doesn't.

What the integration work actually involves

For DISCOMs in India, the practical guidance now circulating is specific: audit the current interfaces between head-end, MDM, billing and CRM systems before adding volume; prioritise billing-cycle and prepaid workflows first, since those are where unvalidated data causes the most immediate customer harm; and link tamper alarms directly into revenue-protection operations rather than leaving them as unactioned log entries. The same guidance pushes utilities to stitch consumer AMI data together with feeder and distribution transformer meters to build loss heat maps that separate technical losses from commercial ones, work that is only possible once the data pipeline underneath is trustworthy.

Germany's rollout adds a related but distinct piece of the same problem. Corinex and EFR have finalised an interoperable G.hn broadband powerline solution built specifically to move data reliably between meters and utility back-end systems over existing power lines, ahead of Germany's target of 95% smart meter penetration by 2030 under the GNDEW roadmap. Interoperability at the communication layer matters because it determines whether a head-end system ever receives clean, complete data in the first place. A rollout can hit its installation targets and still deliver a communications network that drops or corrupts readings under load, which pushes the validation burden further downstream onto MDM systems that were never sized for it.

Why this matters more as deadlines tighten

The UK's Post 2025 Smart Metering Policy Framework requires suppliers to take all reasonable steps to reach 100% of domestic properties by 31 December 2030, replace legacy SMETS1 assets and communications hubs by 2033, and restore any meter found operating in traditional mode back to smart mode within 90 days of becoming aware of it. Every one of those obligations depends on knowing, in near real time, which meters are actually reporting usable data and which have quietly degraded. That knowledge lives in the MDM layer, not in an installation count.

Universal head-end architectures are being discussed in the market precisely because multi-vendor meter fleets, now the norm rather than the exception, make consistent data handoff to MDM harder, not easier. A head-end that can only cleanly serve one meter vendor's data model is a liability the moment a second vendor enters the fleet, which is increasingly when, not if.