Duldungsfall

Ein Duldungsfall liegt vor, wenn der Netzbetreiber eine Redispatch-Maßnahme ohne vorherige Abstimmung mit dem Anlagenbetreiber durchführt – also direkt in die Steuerung der Anlage eingreift. Der Betreiber muss den Eingriff dulden.

Im Gegensatz zum Aufforderungsfall, bei dem der Betreiber zur Anpassung aufgefordert wird, erfolgt beim Duldungsfall der Eingriff direkt durch den Netzbetreiber. Die Unterscheidung ist relevant für die Berechnung der Ausfallarbeit und die anwendbaren Abrechnungsregeln.

Redispatch-Maßnahme, bei der der Netzbetreiber direkt in die Anlage eingreift, ohne vorherige Abstimmung mit dem Betreiber. Für Unternehmen im Strommarkt ist der Begriff vor allem deshalb relevant, weil er technische Prozesse, regulatorische Pflichten und kaufmännische Abrechnung miteinander verbindet.

Im praktischen Kontext taucht Duldungsfall häufig zusammen mit Aufforderungsfall, Redispatch, Ausfallarbeit, BK6-20-059 auf. Wer Redispatch-Fälle prüft, Entschädigungen bewertet oder Marktkommunikation automatisiert, muss diese Zusammenhänge sauber verstehen und dokumentieren.

In der täglichen Arbeit entscheidet Duldungsfall darüber, welche Daten benötigt werden, welche Marktrollen beteiligt sind und welche Nachweise im Streit- oder Prüfungsfall belastbar sein müssen. Besonders bei Redispatch 2.0 entstehen Fehler oft nicht durch eine einzelne Berechnung, sondern durch unklare Zuordnungen zwischen Stammdaten, Messwerten, Fahrplänen und regulatorischen Vorgaben.

Ein sauberer Prozess beginnt daher mit einer eindeutigen fachlichen Definition. Darauf aufbauend lassen sich Fristen, Datenquellen, Verantwortlichkeiten und Prüfschritte so strukturieren, dass Fachbereiche, Netzbetreiber, Direktvermarkter und Abrechnungsteams dieselbe Grundlage verwenden.

Für Duldungsfall sind in der Regel mehrere Datenebenen relevant: Stammdaten beschreiben die Anlage oder Marktrolle, Zeitreihen zeigen gemessene oder geplante Energiemengen, und Prozessnachrichten dokumentieren die Kommunikation zwischen den Beteiligten. Erst die Kombination dieser Informationen macht eine Abrechnung nachvollziehbar.

• Stammdaten: Zuordnung von Anlage, Marktrolle, Bilanzkreis, MaLo, MeLo, Steuerbarer Ressource oder Technischer Ressource.
• Zeitreihen: Messwerte, SCADA-Daten, Fahrpläne, Prognosen oder Ersatzwerte im passenden Zeitraster.
• Kommunikation: Anforderungen, Bestätigungen, Korrekturen und Fehlerhinweise aus der Marktkommunikation.
• Prüfung: Plausibilisierung gegen Regelwerke, historische Werte und fachliche Erwartung.

Typische Fehler entstehen, wenn Definitionen aus Regulierung, Technik und Abrechnung vermischt werden. Dann werden Maßnahmen falsch zugeordnet, Daten nicht im richtigen Zeitfenster geprüft oder Entschädigungsansprüche auf einer unvollständigen Grundlage bewertet.

• Unklare Begriffsverwendung: Fachliche Rollen, technische Ressourcen und kaufmännische Objekte werden nicht sauber getrennt.
• Fehlende Historisierung: Änderungen an Stammdaten sind nicht zum Maßnahmezeitpunkt nachvollziehbar.
• Lückenhafte Datenbasis: Messwerte, Prognosen oder Prozessnachrichten fehlen oder passen zeitlich nicht zusammen.
• Manuelle Nacharbeit: Prüfungen werden nicht reproduzierbar dokumentiert und lassen sich später schwer auditieren.

Für eine skalierbare Redispatch-Abrechnung reicht es nicht, Duldungsfall nur fachlich zu kennen. Die zugehörigen Daten müssen systematisch importiert, validiert, versioniert und in nachvollziehbare Prüfentscheidungen übersetzt werden. Genau hier entsteht der Nutzen einer spezialisierten Softwarelösung.

RedisPay unterstützt Abrechnungsteams dabei, Begriffe wie Duldungsfall nicht als isolierte Wissenseinträge zu behandeln, sondern als Teil eines durchgängigen Daten- und Prüfprozesses. Dadurch werden manuelle Klärfälle reduziert, regulatorische Anforderungen transparenter und Abrechnungsergebnisse besser begründbar.