Agentic MDM im Ex-Post Redispatch 2.0

Konzepte zur automatisierten Fehlererkennung und Stammdaten-Heilung in Redispatch-Prozessen. Wie Agenten proaktiv fehlende BTR-Daten oder abweichende Fahrpläne identifizieren, bevor kaufmännische Abrechnungsschleifen eskalieren.

• Die Abrechnungsfalle im Ex-Post Redispatch
• Proaktive Stammdaten-Heilung — Die Agenten-Logik
• Vom Notfallverfahren zur Automatisierung

Die Abrechnungsfalle im Ex-Post Redispatch

Die Energiewende erzeugt nicht nur Strom. Sie erzeugt Abrechnungsfälle. Über 2.200 Redispatch-Maßnahmen allein im Januar 2026, mit einem Volumen von 3,3 TWh. Für jeden einzelnen Fall muss ein Verteilnetzbetreiber die Ausfallarbeit berechnen, die Entschädigungsansprüche zuordnen und die Abrechnung an den ÜNB weiterleiten. Die Physik dieser Maßnahmen ist trivial: Anlage abregeln, Leistung reduzieren, Engpass beseitigen. Die Administration ist es nicht.

Das operative Massengeschäft

Redispatch 2.0 ist seit Oktober 2021 verpflichtend. Jede Erzeugungsanlage ab 100 kW ist grundsätzlich redispatch-pflichtig. Für einen typischen städtischen Verteilnetzbetreiber bedeutet das ein Portfolio von 40 bis 80 Anlagen, die potenziell in Redispatch-Maßnahmen einbezogen werden können — Photovoltaik-Freiflächenanlagen, KWK-Anlagen, Biomassekraftwerke, Batteriespeicher und Notstromaggregate.

Jede Abregelungsmaßnahme erzeugt einen finanziellen Entschädigungsanspruch des Anlagenbetreibers. Die Ausfallarbeit — die Differenz zwischen der prognostizierten Einspeisung ohne Abregelung (Planwert) und der tatsächlichen Einspeisung während der Maßnahme (Ist-Wert) — muss berechnet, zugeordnet und abgerechnet werden. Das klingt nach einer Subtraktionsaufgabe. In der Praxis ist es ein Datenzuordnungsproblem, das über vier Systeme verteilt ist.

Die Ex-Post-Prozesskette: Wo sie bricht

Die Abrechnung einer einzelnen Redispatch-Maßnahme durchläuft einen Prozess, der sich in den meisten Verteilnetzbetreibern wie folgt darstellt:

Schritt 1: Abruf im Leitsystem. Der Übertragungsnetzbetreiber (ÜNB) oder der Verteilnetzbetreiber selbst initiiert eine Redispatch-Maßnahme. Das Netzleitsystem (SCADA) dokumentiert den Abruf: Zeitpunkt, betroffene Anlage (identifiziert über die technische Ressource), Sollwert der Leistungsreduktion und Dauer der Maßnahme.

Schritt 2: Identifikation der betroffenen Anlage. Die technische Ressource im Leitsystem muss einer kaufmännischen Einheit zugeordnet werden — dem Betreiber der technischen Ressource (BTR). Diese Zuordnung verknüpft die physische Abregelung mit dem wirtschaftlichen Anspruchsinhaber. In der Realität ist diese Zuordnung keineswegs trivial: Eine Erzeugungseinheit im MaStR kann einem anderen BTR zugeordnet sein als im ERP-System des Netzbetreibers. Der BTR kann gewechselt haben, ohne dass die Änderung in allen Systemen nachgezogen wurde.

Schritt 3: Berechnung der Ausfallarbeit. Die Ausfallarbeit ergibt sich aus dem Vergleich von Planwert (erwartete Einspeisung ohne Eingriff) und Ist-Einspeisung (gemessene Einspeisung während der Maßnahme). Der Planwert kommt typischerweise vom Einsatzverantwortlichen (EIV) oder wird vom Netzbetreiber selbst prognostiziert. Der Ist-Wert kommt aus dem Messsystem über die Marktlokation (MeLo) und den zugehörigen Zählpunkt. Beide Werte müssen derselben Anlage, demselben Zeitraum und demselben Messkonzept zugeordnet sein.

Schritt 4: Kaufmännische Abrechnung. Die berechnete Ausfallarbeit wird in das ERP-System (typischerweise SAP IS-U) überführt. Dort erfolgt die Erzeugung des Entschädigungsbetrags, die Zuordnung zum Bilanzkreis und die Erstellung der Abrechnungsnachricht im EDIFACT-Format — konkret über den Prozess der AAÜZ-Erzeugung (Ausfallarbeits-Übergangszahlungsanspruch). Die erzeugten Dateien werden per SFTP an den Übertragungsnetzbetreiber übermittelt.

Wo es in der Praxis scheitert

Dieser Vier-Schritt-Prozess funktioniert genau dann reibungslos, wenn die Stammdaten in allen beteiligten Systemen konsistent sind. Das sind sie in der Praxis selten. Die typischen Fehlermuster:

Fehlende BTR-Zuordnung. Die Anlage wurde im Leitsystem abgeregelt, aber die aktuelle BTR-Zuordnung liegt im kaufmännischen System nicht vor. Der BTR hat gewechselt (z. B. durch Verkauf der Anlage), die EDIFACT-Meldung des neuen BTR ist noch nicht verarbeitet, oder der BTR wurde im MaStR aktualisiert, aber nicht im SAP. Resultat: Die Abrechnung kann nicht erzeugt werden, weil der Zahlungsempfänger nicht identifiziert ist.

NAP-MeLo-Fehlzuordnung. Eine reale Herausforderung entsteht, wenn mehrere Erzeugungseinheiten denselben Netzanschlusspunkt (NAP) nutzen, aber unterschiedliche Marktlokationen (MeLo) haben. Ein Fernheizkraftwerk mit vier Dampfturbinen und einem Batteriespeicher kann an einem einzigen NAP angeschlossen sein, aber über vier separate MeLo-IDs verfügen. Wenn das Leitsystem die Abregelung auf NAP-Ebene dokumentiert, die Abrechnung aber auf MeLo-Ebene erfolgen muss, entsteht ein Zuordnungsproblem, das manuell aufgelöst werden muss: Welche MeLo-ID gehört zu welchem Abruf? Welcher Anteil der Leistungsreduktion entfällt auf welche Einheit?

Planwert-Ist-Wert-Diskrepanz. Der Planwert (die prognostizierte Einspeisung ohne Abregelung) stammt aus einem anderen Quellsystem als der Ist-Wert (die gemessene Einspeisung). Wenn der Planwert auf einem veralteten Erzeugungsprofil basiert — etwa weil die Anlage erweitert wurde, aber die Aktualisierung des Profils im Prognosesystem noch nicht erfolgt ist — wird die Ausfallarbeit systematisch falsch berechnet. Der Anlagenbetreiber erhält zu viel oder zu wenig Entschädigung, und die Differenz wird erst sichtbar, wenn die Monatsabrechnung im SAP läuft.

Das Notfallverfahren: Telefon und Excel

Wenn einer dieser Bruchpunkte eintritt — und in einem Portfolio von 50+ Anlagen tritt mindestens einer pro Abrechnungszyklus ein —, greifen Verteilnetzbetreiber auf das zurück, was intern als Notfallverfahren bezeichnet wird. Der Sachbearbeiter identifiziert den fehlerhaften Datensatz manuell, klärt die korrekte BTR-Zuordnung per Telefonat mit dem Einsatzverantwortlichen oder dem Anlagenbetreiber, dokumentiert die Korrektur in einer Excel-Tabelle und vermerkt den Vorgang im Betriebshandbuch.

Dieses Verfahren hat drei Eigenschaften, die es als Dauerlösung disqualifizieren. Erstens ist es nicht auditierbar: Ein Excel-Vermerk im Betriebshandbuch erfüllt nicht die Anforderungen an eine revisionssichere Dokumentation, die bei regulatorischen Prüfungen oder Streitigkeiten mit Anlagenbetreibern standhält. Zweitens skaliert es nicht: Bei steigendem Redispatch-Volumen — national hat sich das Volumen seit Einführung von Redispatch 2.0 vervielfacht — wächst die manuelle Nacharbeit linear mit der Anzahl der Maßnahmen. Und drittens ist es reaktiv: Der Fehler wird erst sichtbar, wenn die Monatsabrechnung scheitert. Wochen nach der eigentlichen Maßnahme. Wochen, in denen der fehlerhafte Datensatz weitere Folgefehler erzeugen kann.

Die Umsetzung in der SAP-Welt — intern oft als „A96-Prozess" referenziert (nach dem SAP-Transaktionscode für die AAÜZ-Erzeugung) — wird in vielen Stadtwerken als kritischster Einzelprozess im Redispatch beschrieben. Nicht wegen der technischen Komplexität der SAP-Transaktion selbst, sondern weil sie am Ende einer Datenkette steht, deren vorgelagerte Glieder nicht synchronisiert sind.

Proaktive Stammdaten-Heilung — Die Agenten-Logik

Das Timing-Problem: Warum Batch nicht reicht

Ein klassisches Master-Data-Management-System synchronisiert Datenquellen in definierten Intervallen — typischerweise einmal täglich als Nachtlauf oder wöchentlich als Batch-Abgleich. Für den Redispatch-Kontext ist das strukturell zu langsam.

Eine Redispatch-Maßnahme kann innerhalb von Minuten angewiesen und innerhalb von Stunden beendet werden. Die kaufmännische Abrechnung dieser Maßnahme muss auf Stammdaten basieren, die zum Zeitpunkt der Maßnahme aktuell waren — nicht zum Zeitpunkt des letzten Batch-Laufs. Wenn ein BTR-Wechsel am Montag wirksam wird, die Abregelung am Dienstag erfolgt und der Batch-Abgleich erst am Sonntag läuft, dann rechnet das System fünf Tage lang gegen den falschen Betreiber ab. Bei einem KWK-Werk mit 10 MW Leistung und einem Strompreis von 80 €/MWh kann die Fehlzuordnung einer einzigen achtstündigen Maßnahme einen fünfstelligen Betrag betreffen.

Der agentische Ansatz: Kontinuierlicher Abgleich statt Monatsende-Korrektur

Ein Agentic-Asset-MDM-System im Redispatch-Kontext arbeitet nach einer anderen Logik. Es wartet nicht auf den Monatsabschluss, um Fehler zu erkennen. Es traversiert die relevanten Datenquellen täglich und gleicht drei zentrale Datenschichten gegeneinander ab:

Schicht 1: Das Anlagenregister. Alle redispatch-pflichtigen Anlagen (≥ 100 kW) mit ihren aktuellen Stammdaten — MaStR-Nummer, Anlagentyp, installierte Leistung, Netzanschlusspunkt (NAP), Marktlokation (MeLo), Spannungsebene, Betriebsstatus. Die autoritative Quelle ist das MaStR, abgeglichen gegen die lokalen Daten im ERP.

Schicht 2: Die BTR-Zuordnung. Für jede Anlage muss der aktuelle Betreiber der technischen Ressource identifizierbar sein. Die relevanten Quellen sind die EDIFACT-Stammdatenmeldungen (UTILMD), das ERP-System (Vertragspartner) und das MaStR (registrierter Betreiber). Ein Agent prüft die Konsistenz dieser drei Quellen und erkennt, wenn eine Quelle von den anderen abweicht.

Schicht 3: Die Abruf-Zuordnung. Jede Redispatch-Maßnahme im Leitsystem wird gegen die kaufmännischen Stammdaten abgeglichen: Ist die abgerufene technische Ressource einer gültigen MeLo zugeordnet? Stimmt die NAP-Zuordnung? Existiert ein aktueller Planwert für die betroffene Anlage?

Wie der Agent arbeitet: Ein konkreter Prüfzyklus

Der Agent durchläuft seinen Validierungszyklus in einem festen Rhythmus — idealerweise täglich, mindestens aber vor jedem Abrechnungslauf. Jeder Zyklus prüft das gesamte redispatch-relevante Portfolio und erzeugt einen strukturierten Validierungsreport.

Das folgende Beispiel zeigt den Output eines solchen Zyklus für ein Portfolio mit 59 Anlagen und einer Gesamtleistung von 73,4 MW:

{
 "agent": "agentic-asset-mdm",
 "module": "redispatch_prevalidation",
 "cycle": "daily_0600",
 "timestamp": "2026-03-28T06:00:12Z",
 "portfolio": {
   "grid_operator": "Beispiel-VNB",
   "total_installations": 59
 },
 "validation_results": {
   "fully_consistent": 51,
   "warnings": 5,
   "critical": 3,
   "findings": [
     {
       "severity": "CRITICAL",
       "type": "MISSING_BTR_DATA",
       "mastr_id": "SEE9XXXXX482910",
       "installation_name": "PV Freiflaeche Sued",
       "capacity_kw": 2298,
       "detail": "BTR-Zuordnung im ERP abgelaufen seit 2026-02-14. MaStR zeigt neuen Betreiber. UTILMD-Meldung fehlt.",
       "impact": "AAÜZ-Erzeugung blockiert. Kein gültiger Zahlungsempfänger.",
       "days_since_inconsistency": 42,
       "recommended_action": "ESCALATE_BTR_REQUEST"
     },
     {
       "severity": "CRITICAL",
       "type": "NAP_MELO_MISMATCH",
       "nap_id": "SAN9XXXXX641336",
       "detail": "NAP versorgt 5 Erzeugungseinheiten. 4 MeLo-IDs erwartet, aber nur 3 im ERP aktiv. MeLo für Gasturbine fehlt.",
       "impact": "Abrufe an Gasturbine nicht abrechenbar.",
       "recommended_action": "RESTORE_MELO_MAPPING"
     }
   ]
 },
 "billing_readiness": {
   "ready_for_aauz": 51,
   "blocked": 3,
   "next_billing_run": "2026-04-01"
 }
}

Drei Aspekte dieses Validierungsreports sind für das Verständnis der agentischen Logik zentral:

Die Kategorie MISSING_BTR_DATA. Der Agent erkennt nicht erst am Monatsende, dass die BTR-Zuordnung für eine 2,3-MW-Anlage fehlt. Er erkennt es 42 Tage vor dem Abrechnungslauf und identifiziert die Ursache (MaStR-Update ohne korrespondierende UTILMD-Meldung). Er kann den Eskalationsprozess eigenständig anstoßen.

Die Kategorie NAP_MELO_MISMATCH. Dieses Finding zeigt ein Problem, das bei manueller Prüfung nahezu unsichtbar ist. Ein Netzanschlusspunkt versorgt fünf Erzeugungseinheiten, die über vier Marktlokationen abgerechnet werden. Wenn eine MeLo-Zuordnung verloren geht, verteilt das System die Ausfallarbeit auf die verbleibenden MeLos — mathematisch korrekt, kaufmännisch falsch. Der Agent erkennt die Diskrepanz durch den Abgleich von MaStR-NAP-Verknüpfungen.

Der zweite Agent: Tagesabgleich Abruf gegen Stammdaten

Neben dem Portfolio-Validierungsagenten arbeitet ein zweiter Agent auf der operativen Ebene: Er gleicht jede einzelne Redispatch-Maßnahme des Vortages gegen die aktuellen Stammdaten ab.

{
 "agent": "agentic-asset-mdm",
 "module": "redispatch_daily_reconciliation",
 "date": "2026-03-27",
 "reconciliation": [
   {
     "measure_id": "RD-2026-0327-002",
     "timestamp_start": "2026-03-27T14:15:00Z",
     "scada_resource": "PV_SUED_01",
     "power_reduction_kw": 1500,
     "status": "BLOCKED",
     "blocking_reason": "MISSING_BTR_DATA",
     "reference": "Portfolio finding SEE9XXXXX482910",
     "action": "Maßnahme in Quarantäne. AAÜZ-Erzeugung gesperrt bis BTR-Klärung abgeschlossen. Frist für BTR-Klärung: 2026-04-15."
   }
 ],
 "summary": {
   "matched": 2,
   "blocked": 1,
   "total_ausfallarbeit_blocked_kwh": 3375,
   "aauz_ready_with_exclusions": "1 Maßnahme in Quarantäne (PV_SUED_01). Verbleibende Maßnahmen abrechnungsfähig."
 }
}

Der entscheidende Mechanismus ist der Status BLOCKED. Der Agent lässt eine Maßnahme nicht in die AAÜZ-Erzeugung einfließen, wenn die Stammdaten-Konsistenz nicht bestätigt ist. Stattdessen wird die Maßnahme in Quarantäne gesetzt — sie wird nicht abgerechnet, nicht ignoriert und nicht manuell „zurechtgebogen". Das ist der fundamentale Unterschied zum Notfallverfahren: Der Agent verhindert, dass fehlerhafte Daten in den Abrechnungslauf gelangen.

Die Prozesskette: Von der Erkennung zur Heilung

Der agentische Ansatz im Redispatch unterscheidet drei Eskalationsstufen:

Stufe 1 — Automatische Heilung. Inkonsistenzen, die der Agent eigenständig auflösen kann (z.B. veraltete Prognoseprofile bei Anlagen-Erweiterung). Keine menschliche Interaktion erforderlich.

Stufe 2 — Angereicherte Eskalation. Inkonsistenzen, die eine menschliche Entscheidung erfordern. Beispiel: Die BTR-Zuordnung fehlt. Der Agent bereitet eine UTILMD-Anforderung vor und legt sie dem Sachbearbeiter zur Freigabe vor.

Stufe 3 — Quarantäne. Maßnahmen, die weder automatisch noch durch Eskalation rechtzeitig lösbar sind. Sie werden isoliert und aus dem regulären SAP-Lauf ausgeschlossen. Der SAP-Abrechnungslauf läuft störungsfrei für alle konsistenten Maßnahmen durch. Die Blockade des gesamten Laufes durch einen Einzelfehler ist Geschichte.

Vom Notfallverfahren zur Automatisierung

Die Ex-Post-Abrechnung im Redispatch 2.0 ist kein Randprozess. Sie ist finanziell signifikant, regulatorisch geprüft und volumetrisch wachsend. Auf nationaler Ebene wurden allein im Januar 2026 über 2.200 Redispatch-Maßnahmen mit einem Gesamtvolumen von 3,35 TWh dokumentiert — davon 83,5 % strombedingter Redispatch und 12,1 % grenzüberschreitender Countertrade. Diese Volumina sind nicht rückläufig. Sie steigen mit jedem Megawatt erneuerbarer Kapazität, das ans Netz geht.

Für den einzelnen Verteilnetzbetreiber bedeutet das: Die Anzahl der redispatch-pflichtigen Anlagen im Portfolio wächst, die Frequenz der Abrufmaßnahmen nimmt zu und die Komplexität der Stammdatenzuordnung steigt mit jeder neuen Anlage, jedem BTR-Wechsel und jeder ERP-Migration.

Das Notfallverfahren — Telefonat, Excel-Tabelle, Betriebshandbuch-Vermerk — kann in einem Portfolio von 20 Anlagen funktionieren. Es kann auch bei 40 Anlagen noch funktionieren, wenn die Personalkapazität in der Netzabrechnung entsprechend dimensioniert ist. Aber es hat drei strukturelle Grenzen, die durch mehr Personal nicht überwindbar sind.

Grenze 1: Keine präventive Wirkung. Das Notfallverfahren repariert Fehler, die bereits in der Abrechnung gelandet sind. Es verhindert nicht, dass fehlerhafte Datensätze überhaupt in den Abrechnungslauf gelangen. Jeder Fehler, der den SAP-Lauf erreicht, hat Folgekosten: manuelle Korrektur, Nachbuchung, Kommunikation mit dem Anlagenbetreiber und möglicherweise eine Korrekturnachricht an den ÜNB.

Grenze 2: Kein Audit-Trail. Eine Excel-Tabelle ist kein revisionssicheres Medium. Wenn die Bundesnetzagentur oder ein Anlagenbetreiber die Nachvollziehbarkeit einer Abrechnungskorrektur einfordert, kann der Netzbetreiber auf Zellenverweise und Tabellenblätter verweisen — aber nicht auf ein maschinenlesbares Protokoll, das Quellsysteme, Zeitstempel und Entscheidungslogik lückenlos dokumentiert.

Grenze 3: Kein Lerneffekt. Das Notfallverfahren behandelt jeden Fehler als Einzelfall. Es erkennt keine Muster. Wenn dieselbe Fehlerklasse (z. B. fehlende BTR-Daten nach Betreiberwechsel) systematisch bei einem bestimmten Anlagentyp oder in einem bestimmten Netzsegment auftritt, bleibt das unsichtbar. Der Sachbearbeiter löst das Problem jedes Mal neu, statt die Ursache zu beseitigen.

Agentic Asset-MDM als Skalierungslogik

Die agentische Methodik, wie sie in den vorherigen Abschnitten beschrieben wurde, adressiert alle drei Grenzen gleichzeitig:

Der Portfolio-Validierungsagent (täglicher Prüfzyklus) verhindert, dass inkonsistente Stammdaten den Abrechnungslauf erreichen. Er arbeitet proaktiv und erkennt Probleme Tage oder Wochen vor dem SAP-Lauf. Der Tagesabgleich-Agent (Maßnahmen-Zuordnung) stellt sicher, dass jede einzelne Redispatch-Maßnahme vollständig und konsistent den richtigen kaufmännischen Entitäten zugeordnet ist, bevor sie in die AAÜZ-Erzeugung einfließt. Und der Quarantäne-Mechanismus entkoppelt die fehlerfreien Maßnahmen von den problematischen — der SAP-Lauf wird nicht mehr durch Einzelfehler blockiert.

Das Ergebnis ist eine Prozesskette, die nicht mehr am Monatsende unter Zeitdruck manuell zusammengeklebt wird, sondern die kontinuierlich einen konsistenten, abrechnungsfähigen Datenbestand vorhält.

Die drei Optionen: Manuell, Batch, Agentisch

Wie beim Netzanschluss-Use-Case (→ Kapitel 1: Rechtssichere Netzanschlussentscheidungen) lässt sich der Reifegrad der Redispatch-Abrechnung in drei Stufen beschreiben:

Kriterium	Manuell (Notfallverfahren)	Batch-MDM (Nachtlauf)	Agentic Asset-MDM
Fehlererkennung	Erst im SAP-Lauf	Nächster Batch-Lauf (T+1 bis T+7)	Kontinuierlich (T+0)
BTR-Validierung	Per Telefonat	Report + manuelle Nacharbeit	Autonomer MaStR/UTILMD-Abgleich
NAP-MeLo-Prüfung	Nicht systematisch	Regelbasiert, aber ohne Kontext	Kontext-aware mit MaStR-NAP-Graph
Planwert-Aktualität	Unkontrolliert	Periodisch, aber ohne MaStR-Abgleich	Automatischer Kapazitäts-Profilabgleich
SAP-Lauf-Blockade	Häufig (Einzelfehler blockiert Gesamtlauf)	Reduziert	Eliminiert durch Quarantäne
Audit-Trail	Excel + Betriebshandbuch	Datenbankprotokoll	Maschinenlesbar, revisionssicher
Skalierung bei +20 Anlagen	+1 FTE	Konfigurationsaufwand	Automatisch

Build vs. Buy

Die in diesem Kapitel beschriebene Methodik ist vollständig offengelegt. Ein Verteilnetzbetreiber, der über die entsprechenden Schnittstellen verfügt — MaStR-API, SFTP-Anbindung für EDIFACT-Nachrichten, Leitsystem-Export und SAP-RFC-Konnektivität — kann die Agenten-Logik auf Basis eigener Infrastruktur implementieren. Die technische Kernkomponente ist dabei weniger die einzelne Abfrage als die Orchestrierung: der kontinuierliche, getaktete Abgleich über Systemgrenzen hinweg, die Pflege der NAP-MeLo-Zuordnungsgraphen und die Erzeugung revisionssicherer Entscheidungsobjekte.

Wer diese Orchestrierungskomplexität nicht selbst aufbauen und betreiben möchte, findet mit Cernion eine schlüsselfertige B2B-SaaS-Plattform, die genau diese Methodik operationalisiert.

Cernion bietet autonome Validierungsagenten für den Redispatch-Kontext, die sich in bestehende VNB-Systemlandschaften integrieren. Die Plattform umfasst den kontinuierlichen Abgleich von MaStR, ERP und Leitsystem, die automatische BTR-Validierung, die NAP-MeLo-Konsistenzprüfung und die Erzeugung abrechnungsfähiger Datensätze mit vollständigem Audit-Trail. Für Verteilnetzbetreiber, deren Redispatch-Portfolio über die manuelle Beherrschbarkeit hinauswächst, ist das der Weg vom Notfallverfahren zum auditierbaren Regelprozess — ohne den Aufwand einer internen Eigenentwicklung.

---

Datenquellen: Netztransparenz.de (Redispatch-Maßnahmen 2026), Marktstammdatenregister (mastr.bundesnetzagentur.de), BNetzA-Festlegungen BK6-20-059 / BK6-20-061. Abrufdatum: März 2026.

Datenquellen: Netztransparenz.de (Redispatch-Maßnahmen 2026), Marktstammdatenregister (mastr.bundesnetzagentur.de), BNetzA-Festlegungen BK6-20-059 / BK6-20-061. Abrufdatum: März 2026.