Skip to main content

Kapitel 9: Datenarchitektur: MaStR, Lastprofile, OSM, Messpunkte und Anlagenlisten

Reviewstatus: Kontrollierter BookStack-Draft im nicht öffentlichen Buchbereich.
Einordnung: Kontrollierte Erstiteration; kein final freigegebenes Kapitel.
Freigabe: Nicht veröffentlichen oder sichtbar schalten. Vor Veröffentlichung sind Kapitelproduktion, Evidenzprüfung und Gegenprüfung erforderlich.

Kapitel 9: Datenarchitektur: MaStR, Lastprofile, OSM, Messpunkte und Anlagenlisten

Stand: 2026-07-11

Prüfentscheidung 2026-06-30

Die Seite wurde von einem reinen Platzhalter zu einem ersten fachlichen Arbeitsbaustein weiterentwickelt. Der Baustein ist als Entwurf zu lesen: Er beschreibt eine kommunale Datenarchitektur und nennt Primärquellen für MaStR-Daten, trifft aber keine abschließenden Rechts- oder Machbarkeitsaussagen.

Kernthese für das Kapitel

Ein kommunales Energie-Lagebild ist keine einzelne Tabelle. Es ist eine nachvollziehbare Beweiskette: Welche Anlagen gibt es, wem sind sie zugeordnet, wie aktuell sind die Stammdaten, welche Mess- und Lastprofile passen dazu, welche Netz- oder Marktprozesse berühren die Entscheidung und welche Zahl darf am Ende in eine Beschlussvorlage?

Für Kämmerer ist diese Beweiskette vor allem deshalb wichtig, weil Haushaltsrisiken häufig nicht aus der einen großen Rechtsänderung entstehen, sondern aus der Summe kleiner Datenunsicherheiten: unvollständige Anlagenlisten, veraltete Standortdaten, nicht abgestimmte Lastgänge, unklare Betreiberzuordnung, nicht dokumentierte Preiszeiträume oder fehlende Verantwortung für die Nachprüfung.

Mindestarchitektur eines kommunalen Energie-Datenraums

Ein pragmatischer Arbeitsstand sollte fünf Ebenen unterscheiden:

  1. Stammdatenebene: Anlagen, Einheiten, Betreiber, Standort, Energieträger, Leistung, Inbetriebnahmedatum und Status. Primärer Startpunkt ist das Marktstammdatenregister der Bundesnetzagentur.
  2. Raumebene: Gemeindegebiet, Ortsteile, Liegenschaften, Netzgebiet, Konzessionsgebiet, Flurstücke oder frei dokumentierte Suchräume. OpenStreetMap oder kommunale GIS-Daten können hier als Arbeitsquellen dienen, müssen aber gegen amtliche oder lokale Geodaten geprüft werden, bevor daraus harte Aussagen entstehen.
  3. Zeit- und Messwertebene: Lastprofile, Messpunkte, Erzeugungsprofile, Preiszeitreihen und Vergleichszeiträume. Jede Zeitreihe braucht Zeitzone, Auflösung, Datenstand und Berechnungsmethode.
  4. Prozessebene: Netzanschluss, Redispatch, Messstellenbetrieb, Bilanzierung, Beschaffung, Konzessionsabgabe, Wärmeplanung und Beteiligungssteuerung. Diese Ebene verbindet Daten mit Zuständigkeiten.
  5. Entscheidungsebene: Beschlussvorlage, Risikoampel, Investitionspfad, Prüfauftrag, Haushaltswirkung und Wiedervorlage. Hier dürfen nur geprüfte Zahlen stehen; alles andere bleibt Prüfwert.

MaStR als Startpunkt, nicht als fertige Wahrheit

Die Bundesnetzagentur beschreibt das Marktstammdatenregister als behördliches Register für Stammdaten des Strom- und Gasmarktes. Es enthält insbesondere bei Stromerzeugungsanlagen Angaben zu Energieträger, Anlagenleistung, Standort und Anlagenbetreiber. Fast alle Daten sind öffentlich zugänglich und können gefiltert, ausgewertet und heruntergeladen werden. Der MaStR-Datendownload stellt die öffentlichen Daten als XML-Gesamtauszug bereit und wird nach Angabe des MaStR in der Regel um 5:00 Uhr auf den zu diesem Zeitpunkt gültigen Datenstand aktualisiert.

Für das Buch folgt daraus eine vorsichtige Formulierung: MaStR-Daten sind eine starke Primär- und Registerquelle für Anlagenstammdaten, aber sie ersetzen nicht die lokale Prüfung. Eine Kommune sollte bei jeder Auswertung mindestens dokumentieren:

  • Abrufdatum und Datenstand des MaStR-Downloads.
  • Filterlogik: Gemeinde, Netzgebiet, Postleitzahl, Koordinatenradius oder Anlagenstandort.
  • Einbezogene Energieträger und Anlagenstatus.
  • Umgang mit Dubletten, fehlenden Koordinaten, Betreiberwechseln und unplausiblen Leistungswerten.
  • Abgleich gegen Netzbetreiber-, Stadtwerke-, Liegenschafts- oder Beschlussdaten.
  • Verantwortliche Stelle für Nachprüfung und Wiedervorlage.

MaStR-Prüfdatensatz für kommunale Beispiele

Für spätere Beispiele zu Heidelberg, Mauer, Stuttgart oder anderen Kommunen sollte Kapitel 9 nicht direkt mit Summen beginnen, sondern mit einem reproduzierbaren Prüfdatensatz. Der Prüfdatensatz ist eine Arbeitsform: Er zeigt, welche Registerdaten verwendet wurden, wo lokale Gegenprüfung fehlt und welche Zahl noch nicht in eine Haushalts- oder Beschlussaussage übernommen werden darf.

Ein minimaler MaStR-Prüfdatensatz sollte pro Auswertung folgende Felder enthalten:

Feld Zweck Draft-Regel
Abrufweg trennt MaStR-Download, MaStR-Webdienst, öffentliche Einheitenübersicht und lokale Liste URL, Abrufzeit und Export-/Datenstand nennen
Räumlicher Filter erklärt, warum eine Anlage zur Kommune oder zum Suchraum zählt Gemeindegrenze, PLZ, Koordinate, Radius oder Netzgebiet offenlegen
Einheit und Energieträger verhindert Vermischung von Anlagenarten, Speichern und Verbrauchseinrichtungen MaStR-Einheit, Energieträger, Status und Inbetriebnahme getrennt halten
Leistung und Mengenbezug trennt installierte Leistung von Erzeugungs-, Einspeise- oder Verbrauchswerten Leistung nicht als Ertrag, Einsparung oder Haushaltsnutzen formulieren
Betreiber-/Verantwortungsrolle ordnet die Wirkung Kommune, Eigenbetrieb, Stadtwerk, Dritten oder Statistik zu ohne Vertrags- oder Betreiberabgleich nur Prüfwert
Plausibilitätsabgleich hält fest, ob lokale Anlagenlisten, Netzbetreiberangaben oder Liegenschaftsdaten vorliegen fehlende Gegenquelle ausdrücklich markieren
Veröffentlichungsstatus schützt interne, personenbezogene oder vertragliche Daten öffentliche Registerdaten von internen Nachweisen trennen

Die Primärquellenprüfung vom 2026-07-07 bestätigt nur den Register- und Downloadcharakter: Die Bundesnetzagentur beschreibt das MaStR als behördliches Register für Stammdaten des Strom- und Gasmarktes; der MaStR-Datendownload stellt öffentliche Daten als XML-Gesamtauszug bereit und wird in der Regel um 5:00 Uhr aktualisiert. Daraus folgt keine lokale Haushaltswirkung. Für jede spätere Beispielrechnung bleiben Lastgänge, Messkonzept, Preis- oder Vertragsbezug, Betreiberrolle und lokale Gegenquelle erforderlich.

Datenqualitätsfragen für die Beschlussvorlage

Bevor ein Lagebild in eine kommunale Entscheidungsvorlage wandert, sollte die Verwaltung nicht nur nach dem Ergebnis fragen, sondern nach der Belastbarkeit des Ergebnisses:

  • Welche Zahl stammt direkt aus einem Register, welche aus einer Berechnung und welche aus einer Annahme?
  • Ist die Zahl kommunal abgegrenzt, netzgebietsscharf oder nur näherungsweise räumlich gefiltert?
  • Wie alt ist der Datenstand, und welche Veränderung wäre entscheidungsrelevant?
  • Wurde die Anlagenliste gegen lokale Kenntnisse geprüft?
  • Gibt es Anlagen, die technisch vorhanden, aber politisch oder haushalterisch nicht nutzbar sind?
  • Welche Daten dürfen veröffentlicht werden, welche gehören nur in interne Anlagen?
  • Welche Unsicherheit muss im Beschluss ausdrücklich genannt werden?

Datenkette für Konzessionsabgabe und Gasabsatz

Für Kapitel 2 und Kapitel 7 braucht das Buch eine eigene Datenkette, weil Konzessionsabgabe, Gasabsatz, Wärmeplanung und Beteiligungswirkung sonst zu schnell vermischt werden. Die belastbare Kette beginnt nicht mit einer Prognose, sondern mit getrennten Nachweisen:

  1. Rechts- und Vertragsanker: Wegenutzungsvertrag, Konzessionsvertrag, EnWG § 46, EnWG § 48 und KAV § 2.
  2. Mengenanker: gelieferte Kilowattstunden nach Strom/Gas, Tarifkunden, Sondervertragskunden, Schwachlast- oder Sonderregeln und Abrechnungsjahr.
  3. Gebietsanker: Gemeindegebiet, Netzgebiet, Konzessionsgebiet, Ortsteile und betroffene kommunale Liegenschaften.
  4. Transformationsanker: Wärmeplan, Gasnetzstrategie, Wasserstoff- oder Stilllegungspfad, Anschlussgruppen und Zeitfenster.
  5. Finanzanker: bisherige Konzessionsabgabe, erwartete Mengenänderung, Beteiligungsergebnis, Restbuchwerte, Investitionsbedarf und Sozial-/Übergangsrisiken.

Die Datenarchitektur muss dabei zwei Fehler vermeiden. Erstens darf ein sinkender Gasabsatz nicht automatisch als bezifferter Haushaltsausfall dargestellt werden, solange Vertrag, Liefermengen, Kundengruppen und Abrechnung fehlen. Zweitens darf lokale Erzeugung nicht als Ersatz für Konzessionsabgabe formuliert werden; sie liegt auf einer anderen Wirkungsebene.

Für Beschlussvorlagen empfiehlt sich ein Prüfdatensatz mit folgenden Mindestfeldern:

Feld Warum es benötigt wird Status vor Freigabe
Konzessionsvertrag und Laufzeit klärt Rechtsbezug, Vertragspartner, Abrechnungslogik und Fristen lokale Vertragsquelle erforderlich
Liefermenge Strom/Gas nach Kundengruppe trennt Tarifkunden, Sondervertragskunden und Sonderregeln Abrechnung oder Netz-/Lieferantenangabe erforderlich
KAV-/EnWG-Prüfanker begrenzt die Aussage auf Höchstbeträge, Wegenutzung und Zahlungspflicht Primärquelle vor Veröffentlichung erneut prüfen
Wärmeplan-/Gasnetzpfad ordnet Mengenänderung in Transformationsszenario ein lokale Wärmeplan- und Netzbetreiberquelle erforderlich
Haushalts- und Beteiligungswirkung trennt Kernhaushalt, Stadtwerk, Netzgesellschaft und Dritte Haushalts-/Beteiligungsdaten erforderlich

Diese Ergänzung ist ein Prüfstand, keine Rechtsberatung und keine lokale Haushaltsprognose. Cernion Energy Tools können später als Arbeitswerkzeug helfen, Datenstände, Lagebildketten oder Nachweisstatus zu strukturieren; sie ersetzen weder Primärrecht noch Konzessionsvertrag, Abrechnung, Wärmeplan oder Netzbetreiberangaben.

Cernion-/CET-Einordnung für diese Seite

Cernion Energy Tools wurden in dieser Iteration nur als sachliche Arbeits- und Evidenzquelle betrachtet, nicht als Werbe- oder Produktargument. Die Cernion-Abfrage vom 2026-06-30 lieferte für die sehr breite Frage nach Kapitel-9-Prüfpfaden nur indirekte Treffer und wurde deshalb mit niedriger Evidenzsicherheit eingeordnet. Verwertbar sind daraus lediglich allgemeine Hinweise auf Datenqualitäts- und Prozesssicht: Evidenzfrische, Messwesen, Redispatch-/Netzprozess-Kontext und der Datapoint redispatch-hd als möglicher späterer Rechercheanker.

Für den Kapiteltext bedeutet das: Cernion kann helfen, Prüffragen, Datenqualitätsgates und kommunale Lagebildlogik zu strukturieren. Harte Aussagen zu Rechtspflichten, lokalen Netzkapazitäten, Redispatch-Betroffenheit oder finanziellen Effekten müssen weiterhin aus Primärquellen, lokalen Dokumenten oder ausdrücklich dokumentierten Auswertungen kommen.

Quellenstand 2026-07-05

Primär geprüft:

  • Bundesnetzagentur: Marktstammdatenregister, https://www.bundesnetzagentur.de/DE/Fachthemen/ElektrizitaetundGas/Monitoringberichte/Marktstammdatenregister/start.html?r=1
  • Marktstammdatenregister: Datendownload, https://www.marktstammdatenregister.de/MaStR/Datendownload
  • Energiewirtschaftsgesetz, § 46 EnWG, Wegenutzungsverträge: https://www.gesetze-im-internet.de/enwg_2005/__46.html
  • Energiewirtschaftsgesetz, § 48 EnWG, Konzessionsabgaben: https://www.gesetze-im-internet.de/enwg_2005/__48.html
  • Konzessionsabgabenverordnung, § 2 KAV, Bemessung und zulässige Höhe: https://www.gesetze-im-internet.de/kav/__2.html

Arbeits-/Kontextevidenz:

  • Cernion-Abfrage vom 2026-06-30 zu Kapitel-9-Datenarchitektur: niedrige Evidenzsicherheit, nur als Hinweis auf mögliche Prüfpfade verwendbar.

Produktionsstatus

  • Status: kontrollierter Erstbaustein, noch kein finales Kapitel.
  • Nächster Schritt: kommunale Beispielauswertung definieren, vorzugsweise eine kleine MaStR- oder Konzessionsabgaben-Prüfkette mit dokumentiertem Datenstand und klarer Abgrenzung zwischen Registerwert, Vertrags-/Abrechnungswert, Prüfwert und lokaler Bestätigung.
  • Sichtbarkeit: unverändert; keine Veröffentlichung und keine Sichtbarkeitsänderung.

Änderungsnotiz

  • 2026-06-29: Seite als Teil der vollständigen Draft-Struktur für Arbeitsstrang 5 angelegt.
  • 2026-06-30: Erste kontrollierte Inhaltsiteration ergänzt: Datenarchitektur, MaStR-Prüflogik, Datenqualitätsfragen und Cernion/CET-Einordnung als Arbeitsquelle.
  • 2026-07-05: Datenkette für Konzessionsabgabe und Gasabsatz ergänzt; EnWG § 46, EnWG § 48 und KAV § 2 als Primärquellenanker aufgenommen; lokale Haushaltswirkung bleibt Prüfstand bis Vertrags-, Abrechnungs-, Wärmeplan- und Netzbetreiberquellen vorliegen.
  • 2026-07-07: MaStR-Prüfdatensatz für kommunale Beispiele ergänzt; Primärquellenprüfung auf BNetzA-MaStR und MaStR-Datendownload beschränkt; lokale Haushalts-, Lastgang-, Betreiber- und Vertragswirkung bleibt Prüfstand.

Datenqualitaets-Gate 2026-07-09: Register, Zeitreihe, Messpunkt

Fuer kommunale Lagebilder sollte Kapitel 9 jede Datenquelle nach ihrer Rolle in der Beweiskette trennen. Das Marktstammdatenregister ist ein Stammdatenanker fuer Anlagen, Betreiber, Leistung, Standortbezug und Status. Es ersetzt aber nicht den lokalen Messwert, nicht den Vertrag, nicht die Netzbetreiberantwort und nicht die Haushaltsbewertung. Ein belastbares Arbeitsblatt sollte deshalb mindestens vier Spaltenfamilien fuehren: Registerbezug, Zeitreihenbezug, lokaler Messpunktbezug und Entscheidungsstatus.

Das Register-Gate beginnt mit der MaStR-Nummer der Einheit, dem Energietraeger, der Leistung, dem Standortbezug, dem Betriebsstatus, dem Datum der letzten Aktualisierung und dem Hinweis, ob eine Netzbetreiberpruefung oder ein anderer Plausibilitaetsvermerk vorliegt. Fuer kommunale Zwecke reicht ein Treffer im Register nicht aus. Entscheidend ist, ob der Treffer zur Liegenschaft, zum Betreiber, zum Netzanschlusspunkt und zum betrachteten Zeitraum passt.

Das Zeitreihen-Gate trennt bundesweite Markt- oder Systemdaten von lokalen Verbrauchs- und Erzeugungsdaten. SMARD- oder andere Marktdaten koennen einen Preis-, Verbrauchs- oder Erzeugungskontext liefern. Sie duerfen aber nicht als lokaler Haushaltsnachweis behandelt werden, solange Lastgang, Zaehler, Liefervertrag, Bilanzierungslogik und Abrechnungsperiode der Kommune fehlen. Jede Zeitreihe braucht deshalb Metadaten zu Quelle, Zeitauflosung, Zeitzone, Zeitraum, Datenluecken, Abrufdatum und Umrechnung.

Das Messpunkt-Gate ist der kommunale Realitaetstest. Eine Anlage oder ein Verbrauchsort wird erst dann beschlussfaehig, wenn Registerdatensatz, Liegenschaftsnummer, Zaehler- beziehungsweise Messlokation, Netzanschlusspunkt, Betreiberrolle und Vertragsrolle zusammenpassen. Wo diese Zuordnung fehlt, sollte die Vorlage nicht von Einsparung, Erloes, Autarkie oder Entlastung sprechen, sondern nur von einem Pruefstand.

OSM- und Geodaten koennen als raeumliche Orientierung helfen, etwa fuer Leitungsnaehe, Dachflaechenhypothesen oder sichtbare Infrastruktur. Sie sind aber kein Kapazitaetsnachweis, keine Netzvertraeglichkeitspruefung und kein vollstaendiges Anlagenregister. Im Kapitel sollten OSM-Daten deshalb nur als Hypothesenebene erscheinen und immer gegen amtliche Register, Betreiberangaben oder lokale Bestandsdaten abgesichert werden.

Primaer-/Behoerdenanker fuer die Gegenpruefung: Bundesnetzagentur-Seite zum Marktstammdatenregister, MaStRV insbesondere §§ 10, 13 und 15, oeffentliche MaStR-Einheitenuebersichten und SMARD-Datennutzung. Diese Quellen belegen die Rolle von Register-, Pruef- und Marktdaten, ersetzen aber keine kommunalen Mess- und Vertragsdaten.

Cernion-Einordnung: Cernion Energy Tools wurden am 2026-07-09 read-only als Evidenz- und Recherchekontext angefragt. Knowledge RAG lieferte wegen Autorisierungs-/Tokenproblem keine verwertbare primaerquellengestuetzte Evidence; der Evidence Router fand keinen passenden read-only Endpoint fuer kommunale Datenarchitektur. Es wurden keine Cernion-Zahlen, Rechts-, Frist-, Rollen-, Zuständigkeits- oder Erloesaussagen uebernommen.

Register-Messpunkt-Abgleich 2026-07-11: keine Zahl ohne Gegenstück

Für die spätere Beispielauswertung braucht Kapitel 9 eine klare Sperre zwischen Registerfund und kommunaler Beschlusszahl. Ein Treffer im Marktstammdatenregister beantwortet zunächst nur die Stammdatenfrage: Welche Einheit oder Anlage ist mit welchem Datenstand, Standortbezug, Status und Betreiberbezug registriert? Er beantwortet noch nicht, ob diese Einheit zur betrachteten kommunalen Liegenschaft, zum richtigen Zählpunkt, zur richtigen Betreiberrolle, zum richtigen Vertrag und zur richtigen Haushaltsstelle gehört.

Der Abgleich sollte deshalb als Paarprüfung aufgebaut werden. Jede Registerzeile bekommt ein lokales Gegenstück; fehlt dieses Gegenstück, bleibt die Zeile im Status Prüfwert:

Registerfeld Lokales Gegenstück Abbruchpunkt für Beschlusszahlen
MaStR-Nummer der Einheit oder Anlage Liegenschaftsnummer, Standortakte oder technische Bestandsliste kein Bezug zur kommunalen Zuständigkeit
Energieträger, Leistung und Status Inbetriebnahmeunterlage, Betreiberbestätigung oder Anlagenakte keine belastbare Leistungs- oder Betriebsannahme
Standortangabe oder Koordinate Flurstück, Gebäude, Netzanschlusspunkt oder GIS-Prüfung räumlicher Treffer bleibt nur Suchhypothese
Betreiber- oder Marktakteursbezug kommunale Rolle: Eigentümer, Betreiber, Mieter, Dienstleister, Stadtwerk oder Dritter keine Haushalts- oder Vertragswirkung ableiten
Datenstand und Netzbetreiberprüfung Abrufprotokoll, Netzbetreiber-/MSB-Antwort, Änderungsdatum keine Aktualitäts- oder Plausibilitätsaussage treffen
Zeitreihen- oder Messwertbezug Zählpunkt, Messlokation, Lastgangzeitraum, Zeitzone, Abrechnung keine Verbrauchs-, Einspar-, Erlös- oder Reststromzahl verwenden

Damit wird die spätere Rechenlogik einfacher: Erst wenn Registerfund, lokaler Messpunkt, Betreiberrolle und Vertrags-/Haushaltsbezug zusammenpassen, darf eine Zahl in ein Rechenbeispiel wandern. Vorher bleibt sie ein Datenfund mit Prüfauftrag. Diese Formulierung ist keine Rechtsbewertung und keine Aussage zur Vollständigkeit einzelner Registerdaten; sie beschreibt nur die redaktionelle Mindestlogik für das Buch.

Primär-/Behördenanker: MaStRV bei Gesetze im Internet, insbesondere § 13 zur Überprüfung gespeicherter Daten durch Netzbetreiber und § 15 zur öffentlichen Zugänglichkeit der Daten, außerdem der MaStR-Datendownload und der SMARD-Downloadbereich. Die früher verwendeten Einzel-URLs mit Pfad mastrv_2017 lieferten am 2026-07-11 HTTP 404; der gültige Gesetze-im-Internet-Anker ist https://www.gesetze-im-internet.de/mastrv/ beziehungsweise die konsolidierte HTML-Fassung https://www.gesetze-im-internet.de/mastrv/BJNR084210017.html.

Cernion-Einordnung: Cernion Energy Tools wurden am 2026-07-11 read-only als sachlicher Evidenzkontext geprüft. Der Evidence Router fand keinen passenden read-only Endpunkt für kommunale MaStR-Asset-Tabellen, lokale Messpunkt-/Lastgangdaten, Netzbetreiber-/MSB-Antworten oder kommunale Gegenquellen. Die Knowledge-RAG-Abfrage lieferte nur allgemeine beziehungsweise nicht ausreichend primärquellengestützte Hinweise; daher wurden keine Cernion-Zahlen, Rechts-, Frist-, Rollen-, Zuständigkeits- oder Erlösaussagen übernommen.

  • 2026-07-11: Register-Messpunkt-Abgleich ergänzt; MaStRV-Anker korrigiert; Cernion Evidence Router und Knowledge RAG nur als negative beziehungsweise schwache Evidenzprüfung dokumentiert. Keine Veröffentlichung, keine Sichtbarkeits- oder Berechtigungsänderung.