From meter to market: the 7-stage meter-to-bill chain

The meter-to-bill chain is a literal chain of custody, defined by industry codes and enforced by Ofgem licence conditions. Every reading, notification and meter event follows a sequence of stages. Knowing this chain is the foundation of every other topic in this course: governance, privacy, settlement and digitalisation all depend on knowing where data is, who holds it, and what has been done to it.

The chain is being rebuilt. Under MHHS the retrieval roles are the Smart Data Service for domestic and small non-domestic meters and the Advanced Data Service for larger advanced meters. The old profiling step becomes the Load Shaping Service, which shapes consumption only where an actual half-hourly read is missing. Aggregation is absorbed by the Market-wide Data Service, and every message is wired between parties by the Data Integration Platform (DIP), an Azure-based message router run by Avanade as DIP Service Provider. The seven stages below hold their shape; the agents behind them are what change.

1. Capture: the meter records energy consumed in a half-hour period
2. Store: the meter keeps the reading in its local register buffer
3. Transmit: the reading is retrieved through the DCC and published to the DIP
4. Validate: readings are checked for completeness, plausibility and conformance
5. Aggregate: validated data is grouped by supplier, meter point, period and settlement role
6. Settle: Elexon settlement systems calculate imbalance positions and cash flows
7. Bill: the supplier converts consumption and charges into the customer bill

Each stage is detailed below, with the legacy model it replaces named at the end.

Stage 1: Capture

Data is created at the point of measurement or observation. For a SMETS2 electricity meter, the metrology chip records instantaneous power in watts and accumulates energy in watt-hours. Every 30 minutes, it stores a register reading. For gas, a diaphragm meter records volume in cubic metres. For network data, a substation monitor records voltage, current, and power factor. The generation stage is physical: it depends on sensor accuracy, calibration certificates, and measurement standards traceable to the National Physical Laboratory.

At this stage, the data exists only on the device. It has not been transmitted, validated, or seen by anyone. The meter holds up to 13 months of half-hourly data in its local registers, providing a buffer against communication failures.

Stage 2: Store

Storage starts inside the meter before any central system sees the reading. The meter writes the half-hour value to its local register buffer with a timestamp, meter identifier and register context. This local storage is important because WAN failures do not automatically destroy the evidence. A later successful request can recover readings that were captured but not transmitted on the first attempt.

Stage 3: Transmit

Transmission is the act of moving data from the meter to authorised central systems. For smart meters, the Data Communications Company (DCC) provides the communications infrastructure. Under MHHS the Smart Data Service issues the service request through DCC systems to the meter over the WAN. Coverage splits by region: the DCC CSP North region uses Arqiva long-range radio across Scotland and northern England, while the Central and South regions, which include all of Wales, use Telefonica and Virgin Media O2 cellular. The meter responds with the register value and associated technical data, which is then published to the DIP.

Transmission introduces the first data quality risks outside the device. Communication failures, timeouts, incomplete responses, and WAN congestion can all prevent collection. The DCC reports a success rate above 96%, but for the remaining 4% the data must be estimated or recovered later. Gas meters add a further complication: the Zigbee HAN link between the gas meter and the electricity meter's communications hub is battery-powered and sends readings only every 30 minutes, introducing latency that does not exist for electricity.

Stage 4: Validate

Raw readings are checked against a set of validation rules before they enter any downstream system. Validation includes range checks (is the reading physically plausible?), consistency checks (is it higher than the previous reading?), format checks (correct number of digits, correct units), and identity checks (does this MPxN, the meter point reference behind every MPAN and MPRN, match a registered supply point?). Readings that fail validation are flagged for manual investigation or replaced with estimates calculated from historical consumption patterns.

The validation rules are defined in the Balancing and Settlement Code (BSC) for electricity and the Uniform Network Code (UNC) for gas. They are not optional: licensees are required to apply them, and Ofgem audits compliance through the Performance Assurance Framework. Poor validation has direct financial consequences. If an invalid reading enters settlement, it distorts imbalance calculations and misallocates costs across the entire market.

Stage 5: Aggregate

Aggregation turns validated readings into the volumes needed for market calculations. Under MHHS the Market-wide Data Service groups half-hourly reads by supplier, by Settlement Period and by GSP Group, the fourteen regional groupings that sit above the physical Grid Supply Point (GSP) boundaries. Where an actual half-hourly read is missing, the Load Shaping Service supplies a shaped estimate rather than the old profile class. Aggregation must preserve traceability, because every downstream cash-flow calculation depends on knowing which reads contributed to each total.

Other aggregation includes demand forecasting, network capacity analysis and billing preparation. Every aggregation step adds value but also adds risk: errors compound through the chain, which is why validation at Stage 4 matters so much.

Stage 6: Settle

Settlement turns aggregated consumption and contractual positions into market balances. The Settlement Administration Agent calculates imbalance positions, and the Funds Administration Agent manages the resulting cash flows between BSC parties. Settlement is repeated through reconciliation runs as more actual data becomes available and estimates are replaced.

Settlement outputs are shared with entitled parties under the Balancing and Settlement Code. Data Best Practice adds a separate rule for non-personal energy datasets: data assets should be treated as presumed open unless the custodian has evidence for reducing availability, for example privacy, security, legal or commercial sensitivity.

Stage 7: Bill and retain evidence

Billing converts consumption, tariff rates, network charges, policy costs and VAT into the amount the customer sees. Evidence then has to be retained for audit, complaint handling, reconciliation and regulatory purposes. Storage limitation under UK GDPR still applies to personal data, so retention has to be justified by purpose rather than treated as indefinite.

The outgoing world: MOP, DC and DA

The chain above is replacing a decades-old arrangement. In the legacy model a supplier appointed a Meter Operator (MOP) to install and maintain the meter, a Data Collector (DC) to retrieve and validate reads, and a Data Aggregator (DA) to total them for settlement. Domestic consumption was mostly settled on estimated profiles rather than actual half-hourly data. That MOP, DC and DA chain is being dismantled as meter points migrate: the Smart Data Service and Advanced Data Service take over retrieval, the Load Shaping Service takes over shaping, and the Market-wide Data Service takes over aggregation. Both models run in parallel until migration finishes in May 2027, which is why a working knowledge of the old names still matters.

Abstract stages become concrete when you trace a single reading end to end. Let us follow 1.47 kWh recorded by a SMETS2 electricity meter in a three-bedroom house in Birmingham between 07:00 and 07:30 on a Tuesday morning in January. The household is on a standard variable tariff with a mid-sized supplier. We run the half-hour through the MHHS chain, then note where the legacy chain did the same job differently.

07:00 to 07:30: Capture

The metrology chip records energy consumption. The family is having breakfast: the kettle, toaster, fridge-freezer, lighting and a phone charger are all drawing power. The meter accumulates 1.47 kWh over the half-hour period and stores it in register 2 (import active energy, TOU rate 1).

07:31: Transmit

The Smart Data Service asks the DCC to retrieve the half-hour. The scheduled read uses a Service Request from the 4.8 family (Read Active Import Profile Data), the request built for scheduled half-hourly profile reads; the on-demand 4.1.1 Read Instantaneous Import is a different request, used to read the register live rather than on a schedule. The meter responds with the register value over the Virgin Media O2 cellular WAN. The response carries the meter serial number, the MPAN, the timestamp and the register reading. Transit from meter to the DCC central systems typically takes under ten seconds, and the Smart Data Service publishes the read to the DIP for the settlement parties that have subscribed to it.

08:00 to 10:00: Validate

Validation applies the BSC rules to the read. The 1.47 kWh is compared with the previous half-hour (1.12 kWh) and the same half-hour on the previous Tuesday (1.39 kWh). It passes: it sits in the expected range for this home and time of day, the register has advanced rather than reversed, and the MPAN matches a registered supply point. Under MHHS this actual half-hourly value is what settles the period; the Load Shaping Service would only step in if the read were missing, and the old Data Collector role that used to run this check is being retired as meters migrate.

Day+1: aggregate, allocate and calculate

The path the half-hour has now taken is the MHHS path in three hops: meter to Smart Data Service, Smart Data Service to DIP, DIP to Market-wide Data Service. The MDS is the subscriber that matters for settlement: it takes the published read off the DIP and totals it with every other read for that supplier, Settlement Period and GSP Group, the job the Data Aggregator used to do. Under the legacy chain the same half-hour would have gone meter to Data Collector to Data Aggregator over the DTS, and for a domestic non-half-hourly meter it would not have been read at all: a profile class would have stood in for it.

The MDS aggregate then reaches the supplier's billing system and the Supplier Volume Allocation Agent (SVAA). The SVAA is one central Elexon service, not a machine sitting at each substation. It runs volume allocation and GSP Group correction across the fourteen GSP Groups, placing the 1.47 kWh in the group its MPAN belongs to. That grouping feeds loss factors and network charges, not a separate regional settlement price.

Settlement then totals the supplier's metered volume in that GSP Group and compares it with the supplier's contracted position (their Forward Contract Notifications and Bid-Offer acceptances). The difference is the supplier's imbalance volume, priced at a single national imbalance price for the Settlement Period. GB moved to a single cash-out price years ago, so one price settles both long and short positions in each half-hour; only the direction of the cash flow differs.

Day+16 working days: Initial Settlement

The first proper settlement run, Initial Settlement (SF), lands 16 working days after the settlement day. The SF volume allocation run sits a day earlier, at 15 working days, which is the source of a common off-by-one confusion. This run uses the metered data available so far and estimates the rest. The Funds Administration Agent then works out the cash flows and moves money between BSC Trading Parties. For this GSP Group and this half-hour the supplier turns out to be 2.3 MWh long, having contracted more than its customers used, so it receives a credit at the single imbalance price for the period.

Reconciliation across the following months

Settlement does not stop at SF. Reconciliation runs fold in more actual data, corrections and dispute outcomes as they arrive. Under today's timetable the ladder runs out to a final run about 14 months after the settlement day, and each run can move the imbalance figure and the cash that follows it. After the final run the data is archived but stays reachable for regulatory investigation.

The M16 settlement timetable cutover, due early in July 2027, compresses this ladder. Initial Settlement drops from 16 working days to about seven, and final settlement moves from roughly 14 months to about four. Carrying settlement uncertainty for a shorter time cuts the cash-flow risk every party holds.

End of billing period: The 42p

At the end of the billing period, the supplier prices the 1.47 kWh at the customer's unit rate of approximately 24.5p per kWh plus standing charge. The 1.47 kWh contributes about 36p in energy cost, plus approximately 6p allocated to network charges, policy costs, and VAT. The customer's bill shows a single line: “Electricity used: 1.47 kWh, 42p.” Behind that line lies the entire lifecycle we have just traced.

The GB energy system does not have one data platform. It has evolved three, each built for a different era and a different purpose. Understanding their roles, overlaps, and planned succession is essential for anyone working with energy data.

Data Transfer Service (DTS), the legacy workhorse

The DTS has been the backbone of energy data exchange for over 25 years. It uses structured flat files in Data Transfer Catalogue (DTC) formats, exchanged between market participants via secure file transfer. Every settlement reading, meter registration, change of supplier notification, and exception report has flowed through DTS files. The format is rigid, well-understood, and deeply embedded in every participant's IT systems.

The DTS works, but it has serious limitations. Data flows are batch-based, with most files processed overnight. There is no real-time capability. The file formats are proprietary to the GB market and incompatible with modern API standards. Error detection relies on manual exception reports rather than automated validation. Onboarding a new participant requires implementing the full DTC specification, which is a significant barrier to entry for innovators and small market entrants.

Data Integration Platform (DIP), the MHHS enabler

The DIP went live in August 2025 as the data exchange platform for MHHS. It is an Azure-based message router operated by Avanade as DIP Service Provider. Unlike the DTS, it uses RESTful APIs and event-driven publish-subscribe messaging, so data flows in near real time rather than overnight batches, and it enforces standard data models and validation at the point of entry, reducing downstream errors.

The DIP is not a database. It is a messaging platform: data flows through it but is not permanently stored in it. Participants publish messages (meter readings, registration events, exception notifications) and authorised subscribers receive them. This design supports the compressed settlement timelines required by MHHS and reduces the latency from days to minutes.

As MHHS migration completes through to May 2027, settlement-relevant data moves onto the DIP rather than the DTS. The DTS does not vanish at once: non-settlement flows such as change of tenancy, meter removals and ad-hoc reads keep using it until they too migrate, which may take several more years. The DTS is a legacy network being wound down, not switched off overnight.

Data Sharing Infrastructure (DSI), the cross-sector discovery layer

The DSI is the most ambitious of the three platforms. NESO describes it as a socio-technical solution that brings together common processes, governance and technology so the energy sector can share data and models in a scalable, secure and resilient way. Where the DIP handles electricity market messaging for MHHS, the DSI is aimed at cross-sector discovery, trust and controlled access.

The DSI is not a warehouse that stores all energy data. It is better understood as shared public digital infrastructure: catalogues, trust services, governance, standards and access processes layered over data that remains with multiple custodians. This distinction matters because it avoids implying that DSI replaces DCC, DIP, DTS, supplier systems or network company systems.

Ofgem appointed NESO as interim DSI coordinator for the 2024 to 2028 period. Delivery is therefore staged rather than a single launch date. The course treats DSI as in development under interim coordination until a current primary source confirms a firmer enduring operating model.

Gas data: a parallel lifecycle

Gas data follows the same seven stages but with critical differences. Gas meters record volume in cubic metres, which must be converted to energy (kWh) using the Calorific Value (CV) of the gas, measured daily at each Local Distribution Zone. The correction formula (Volume × CV × 1.02264 ÷ 3.6) introduces a variable that electricity does not have. Gas settlement operates under the Uniform Network Code (UNC) rather than the BSC, with its own agents (Xoserve operates the Central Data Service Provider role) and its own timelines.

Gas data also has a latency problem. Gas smart meters send readings via the electricity meter's communications hub using ZigBee, which adds delay. Battery life constraints mean gas meters transmit less frequently than electricity meters. And gas does not yet have half-hourly settlement: allocation is daily, which means the per-period accuracy that electricity achieves is not yet available for gas. The gas lifecycle gets its own treatment in gas-data-in-depth, where Unidentified Gas, the AUGE and the calorific value chain are worked through in full.

MHHS is not a single switch but a staged migration, and knowing the dates is part of reading the data correctly. The central systems went live on 22 September 2025. The migration of meter points began on 22 October 2025 and runs for eighteen months to May 2027, moving MPANs from the legacy MOP, DC and DA arrangements into the new roles in tranches. Around 80 percent of meters are expected to be migrated by October 2026, so for most of 2026 the two models run side by side.

The settlement calendar changes last. The M16 timetable cutover is due early in July 2027, once migration is essentially complete. Before M16, Initial Settlement lands 16 working days after the settlement day and the final reconciliation run completes about 14 months later. After M16, Initial Settlement drops to about seven working days and final settlement to about four months. The practical effect is that a supplier's imbalance position firms up far sooner, which lowers the working capital each party has to hold against late corrections.