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. Understanding 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.

For a half-hourly electricity reading, the seven stages are operational rather than abstract. A meter captures the value, stores it locally, DCC transmits it, the supplier and settlement agents validate it, Elexon aggregates it, settlement calculates market positions, and the supplier turns the settled consumption into a bill line.

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 moves through the DCC WAN and authorised market interfaces
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.

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. An authorised user sends a service request through DCC systems to the meter via the WAN: VMO2 cellular in south and central GB, or Arqiva radio mesh in the north, Scotland and Wales. The meter responds with the register value and associated technical data.

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 MPAN or MPRN match a registered meter?). 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.

“BSC parties shall ensure that all meter readings submitted for settlement have been validated in accordance with the validation rules set out in the BSC and associated procedures, and that no estimated reading is used where an actual reading is available.”

Elexon, Balancing and Settlement Code - Section S

This BSC provision makes Stage 4 (Validate) a legal obligation, not a technical preference. A supplier that submits unvalidated readings faces Performance Assurance action and potential settlement charges if invalid data inflates or deflates their imbalance position.

Stage 5: Aggregate

Aggregation transforms validated readings into the volumes needed for market calculations. Settlement processing is the most complex example: settlement agents allocate half-hourly meter readings to Grid Supply Points, suppliers, settlement periods and market roles. Aggregation must preserve traceability because every downstream cash-flow calculation depends on knowing which readings 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.

Abstract stages become concrete when you trace a single reading through the entire chain. 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.

07:00 - 07:30: Generate

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: Collect

The DCC's Data Service Provider (DSP), operated by CGI, polls the meter via a scheduled Service Request 4.1.1 (Read Instantaneous Import). The meter responds with the register value over the VMO2 cellular WAN. The response includes the meter serial number (MSN), the MPAN, the timestamp, and the register reading. Transit time from meter to the DCC's central systems is typically under 10 seconds. The DCC logs the successful collection and forwards the data to the registered supplier.

08:00 - 10:00: Validate

The supplier's Meter Operator Agent (MOA) and Data Collector (DC) apply BSC validation rules. The 1.47 kWh reading is checked against the previous half-hour (1.12 kWh) and the same half-hour on the previous Tuesday (1.39 kWh). The reading passes all checks: it is within the expected range for this profile class and time period, the register has advanced (not reversed), and the MPAN matches a registered supply point.

Day+1: Store and process

The validated reading enters the supplier's billing system and is also submitted to the Supplier Volume Allocation Agent (SVAA). The SVAA operates at each of the approximately 350 Grid Supply Points (GSPs) across England, Wales, and Scotland. It allocates the 1.47 kWh to the correct GSP based on the MPAN's registered location. This allocation determines which regional price applies.

The Settlement Administration Agent (SAA) then calculates the supplier's total metered volume at this GSP and compares it to the supplier's contracted position (their Forward Contract Notifications and Bid-Offer acceptances). The difference is the supplier's imbalance volume, which is settled at the System Buy Price (SBP) or System Sell Price (SSP). Current GB cash-out has a single price calculation, so SBP equals SSP in each Settlement Period even though the cashflow direction differs.

Day+15 working days (SF run): Share

The SAA publishes the first Settlement Final (SF) run. This initial calculation uses the metered data available at that point and estimates the rest. The Funds Administration Agent (FAA) calculates the cash flows and arranges payments between BSC Trading Parties. The supplier discovers that its imbalance for this GSP, for this half-hour, was 2.3 MWh long (they had contracted more than their customers consumed). They receive a credit at SSP, which equals SBP for that Settlement Period.

Reconciliation to Month+14: Reconciliation and archive

Settlement does not stop at the SF run. Reconciliation runs incorporate more actual data, corrections and dispute outcomes as they become available. Elexon describes the current settlement process as taking 14 months to complete. Each run can change the imbalance calculation and the associated cash flows. After the final run, the data is archived but must remain accessible for regulatory investigation.

Under Market-Wide Half-Hourly Settlement (MHHS), the timeline compresses dramatically. The SF run moves from 15 Working Days to seven Working Days. The final reconciliation moves from 14 months to seven months and then four months. This compression reduces cash-flow risk because parties carry settlement uncertainty for less time.

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 primary data exchange platform for Market-Wide Half-Hourly Settlement. Unlike the DTS, the DIP uses RESTful APIs and modern messaging patterns (event-driven architecture with publish-subscribe). Data flows are near real-time rather than batch. The DIP enforces standardised 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.

By the time MHHS reaches full migration (expected 2027), all settlement-relevant data will flow through the DIP rather than the DTS. However, the DTS will not disappear immediately: non-settlement data flows (change of tenancy, meter removals, ad-hoc reads) will continue to use DTS until they are migrated, which may take several more years.

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 Transporters shall publish daily Calorific Value data for each Local Distribution Zone, and this data shall be used by all parties for the conversion of gas volume to energy for billing and settlement purposes.”

Uniform Network Code

This UNC provision creates the parallel gas lifecycle described in this section. Unlike electricity settlement which uses meter readings directly, gas settlement requires a two-step process: volumetric meter reading plus UNC-mandated calorific value data. The CV publication obligation ensures all parties use the same energy conversion factor.

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.