Zeitliche Gültigkeit von Stammdaten im Energiemarkt

Kurzantwort

Stammdaten gelten im Energiemarkt nicht einfach ab dem Zeitpunkt, an dem eine Nachricht verschickt oder in einem System gespeichert wird. Mindestens vier Zeitangaben müssen auseinandergehalten werden: der Zeitpunkt des Geschäftsvorfalls oder der Übermittlung, das Änderungsdatum (wann eine Information in der Marktkommunikation verwendet werden soll), der Gültigkeitsbeginn (für welchen fachlichen Zeitraum sie gilt) und die Version beziehungsweise Korrektur einer bereits übermittelten Datenreihe.

Das UTILMD-Anwendungshandbuch zur Stammdatenänderung beschreibt, dass Stammdaten innerhalb einer Segmentgruppe ab dem Datum „Änderung zum“ vollständig und gemeinsam gelten. Der Verantwortliche übermittelt die Änderung unverzüglich an den Verteiler; der Netzbetreiber hat dabei regelmäßig die Verteilerfunktion. Eine Änderung kann – abhängig vom Stammdatum und dem konkreten Anwendungsfall – auch rückwirkend gelten. Daraus folgt aber nicht, dass jedes Datum beliebig rückdatiert werden darf.

Für die Praxis ist die entscheidende Frage daher nicht nur „Welcher Wert ist aktuell?“, sondern: Welcher Wert war an dieser Marktlokation oder Messlokation zu welchem Zeitpunkt und in welcher bestätigten Version gültig? Ohne diese Zeitachse entstehen falsche Lieferantenabgrenzungen, fehlerhafte Bilanzierung und nicht reproduzierbare SAP-IS-U-Abrechnungen.

Die fünf Zeitbegriffe einer Stammdatenänderung

Der Ereigniszeitpunkt ist der Zeitpunkt, an dem sich die Realität ändert oder die Änderung bekannt wird: etwa der Einbau eines neuen Zählers, eine Änderung der Messlokationsstruktur oder die Festlegung eines neuen Bilanzierungsbeginns. Dieses Datum kann vor oder nach der Übermittlung liegen. Ein verspätet bekannt gewordener Zählerwechsel ist deshalb nicht automatisch ein verspäteter Zählerwechsel.

Der Transaktionszeitpunkt bezeichnet die technische Handlung: eine UTILMD-Nachricht wird erstellt, versendet, empfangen oder verarbeitet. Ein Empfänger kann eine Nachricht am 12. Mai erhalten, obwohl die darin beschriebene Stammdatenänderung ab dem 1. Mai gelten soll. Empfangszeit, Verarbeitungszeit und fachlicher Stichtag gehören in Protokollen getrennt gespeichert.

Das Änderungsdatum („Änderung zum“) ist der Zeitpunkt, ab dem die geänderten Stammdaten in der Marktkommunikation zu verwenden sind. In den Anwendungshandbüchern wird es über die entsprechende DTM-Angabe ausgedrückt; bei UTILMD ist dies typischerweise das Datum mit dem Qualifier für „Änderung zum“. Für ein bereits bestehendes Vertrags- oder Zuordnungsverhältnis ist dieses Datum regelmäßig der Beginn der neuen Datenversion.

Der Gültigkeitsbeginn beschreibt den fachlichen Zeitraum, in dem ein Wert gilt. Bei Zuordnungen können Beginn und Ende der Zuordnung eigene Datumsangaben sein. Bei einem zukünftigen Berechtigten können Änderungsdatum und Gültigkeitszeitpunkt auseinanderfallen: Der Empfänger wird heute informiert, darf die Daten aber erst ab dem späteren Zuordnungsbeginn anwenden.

Die Version ist die nachvollziehbare Fassung eines Stammdatensatzes. Version 1 kann zunächst einen vorläufigen oder später als falsch erkannten Wert enthalten; Version 2 kann ihn mit gleichem fachlichem Stichtag korrigieren. Die Version ist keine zusätzliche Gültigkeitsperiode. Zwei Versionen können denselben Zeitraum betreffen, aber nur eine darf für die jeweilige fachliche Auswertung als gültig markiert sein.

Änderungsdatum ist nicht gleich Übermittlungsdatum

Der Verantwortliche eines Stammdatums muss die Änderung nach Bekanntwerden unverzüglich und innerhalb der geltenden Prozessregeln mitteilen. Das macht den Übermittlungszeitpunkt jedoch nicht zum Gültigkeitsbeginn. Ein Netzbetreiber kann beispielsweise am 10. Juni eine am 1. Juni wirksam gewordene Änderung an einen berechtigten Lieferanten übermitteln. Der Empfänger muss die fachliche Gültigkeit abbilden, zugleich aber dokumentieren, wann die Information eingegangen und verarbeitet wurde.

Diese Unterscheidung ist besonders wichtig bei der Abgrenzung von Lieferbeginn und Lieferende. Ein Lieferant, der die Stammdaten einer Marktlokation erst später erhält, darf daraus nicht automatisch eine andere Zuordnung für die Vergangenheit ableiten. Maßgeblich sind der konkrete GPKE- oder WiM-Prozess, die bestätigten Termine und die Rolle des jeweiligen Marktpartners. Eine technische Nachricht kann einen früheren Stichtag mitteilen; sie ersetzt weder eine erforderliche Bestätigung noch eröffnet sie eine allgemeine Rückwirkungsmöglichkeit.

Für die Datenverarbeitung bedeutet das: received_at, processed_at und valid_from dürfen nicht in ein einziges Datum zusammenfallen. Ein System, das beim Eingang pauschal valid_from = received_at setzt, kann historische Abrechnungsperioden verschieben. Ein System, das dagegen nur den Stichtag speichert, verliert den Nachweis, ob eine Marktfristenverletzung oder eine verspätete interne Verarbeitung vorlag.

Rückwirkende Änderungen: möglich, aber nicht grenzenlos

Das UTILMD-AHB unterscheidet Stammdatenänderungen, die zu einem in der Meldung genannten Datum – gegebenenfalls rückwirkend – Gültigkeit erlangen, von Änderungen, die erst zu einem festen zukünftigen Zeitpunkt wirksam werden. Nicht bilanzierungsrelevante Daten können in dafür vorgesehenen Anwendungsfällen rückwirkend korrigiert werden. Bilanzierungsrelevante Daten und Zuordnungen haben dagegen häufig strengere Prozessbedingungen, weil sie bereits in Abrechnung und Bilanzkreisführung eingeflossen sein können.

Rückwirkend bedeutet dabei nicht „beliebig bis zum Entstehungszeitpunkt des Problems“. Entscheidend sind der fachliche Anwendungsfall, die zulässigen Fristen und die Antwort des verantwortlichen Marktpartners. Auch ein rückwirkend übermittelter Wert muss den korrekten Gesamtbestand der betroffenen Segmentgruppe zum Änderungsdatum enthalten. Das AHB verlangt gerade nicht nur das einzelne geänderte Feld: Die zu diesem Zeitpunkt gültigen Stammdaten der Segmentgruppe sind als zusammengehöriges Datenpaket zu übermitteln.

Ein Storno auf eine Stammdatenänderung ist im beschriebenen UTILMD-Prozess nicht das normale Korrekturmittel. Ist eine Änderung falsch, wird eine erneute Stammdatenänderung mit dem fachlich korrekten Inhalt versendet. Intern sollte trotzdem eine Korrekturbeziehung zwischen alter und neuer Version bestehen. So bleibt sichtbar, was ursprünglich gemeldet wurde, warum es ersetzt wurde und welche abhängigen Prozesse erneut zu rechnen sind.

Zukunftsdaten und mehrere Stichtage

Viele Stammdaten ändern sich nicht sofort, sondern zu einem angekündigten Termin: ein neuer Messstellenbetreiber übernimmt ab dem Monatswechsel, ein Bilanzierungsverfahren beginnt zu einem bestimmten Tag oder ein Messkonzept wird nach Umbau aktiv. Marktpartner können die Information bereits vorher erhalten. Der Datensatz braucht dann einen geplanten Gültigkeitsbeginn, der größer als der Eingangszeitpunkt ist.

Ändern sich mehrere abhängige Informationen zu unterschiedlichen Terminen, darf nicht alles in eine einzige Meldung mit einem scheinbar einheitlichen Stichtag gepackt werden. Das AHB weist darauf hin, dass bei unterschiedlichen Inkraftsetzungsterminen mehrere Vorgänge zu bilden sind. Ein neuer Zähler kann beispielsweise am 1. August eingebaut werden, während ein nachgelagerter Messdienst erst am 15. August beginnt. Die Fachlogik muss beide Perioden abbilden und darf die spätere Änderung nicht vorziehen.

Auch ein zukünftiger Berechtigter ist ein typischer Fallstrick. Er kann schon heute über einen geänderten Wert informiert werden, erhält ihn aber möglicherweise erst ab seiner Zuordnung zum Mess- oder Zählpunkt. Änderungsdatum und Zuordnungsbeginn sind dann zwei verschiedene Sachverhalte. Die Antwort- und Bestandslogik muss den Empfängerstatus zum jeweiligen Zeitpunkt berücksichtigen.

Stammdaten, Messwerte und Bilanzierung

Stammdaten beschreiben den Kontext, Messwerte beschreiben die gemessene oder ersatzweise ermittelte Menge. Ein geänderter Wandlerfaktor, eine neue OBIS-Kennzahl oder eine andere Messrichtung kann deshalb die Interpretation bereits vorhandener Messwerte verändern. Der Messwert selbst wird dadurch nicht automatisch neu gemessen. Für die Auswertung muss geklärt werden, welche Stammdatenversion zum Intervall gültig war.

In WiM-Prozessen werden technische Messstellen- und Messwertinformationen zwischen den berechtigten Rollen ausgetauscht. MaBiS verwendet Stammdaten und Zuordnungen, um bilanzierungsrelevante Zeitreihen korrekt zu aggregieren. Die aktuelle BNetzA-Dokumentation führt jeweils die gültigen Fassungen und Übergänge; sie sind gegenüber älteren AHB-Versionen maßgeblich. Die Änderung der Marktkommunikationsversion (zum Beispiel eine neue UTILMD-MIG) ist wiederum von der fachlichen Stammdatenversion einer MaLo zu unterscheiden.

Bei der Zuordnungsliste gilt praktisch: Änderungen sollen zuvor über den dafür vorgesehenen Änderungsprozess kommuniziert und bestätigt sein. Die Liste bezieht sich auf einen Bezugsmonat, kann aber tatsächliche Beginn- und Endtermine außerhalb dieses Monats enthalten. Deshalb ist „Bezugsmonat“ kein Ersatz für den fachlichen Gültigkeitszeitraum.

SAP IS-U: Zeitabhängige Stammdaten sauber modellieren

In SAP IS-U liegen Stammdaten in zeitabhängigen Objekten und Anlagenkonfigurationen; Marktkommunikation und EDM ergänzen diese um Nachrichten-, Mess- und Zeitreiheninformationen. Die konkrete Tabellen- und Customizing-Ausprägung hängt von Release und Systemarchitektur ab. Fachlich sollte jede Änderung jedoch mindestens folgende Informationen tragen: Objekt (MaLo, MeLo, Zählwerk oder Vertrag), Attribut, alter Wert, neuer Wert, valid_from, optional valid_to, Empfangs- und Verarbeitungszeit, Quelle, Prüfstatus und Korrekturbezug.

Eine belastbare Verarbeitung folgt dieser Reihenfolge:

1. Die Nachricht wird syntaktisch und semantisch geprüft, ohne historische Daten sofort zu überschreiben.
2. Identität, Verantwortlicher, Änderungsdatum und betroffene Segmentgruppe werden ermittelt.
3. Der vollständige Datenbestand zum Stichtag wird als neue fachliche Version gespeichert.
4. Die Version wird erst nach Bestätigung für die betroffenen Rollen und Folgeprozesse aktiviert.
5. Messwerte, Abgrenzungen, Abrechnung und MaBiS-Aggregate werden nur für die tatsächlich betroffene Periode neu bewertet.

Eine einfache „Update current value“-Logik ist riskant. Sie zerstört die Antwort auf die Frage, welcher Wandlerfaktor am 3. Mai galt. Ebenso riskant ist das unkontrollierte Nebeneinander zweier aktiver Versionen. Das System braucht eine Eindeutigkeitsregel: Für ein Objekt, Attribut und Intervall darf genau eine Version fachlich aktiv sein; Vorgänger und Korrekturen bleiben revisionssicher nachvollziehbar.

Praxisbeispiel: Zählerwechsel mit verspäteter Nachricht

An einer Messlokation wird am 4. Mai ein Zähler ausgebaut und ein neuer eingebaut. Der Netzbetreiber übermittelt die geänderte Zählwerks- und Messgeräteinformation am 7. Mai. In der UTILMD-Nachricht steht als „Änderung zum“ der 4. Mai. Der Empfänger muss die neue Stammdatenversion also ab dem 4. Mai führen, darf aber den Empfang am 7. Mai nicht vergessen.

Für Messwerte bis einschließlich 3. Mai gilt die alte Geräte- und Zählwerkszuordnung. Der Ausbauwert des alten Zählers und der Einbauwert des neuen Zählers bilden die Abgrenzung; Werte ab dem 4. Mai werden dem neuen Gerät zugeordnet. Falls am 8. Mai eine Korrektur eintrifft, die den Wandlerfaktor zum 4. Mai berichtigt, wird nicht einfach der aktuelle Faktor ersetzt. Die betroffenen Messwerte und Abrechnungen werden gegen die neue Version geprüft und, falls erforderlich, gezielt neu berechnet.

Wäre der Zählerwechsel erst für den 1. Juni angekündigt, dürfte die Datenbank die neue Version bereits als geplant speichern, aber bis zum 31. Mai weiterhin die alte Version aktiv anwenden. Eine Vorabinformation ist keine vorgezogene Wirksamkeit.

Typische Missverständnisse

• „Das Empfangsdatum ist der Gültigkeitsbeginn.“ Nein. Empfang und fachlicher Stichtag müssen getrennt gespeichert werden.
• „Rückwirkend heißt, jedes beliebige Datum ist zulässig.“ Nein. Rückwirkung hängt vom Anwendungsfall, Stammdatentyp, Prozess und den geltenden Fristen ab.
• „Eine Korrektur wird durch Storno der alten UTILMD erledigt.“ Für Stammdatenänderungen ist regelmäßig eine neue korrekte Änderungsmeldung vorgesehen; intern sollte sie auf die ersetzte Version verweisen.
• „Nur das geänderte Feld muss übertragen werden.“ Nein. Die betroffene Segmentgruppe ist zum Änderungsdatum als konsistentes Datenpaket zu betrachten.
• „Eine neue Nachrichten-MIG ist eine neue MaLo-Stammdatenversion.“ Nein. Formatversion und fachliche Datenversion sind unabhängige Achsen.
• „Zukünftige Stammdaten gelten sofort.“ Nein. Eine Vorabkommunikation kann nötig sein; angewendet werden sie erst ab dem gültigen Stichtag.
• „Der Bezugsmonat der Zuordnungsliste ist der Änderungszeitraum.“ Nein. Der Bezugsmonat strukturiert die Liste, ersetzt aber nicht Beginn und Ende der Zuordnung.
• „Nach Bestätigung darf die alte Version gelöscht werden.“ Nein. Für Audit, Korrekturen und reproduzierbare Abrechnung müssen Vorgänger und Verarbeitungsnachweise erhalten bleiben.

Quellen und Pflegehinweis

Dieser Artikel orientiert sich an den von der Bundesnetzagentur veröffentlichten Prozess- und Formatunterlagen zu GPKE, WiM und MaBiS sowie am UTILMD-Anwendungshandbuch zur Stammdatenänderung. Geprüfter Stand ist der 8. September 2026. Für eine konkrete Umsetzung sind immer die auf der BNetzA-Seite als aktuell ausgewiesene Festlegung, das zugehörige AHB, die Nachrichtentypbeschreibung, Codelisten und die gültigen Anwendungshilfen gemeinsam zu lesen.

Besonders prüfbedürftig sind Änderungs- und Umstellungstermine, Regeln für rückwirkende Einzüge und Korrekturen, die Verantwortlichkeit einzelner Stammdaten, die Behandlung bilanzierungsrelevanter Attribute sowie die Formatversionen. Bei einer Revision des Marktprozesses müssen nicht nur Frontend-Nachrichten, sondern auch Zeitintervalle in IS-U/EDM, Abgrenzungen, Folgeabrechnungen und die revisionssichere Historie getestet werden. Technische Annahme, fachliche Bestätigung und abrechnungsrelevante Aktivierung bleiben getrennte Zustände.