Why Metering Companies in AU/NZ Need a Control Tower for AMI Data Delivery

Fixing the blind spot in AMI data delivery

For metering companies in Australia and New Zealand, Advanced Metering Infrastructure (AMI) should be a competitive advantage. It enables accurate billing for retailers, powers DER orchestration for VPPs, and supports newer services like dynamic tariffs and community batteries.

But in reality, AMI data delivery is still a black box.

Despite well-established MDMS systems and mature meter fleets, many providers continue to breach SLAs, delay customer reports, and rely on reactive manual checks to find out when something has gone wrong.

At the root of the problem is a lack of operational observability across the AMI delivery chain.

The disconnect between data received and data delivered

The data journey in AMI delivery is deceptively complex.

What’s expected by customers often doesn’t match what’s produced by your systems or ultimately delivered through APIs or file drops. These gaps appear in four places:

1. Expected data: What customers have subscribed to

2. Received data: What you ingest from your MDMS

3. Produced data: What your systems process and package

4. Delivered data: What actually lands with the retailer, VPP, or network

The lack of visibility between these layers results in late detection of delivery failures. Operational teams often find out about missing files only when a customer calls. And data quality teams spend hours manually investigating gaps across logs, reports, and FTP archives.

This breakdown isn’t just inefficient, it carries cost. SLA penalties, reputational risk, regulatory exposure, and missed revenue from real-time services like flexible exports or FCAS participation are now common consequences.

Why metering SLA compliance needs observability, not more tools

Most metering companies already have a Meter Data Management System in place. But MDMS platforms are not built for SLA assurance. They track ingestion and storage, not customer delivery expectations or file-level fulfilment.

What’s missing is a solution that gives operational teams real-time answers to questions like:

• Did we publish complete and accurate AMI data for every NMI, register, and suffix?

• Where are the AMI data gaps, and how early can we catch them before they breach an SLA?

• How does our delivered data compare to what the customer expected today, not at the end of the month?

This is where the Smart Meter Operational Console (SMOC) fits in.

Introducing SMOC: A control tower for AMI customer delivery

At Aurion Systems, we built SMOC, the Smart Meter Operational Console, specifically to address this invisible but costly failure point in the AMI pipeline. It’s a cloud-native observability and reconciliation solution designed for metering companies in Australia and New Zealand that are managing high volumes of retail, VPP, and community energy data.

SMOC doesn’t replace your MDMS. Instead, it wraps around your existing metering environment to provide visibility across the entire AMI data delivery lifecycle from what the customer subscribed to, to what was received from the MDMS, processed by your pipeline, and finally published downstream. That includes surfacing gaps like missing intervals, incomplete registers, or short-published NMIs long before a customer flags it.

With SMOC in place, your team gets:

• A real-time view of expected vs delivered AMI data at NMI > Meter > Register > Suffix level

• Daily reports showing data quantity and quality, what was received from the MDMS, what was expected, and what was actually published

• Self-serve dashboards for operational teams to quickly validate data quality without escalating to tech or BI

This isn’t just another dashboard. We built SMOC to be your operational control tower, for AMI delivery, helping your team stay accountable, respond faster, and reduce penalties, all without chasing logs and spreadsheets.

How SMOC integrates with your stack

We designed SMOC to plug into your existing architecture with zero disruption, so your team can move fast without rebuilding workflows. It consumes data from your existing MDMS, including NEM12/13 extracts, and combines that with customer subscription logic, delivery output logs, and file-level states. From there, it continuously monitors expected vs actual delivery performance across all channels.

SMOC is built entirely on AWS-native services:

• Glue Spark ETL for ingest and transformation

• Lambda functions for event-driven workflows

• S3 for storage and traceability

• Grafana dashboards for rich visualisation and reporting

No matter which systems you already use, SMOC enhances them by adding a modular, real-time visibility layer, making it easier for teams to spot breakdowns, restore trust, and support emerging use cases like dynamic pricing, BESS, and DER orchestration.

What SMOC delivers, and why it matters

Implementing SMOC doesn’t just make your data operations more efficient, it directly impacts the KPIs that matter to your business:

Across multiple deployments, we’ve helped metering teams reduce their daily reconciliation effort by up to 70% , not just by automating reports, but by giving them early visibility into AMI data gaps across the delivery chain. In several cases, teams discovered issues that had been missed for weeks, like NMIs publishing only partial intervals, or entire suffixes dropping out.

How we can help...

AMI data delivery has become central to how retailers bill, how VPPs participate in FCAS, how community batteries operate, and how customers engage with energy services. As expectations from AEMO, retailers, and end users rise, the cost of getting it wrong is only increasing.

If your team is still chasing AMI data issues, reconciling missing registers manually, or relying on server logs to figure out what was sent, SMOC helps you get ahead of those gaps instead of reacting after the fact. Book a walkthrough of SMOC and get a tailored readiness assessment for your metering environment.