Smart meter data journey in Austria

Around 97% of all electricity connections in Austria now have a smart meter. Before its readings reach a system you can work with, they pass through six stations, and each one brings its own technical task. Together, they explain why automated access to smart meter data in Austria takes real work.

Station 1: The smart meter measures

It starts with the meter itself. A smart meter records energy consumption in 15-minute intervals. Since the ElWG (December 2025), quarter-hourly values are the default resolution in Austria.

It measures two directions:

• Consumption: electricity drawn from the grid (in kWh)
• Feed-in: electricity fed back into the grid, for example from a photovoltaic system

Data quality varies: each reading is tagged with a quality level by the grid operator. L1 (measured) and L2 (reliable substitute) are considered final and authoritative. L3 values are preliminary and must be replaced by the grid operator within 60 days.

As a business, you don't read this data directly from the meter: the meter transmits it to the responsible grid operator (Netzbetreiber) via powerline communication (PLC) or mobile networks.

Station 2: The grid operator collects

Austria has around 146 distribution grid operators, among them large companies like Wiener Netze or Netz Niederösterreich and small municipal utilities. Each grid operator is responsible for a specific geographic area and collects data from all smart meters in their territory.

Every metering point is uniquely identified by its metering point number (Zählpunktnummer). This 33-character identifier begins with an 8-character prefix that identifies the grid area, which in most cases tells you which grid operator a data request has to go to.

Grid operators store the measurement data and make it available through Austria's regulated, shared data exchange infrastructure.

Station 3: The EDA network transports

EDA stands for Energiewirtschaftlicher Datenaustausch (Energy Data Exchange) and is Austria's regulated infrastructure for exchanging energy data between market participants. We explain the EDA network in detail in a dedicated article.

The EDA network is a decentralized messaging system: participants exchange encrypted XML messages following an industry-specific standard (ebutilities). There is no central database; each participant operates their own infrastructure.

There are three ways to connect to the EDA network:

• EDA Portal: a web interface for manual queries that needs no software of your own and cannot be automated.
• Email connection: for market participants with their own software, suitable for up to around 200 metering points.
• Dedicated communication endpoint: for more than 200 metering points: specialized communication software installed and operated locally on your own infrastructure. This endpoint consists of two software components and requires ongoing maintenance.

For businesses that need to process smart meter data programmatically, the first option is too limited. The other two require either custom software or dedicated infrastructure, plus registration as a market participant with your own participant address.

Station 4: The consent process

Before any data can flow, the meter holder must give explicit consent. This process is regulated by law and GDPR-compliant.

The process:

1. An authorized service provider submits a data access request for a specific metering point via the EDA network.
2. The responsible grid operator validates the request.
3. The meter holder must confirm the consent on their grid operator's web portal. This step cannot be automated; it requires a deliberate decision by the meter holder.
4. Once confirmed, data delivery begins.

The exact technical flow is documented in the official ebutilities process diagram.

Consent is valid for a defined period of up to three years and can be revoked at any time by the meter holder. From request to approval, the process takes seconds to hours in most cases, depending on the grid operator.

Station 5: Processing

Once consent is active, data is delivered on a T-1 basis: yesterday's consumption values are available today.

The raw data arrives as XML messages, from each grid operator individually, and operators can have different delivery schedules and procedures. The data must be:

• parsed: XML messages converted into a usable format
• validated: consistency checks, duplicate handling
• transformed: the industry-specific XML format converted into usable formats like JSON or CSV
• quality-monitored: each reading carries a quality level (L1/L2/L3), and when the grid operator replaces preliminary L3 values with better data, the updates have to be incorporated

Data volumes grow quickly: at 96 readings per metering point per day, 1,000 metering points produce around 96,000 records daily. Storage must handle time-series data efficiently: compression, retention policies, and fast queries.

Station 6: Delivery to your system

The final station is the goal: getting the data where it's needed. Depending on the use case, different delivery methods apply:

• REST API: for software integration and on-demand queries
• Webhooks: a notification as soon as new data arrives
• CSV via email: for teams that analyze data in spreadsheets

MQTT (for IoT applications) and SFTP (for ERP integration) are available as well.

Each delivery channel brings its own challenges: error handling, retry logic, format conversion, delivery monitoring. When a webhook fails, data must not be lost. When a CSV delivery is missed, it needs to be detected and retried.

Why this journey is so complex

Count the technical components and you get a substantial list:

• Meter communication (handled by the grid operator)
• Registration as an EDA market participant
• Dedicated communication endpoint with specialized, licensed software
• Consent management for each individual metering point
• Parsing and transforming XML messages into usable formats
• Data quality monitoring and handling of substitute values
• Efficient time-series storage
• Multiple delivery channels, each with their own error handling
• Twice-yearly protocol updates from the EDA network that must be implemented

In our experience, building your own EDA integration takes several months, and after that each of these components needs specialized knowledge and ongoing maintenance.

For businesses whose core product is not EDA infrastructure, this effort quickly outweighs the benefit. Managed services like energiedaten.at take this work over and deliver the data through REST API, webhooks and CSV, whether for internal optimization or to meet EEffG and CSRD reporting requirements.

Read our article on automation to learn when manual data collection reaches its limits.