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

Reviewstatus: Kontrollierter BookStack-Draft im nicht öffentlichen Buchbereich.
Einordnung: Vollständige Kapitel-Erstfassung für die redaktionelle Gegenprüfung. Kein Rechtsgutachten, keine Wirtschaftlichkeitsrechnung und keine kommunale Entscheidungsvorlage.
Stand der Quellenprüfung: 2026-07-12
BookStack Page ID: 322
Freigabe: Vor Veröffentlichung sind lokale Messpunkt-, Anlagen-, Liegenschafts-, Vertrags-, Netzbetreiber-, Messstellenbetreiber-, Datenschutz- und Haushaltsprüfungen erforderlich.

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

Warum Datenarchitektur eine Haushaltsfrage ist

Kommunale Energieentscheidungen scheitern selten daran, dass es gar keine Daten gibt. Sie scheitern daran, dass Daten aus unterschiedlichen Systemen ungeprüft nebeneinanderliegen: eine Gebäudeliste aus dem Liegenschaftsamt, Stromrechnungen aus der Kämmerei, ein MaStR-Export aus dem Internet, Lastgänge vom Messstellenbetreiber, Dachflächen aus einem GIS, eine PV-Potenzialkarte, Preisblätter des Netzbetreibers, ein Wärmeplan, OSM-Geometrien, Betreiberangaben, Excel-Listen aus früheren Projekten und Präsentationszahlen aus Beratungsaufträgen.

Für die Kämmerei ist das kein technisches Ordnungsproblem. Es ist die Grundlage der Entscheidungsreife. Eine Kommune kann nur dann Investitionen, Beschaffungsstrategien, Betreiberrollen und Beschlussvorlagen sauber bewerten, wenn sie weiß, welche Zahl welchen Gegenstand beschreibt, aus welcher Quelle sie stammt, welchen Zeitraum sie abdeckt, wer sie verantwortet und ob sie für die jeweilige Entscheidung überhaupt zulässig ist.

Die zentrale These dieses Kapitels lautet:

Eine kommunale Energiedatenarchitektur muss nicht möglichst viele Daten sammeln, sondern jede entscheidungsrelevante Aussage auf Objekt, Messpunkt, Zeitraum, Rolle, Quelle, Qualität und Haushaltswirkung zurückführen.

Das klingt nüchtern. Es verhindert aber die häufigsten Fehlentscheidungen. Installierte Leistung wird nicht mit Erzeugung verwechselt. Jahresverbrauch wird nicht als Lastgang gelesen. OSM-Gebäude werden nicht als amtliches Liegenschaftsinventar behandelt. Ein MaStR-Fund wird nicht automatisch zur kommunalen Anlage. Eine Standardlastprofilkurve wird nicht als gemessener Betrieb interpretiert. Ein Spotpreis wird nicht als kommunaler Rechnungspreis angesetzt. Eine Liste der Zählernummern wird nicht mit Marktlokationen, Messlokationen und Kostenstellen vermischt.

Kapitel 9 ist deshalb das Verbindungskapitel zwischen den fachlichen Themen dieses Buches. Kapitel 3 braucht es für Stromverbrauch und lokale Erzeugung. Kapitel 5 braucht es für kommunale Liegenschaften. Kapitel 6 und 7 brauchen es für Wärme- und Gasbestände. Kapitel 8 und 10 brauchen es für Netzbetreiberkommunikation, Messwesen und steuerbare Verbrauchseinrichtungen. Kapitel 11 und 12 brauchen es für Beschlussvorlagen und Arbeitsprogramme.

Das Grundmodell: Eine Aussage, sieben Prüfspalten

Die wichtigste Einheit der Datenarchitektur ist nicht die Tabelle, sondern die Aussage. Eine Aussage kann lauten: "Die Schule X verbraucht jährlich 180.000 kWh Strom." Oder: "Auf dem Dach des Bauhofs ist eine PV-Anlage mit 99 kWp installiert." Oder: "Der Standort Y hat einen Viertelstundenlastgang." Oder: "Die Kommune kann den Speicher zur Reduktion von Lastspitzen einsetzen." Jede dieser Aussagen braucht sieben Prüfspalten.

Objekt: Worauf bezieht sich die Aussage? Auf ein Gebäude, ein Grundstück, eine Marktlokation, einen Netzanschluss, eine Anlage, einen Betreiber, eine Kostenstelle, eine Straße oder ein Gebiet?

Messpunkt: Welche Marktlokation, Messlokation, Zählernummer, Messeinrichtung oder Einspeisestelle ist betroffen? Bei Wärme und Gas entsprechend: welche Lieferstelle, Anlage, Übergabestation oder Abrechnungseinheit?

Zeitraum: Für welchen Zeitraum gilt die Zahl? Ein Rechnungsjahr, ein Kalenderjahr, ein Lieferjahr, ein Monat, ein Viertelstundenintervall, ein Stichtag oder ein Planstand?

Rolle: Wer ist Eigentümer, Betreiber, Nutzer, Letztverbraucher, Anlagenbetreiber, Lieferant, Messstellenbetreiber, Netzbetreiber, Verpächter, Contractor oder Haushaltsverantwortlicher?

Quelle: Woher stammt die Aussage? Rechnung, Lastgangdatei, MaStR, Netzbetreiberantwort, Messstellenbetreiberportal, Liegenschaftsregister, Wärmeplan, OSM, GIS, Vertrag, Beschlussvorlage, Gutachten oder Schätzung?

Qualität: Ist der Wert gemessen, abgerechnet, registerbasiert, geprüft, plausibilisiert, geschätzt, modelliert, veraltet, widersprüchlich oder gesperrt?

Haushaltswirkung: Welche Kostenstelle, Investitionsnummer, Vertragslaufzeit, Einnahmeart, Folgekostenposition, Beteiligungswirkung oder Beschlussfrage wird berührt?

Diese sieben Spalten sollten in jeder kommunalen Energieakte sichtbar sein. Sie machen aus einer Datensammlung ein Nachweissystem. Ohne sie bleibt unklar, ob eine Zahl als Beleg, Prüfwert, Annahme oder Sperre zu behandeln ist.

Objektidentität: Gebäude, Grundstück, Anschluss und Organisation trennen

Die erste Datenfalle liegt in der Objektidentität. Eine kommunale Liegenschaft ist nicht immer ein Gebäude. Ein Gebäude ist nicht immer eine Kostenstelle. Eine Kostenstelle ist nicht immer ein Netzanschluss. Ein Netzanschluss ist nicht immer eine Marktlokation. Eine Adresse ist nicht immer eindeutig. Und eine organisatorische Zuständigkeit kann von Eigentum und Nutzung abweichen.

Für Energieentscheidungen muss die Kommune mindestens vier Objektlogiken trennen.

Liegenschaftslogik: Sie fragt nach Grundstück, Gebäude, Gebäudeteil, Nutzung, Eigentum, Baujahr, Sanierungsstand, Dachfläche, Heizsystem, Brandschutz, Denkmalschutz und Bauunterhaltung. Diese Sicht liegt häufig im Gebäudemanagement oder Bauamt.

Energiewirtschaftliche Logik: Sie fragt nach Netzanschluss, Marktlokation, Messlokation, Zähler, Lieferant, Messstellenbetreiber, Netzbetreiber, Lastgang, Einspeisung, Einspeiseanlage, Bilanzierung und Vertragsmodell. Diese Sicht liegt häufig bei Lieferant, Netzbetreiber, Messstellenbetreiber oder Stadtwerk.

Haushaltslogik: Sie fragt nach Kostenstelle, Produkt, Sachkonto, Investitionsmaßnahme, Fördermittel, Bewirtschaftungsbudget, Eigenbetrieb, Beteiligung, interner Leistungsverrechnung und Zuständigkeit der Bewirtschaftung. Diese Sicht liegt in Kämmerei, Fachamt und Haushaltsplanung.

Betriebslogik: Sie fragt nach Nutzer, Betriebszeiten, Hausmeister, Dienstleister, Fuhrpark, Schulbetrieb, Feuerwehrbereitschaft, Sportnutzung, Wartung, Störung, Zugang und Alltag. Diese Sicht liegt oft in mehreren Ämtern und ist selten vollständig digitalisiert.

Wenn diese vier Logiken nicht sauber verbunden werden, entstehen falsche Prioritäten. Ein Gebäude kann auf dem Papier einen hohen Stromverbrauch haben, tatsächlich aber mehrere Nutzer, Untermessungen und Sonderlasten enthalten. Ein Dach kann im GIS groß wirken, aber wegen Statik, Brandschutz, Verschattung oder Sanierungsfenster nicht nutzbar sein. Eine PV-Anlage kann auf kommunalem Grund stehen, aber einem Dritten gehören. Ein Netzanschluss kann mehrere Gebäude versorgen. Eine Kostenstelle kann Verbräuche mehrerer Lieferstellen bündeln.

Die Datenarchitektur muss daher mit einer Objekt-ID arbeiten, die nicht eine bestehende Nummer ersetzt, sondern die vorhandenen Nummern zusammenführt. Für jedes Objekt sollten mindestens geführt werden:

kommunale Objekt-ID,
Adresse und Geokoordinate,
Grundstücks- oder Flurstücksbezug, soweit verfügbar,
Gebäudeteil und Nutzung,
Eigentümer und Nutzer,
zuständiges Amt,
Kostenstelle und Haushaltsbezug,
Netzanschluss und Marktlokation,
Messlokation und Zähler,
relevante Anlagen-IDs, insbesondere MaStR-Nummern,
Datenverantwortlicher und letzter Prüfstand.

Diese Stammdaten sind nicht spektakulär. Ohne sie ist jede spätere Analyse unsicher.

MaStR: Registeranker, kein Anlageninventar der Kommune

Das Marktstammdatenregister ist ein zentraler Behördenanker für die kommunale Energiedatenarchitektur. Die Bundesnetzagentur beschreibt das MaStR als umfassendes behördliches Register für Stammdaten des Strom- und Gasmarktes. Es enthält insbesondere Angaben zu Stromerzeugungsanlagen, etwa Energieträger, Anlagenleistung und Standort, und stellt Daten für Anlagenbetreiber, Netzbetreiber, Politik und Behörden bereit.

Für die Datenarchitektur sind drei Quellenebenen wichtig. Erstens die öffentliche Suche und die öffentlichen Übersichten des MaStR. Zweitens der Gesamtdatenexport, der nach Angaben des MaStR als XML bereitgestellt und in der Regel morgens aktualisiert wird. Drittens die Marktstammdatenregisterverordnung als rechtlicher Rahmen. § 5 MaStRV verpflichtet Betreiber, Einheiten sowie EEG- und KWK-Anlagen zu registrieren; Registrierungen müssen grundsätzlich innerhalb eines Monats nach Inbetriebnahme erfolgen. § 13 MaStRV beschreibt die Überprüfung gespeicherter Daten durch Netzbetreiber auf Aufforderung der Bundesnetzagentur.

Für die Kommune folgt daraus eine klare, aber begrenzte Nutzung:

Das MaStR ist ein Registeranker. Es beweist nicht automatisch kommunales Eigentum, tatsächliche Erzeugung, Eigenverbrauch, Haushaltswirkung oder Beschlussreife.

Ein MaStR-Eintrag beantwortet vor allem: Welche registrierte Einheit oder Anlage existiert nach Registerstand? Wo ist sie verortet? Welche technischen Stammdaten sind eingetragen? Wer ist als Marktakteur oder Betreiber relevant, soweit öffentlich sichtbar? Welcher Datenstand wurde genutzt?

Ein MaStR-Eintrag beantwortet nicht allein:

ob die Anlage kommunal ist,
ob sie einem Eigenbetrieb, Stadtwerk, Contractor oder Dritten gehört,
ob der Strom im kommunalen Objekt verbraucht wird,
welche Viertelstunden-Erzeugung tatsächlich vorliegt,
welches Messkonzept gilt,
welche Einnahmen oder Einsparungen entstehen,
ob die Anlage vollständig, fehlerfrei oder aktuell im Register geführt ist.

Die kommunale Arbeitsregel lautet deshalb: Jeder MaStR-Fund wird zuerst als Anlagenhypothese geführt. Aus der Hypothese wird erst dann ein kommunaler Nachweis, wenn Betreiberrolle, Objektzuordnung, Netzanschluss, Zählerkonzept, Abrechnung und tatsächliche Erzeugungs- oder Einspeisedaten abgeglichen sind.

Praktisch sollte die Kommune einen MaStR-Abgleich in fünf Schritten durchführen:

Gebietsexport: MaStR-Daten für das Gemeindegebiet oder die relevante Gebietskulisse mit Exportdatum sichern.
Adress- und Geoprüfung: Registerstandort gegen kommunale Adressen, Flurstücke, Gebäude und bekannte Anlagen prüfen.
Rollenklärung: Betreiber, Eigentümer, Nutzer, Vertragspartner und Haushaltsverantwortung trennen.
Mess- und Vertragsabgleich: Zähler, Marktlokation, Messlokation, Einspeisung, Eigenverbrauch und Vergütungs- oder Lieferverträge prüfen.
Statusentscheidung: Anlage als kommunal belegt, kommunal relevant, Drittanlage, unklar, veraltet oder gesperrt markieren.

Gerade der letzte Schritt ist wichtig. Eine Datenbank ohne Statusentscheidung lädt zu Fehlinterpretationen ein. Ein Kämmerer braucht nicht nur den Anlagenfund, sondern den Prüfstatus.

Messpunktlogik: Marktlokation, Messlokation und Zähler nicht vermischen

Kommunale Energieprojekte werden oft über Zählernummern begonnen. Das ist verständlich, aber unzureichend. Eine Zählernummer kann sich ändern. Eine Rechnung kann mehrere Informationen bündeln. Eine Marktlokation beschreibt die energiewirtschaftliche Verbrauchs- oder Einspeisestelle, eine Messlokation die messtechnische Erfassung, und der physische Zähler ist nur ein Teil der Messinfrastruktur. Für Beschlussvorlagen muss klar sein, welche Ebene gemeint ist.

Die Messpunktlogik ist besonders wichtig, wenn eine Kommune Eigenverbrauch, Gebäudestrom, Energy Sharing, steuerbare Verbrauchseinrichtungen, Speicher, Ladepunkte oder dynamische Tarife prüft. In diesen Fällen reicht die Jahresabrechnung nicht. Die Kommune muss wissen, wo Strom entnommen, eingespeist, gemessen, bilanziert und abgerechnet wird.

Das Messstellenbetriebsgesetz zeigt, warum diese Unterscheidung keine Formalie ist. § 55 MsbG beschreibt die Messwerterhebung Strom. Bei Letztverbrauchern mit einem Jahresstromverbrauch von mehr als 100.000 kWh erfolgt die Messung durch Zählerstandsgangmessung oder, soweit erforderlich, durch viertelstündige registrierende Lastgangmessung. Bei Letztverbrauchern mit intelligentem Messsystem sowie bei steuerbaren Verbrauchseinrichtungen nach § 14a EnWG gelten ebenfalls spezifische Messlogiken. Bei Erzeugungs- und Verbrauchssituationen an einem Anschlusspunkt sind entnommene und eingespeiste sowie, soweit angeordnet, verbrauchte und erzeugte Energie in einem einheitlichen Verfahren zu messen.

§ 60 MsbG ordnet die Datenübermittlung durch den Messstellenbetreiber an berechtigte Stellen. In den dort beschriebenen Fällen werden Last-, Zählerstands- oder Einspeisegänge unter anderem täglich für den Vortag und unter bestimmten Anforderungen auch viertelstündlich übermittelt. Für die Kämmerei bedeutet das nicht, dass jede kommunale Stelle automatisch jeden Messwert frei verwenden darf. Es bedeutet aber, dass Messdaten organisatorisch, rechtlich und technisch in definierten Rollen verarbeitet werden.

Eine kommunale Messpunktliste sollte daher mindestens enthalten:

Marktlokations-ID,
Messlokations-ID,
Zählernummer und Zählerart,
Netzanschluss und Adresse,
Netzbetreiber,
Messstellenbetreiber,
Lieferant,
Letztverbraucher oder Anlagenbetreiber,
Kostenstelle und Haushaltsprodukt,
Messverfahren, etwa SLP, RLM, iMSys oder Zählerstandsgang,
Datenauflösung und Verfügbarkeit,
Beginn und Ende des Liefer- oder Messzeitraums,
Zuordnung zu Gebäude, Anlage, Ladepunkt, Wärmepumpe, Speicher oder sonstiger Nutzung,
Datenschutz- und Freigabestatus.

Ohne diese Liste lassen sich Energiezahlen nicht zuverlässig mit Rechnungen, Anlagen, Verträgen und Beschlüssen verbinden.

Lastprofile: SLP ist kein gemessener Betrieb

Standardlastprofile sind ein wichtiges Instrument des Strommarktes. Sie dürfen in kommunalen Energieanalysen aber nicht als echte Lastgänge missverstanden werden. Der BDEW beschreibt, dass Stromverteilnetzbetreiber nach § 12 Absatz 1 Stromnetzzugangsverordnung Standardlastprofile für Kunden nutzen, für die keine Lastgang- oder Zählerstandsdaten vorliegen. Das umfasst Verbraucher ohne registrierende Leistungsmessung und ohne intelligente Messsysteme. Standardlastprofile sollen die viertelstündliche Stromabnahme von Kundengruppen in der Gesamtheit möglichst präzise abbilden.

Für die Kämmerei ist der Zusatz "in der Gesamtheit" entscheidend. Ein Standardlastprofil kann für Bilanzierung, Prognose und erste Plausibilisierung geeignet sein. Es zeigt aber nicht, wie die konkrete Schule, das konkrete Rathaus oder der konkrete Bauhof tatsächlich an einem bestimmten Dienstag geladen, geheizt, gekühlt oder produziert hat.

Deshalb sollte die kommunale Datenarchitektur drei Lastdatenklassen unterscheiden:

Gemessene Zeitreihe: RLM-, Zählerstandsgang-, Einspeisegang- oder iMSys-Daten mit Zeitstempel, Messpunkt, Einheiten, Fehlwertstatus und Quelle. Diese Daten sind für Lastspitzen, Eigenverbrauch, Speicher, steuerbare Verbrauchseinrichtungen und dynamische Tarife besonders wertvoll.

Abgerechneter Jahres- oder Monatswert: Rechnungs- oder Ablesewert mit Zeitraum, Tarif, Preisbestandteilen und Messpunktbezug. Diese Daten sind für Haushalts- und Kostenabgleich wichtig, zeigen aber keine Laststruktur.

Profilierter Wert: Standardlastprofil oder Ersatzprofil, skaliert aus Jahresverbrauch, Nutzungsart oder Netzbetreiberzuordnung. Diese Daten sind für erste Modelle und Lückenfüllung geeignet, müssen aber als Modell gekennzeichnet werden.

Für Beschlüsse gilt: Je stärker eine Maßnahme von Zeitgleichheit, Lastspitzen, Flexibilität oder Preisfenstern abhängt, desto weniger reicht ein Standardlastprofil. Eine PV-Eigenverbrauchsrechnung, ein Speicher-Business-Case, ein §-14a-Prüfpfad, ein dynamischer Tarif oder ein Bauhof-Lademanagement brauchen echte oder zumindest belastbar simulierte Zeitreihen mit offengelegten Annahmen. Fehlen diese Daten, darf die Vorlage nur einen Prüfauftrag oder eine Vorplanung beschließen.

SMARD und Marktdaten: Systemkontext statt kommunaler Messwert

SMARD ist für Kapitel 9 relevant, weil es ein Beispiel für gut zugängliche, amtliche Marktdaten ist. § 111d EnWG verpflichtet die Bundesnetzagentur zum Betrieb einer nationalen Informationsplattform mit aktuellen Informationen unter anderem zu Erzeugung, Last, Importen, Exporten, Netz- und Anlagenverfügbarkeit sowie grenzüberschreitenden Kapazitäten. Die Daten sind aggregiert für die deutsche Gebotszone und frei zugänglich. SMARD weist außerdem darauf hin, dass veröffentlichte Marktdaten kostenfrei genutzt werden können und unter CC BY 4.0 stehen; zugleich wird die Datenqualität kontinuierlich verbessert, ohne Haftung für Richtigkeit und Vollständigkeit zu übernehmen.

Für die kommunale Datenarchitektur heißt das:

SMARD liefert Markt- und Systemkontext. SMARD ersetzt keine lokale Messstelle, keinen Liefervertrag und keine kommunale Rechnung.

SMARD ist geeignet für:

nationale Erzeugungs-, Last-, Import- und Exportentwicklungen,
Day-Ahead-Preise als Großhandelssignal,
Plausibilisierung von Zeitfenstern,
Erklärung von Strommarktzusammenhängen,
Abgrenzung von Systemdaten und lokalen Haushaltsdaten.

SMARD ist nicht geeignet für:

konkrete Stromkosten einer Kommune ohne Liefervertrag,
Eigenverbrauchsquote einer Liegenschaft ohne Messpunktdaten,
lokale Erzeugung aus MaStR-Anlagen ohne tatsächliche Erzeugungszeitreihe,
Einsparversprechen aus dynamischen Tarifen ohne lokale Laststeuerung,
Beschlussreife von Speichern oder Ladeinfrastruktur ohne Standortdaten.

Die Datenarchitektur sollte daher eine klare Quellenklasse "Marktdaten" führen. Diese Klasse darf als Kontext, Vergleich, Plausibilisierung oder Szenario verwendet werden. Sie darf nicht stillschweigend in "kommunaler Ist-Wert" umbenannt werden.

OSM und GIS: Gute Geodaten, aber kein amtliches Liegenschaftsregister

OpenStreetMap ist für kommunale Energieanalysen nützlich. Es kann Gebäudekörper, Straßen, Flächennutzungen, Orientierung, Umfeld, Wegebeziehungen und erste Geometrien liefern. Die OSM Foundation stellt OpenStreetMap-Daten als offene Daten unter der Open Database License bereit und verlangt unter anderem Attribution sowie Beachtung der Lizenzbedingungen.

Für die Kämmerei ist OSM aber kein amtliches Liegenschaftsregister. Ein Gebäudepolygon in OSM kann fehlen, veraltet, ungenau, falsch attribuiert oder ohne Nutzungsinformation sein. Es sagt nichts über Eigentum, Dachstatik, Brandschutz, Denkmalschutz, Sanierungszustand, Hausanschluss, Zähler, Betreiber, Mietverhältnisse oder Haushaltsstelle. OSM kann deshalb eine Energieakte unterstützen, aber nicht ersetzen.

Die richtige Rolle von OSM und GIS liegt in drei Bereichen:

Geometrischer Einstieg: Gebäudeumrisse, Lage, Nachbarschaft, Wege und Flächen können helfen, Objekte zu identifizieren, Dachflächen grob zu prüfen oder Wärmenetzkorridore zu visualisieren.

Plausibilisierung: OSM-Daten können mit kommunalem GIS, ALKIS, Liegenschaftsregister, Bauakten, Energieausweisen, Dachkataster und Luftbildern abgeglichen werden. Abweichungen sind Hinweise auf Prüfbedarf.

Kommunikation: Karten helfen Rat, Verwaltung und Öffentlichkeit, Energiefragen räumlich zu verstehen. Sie dürfen aber nur mit korrektem Quellen- und Lizenzhinweis und ohne Überdehnung der Aussagekraft verwendet werden.

Für die Datenarchitektur sollte jede Geodatenquelle nach Status markiert werden:

amtliche kommunale Geodaten,
öffentliches Open-Data-Angebot,
OSM oder Community-Daten,
Luftbild- oder Fernerkundungsableitung,
Gutachter- oder Dienstleistermodell,
manuell gezeichnete Arbeitsgeometrie.

Diese Statusspalte verhindert, dass eine optisch überzeugende Karte mehr Beweiskraft erhält als ihr zusteht.

Anlagenlisten: Aus Einzelquellen wird ein Asset-Register

Das wichtigste fehlende Element in vielen Kommunen ist eine belastbare Energie-Asset-Liste. Sie umfasst nicht nur PV-Anlagen. Sie umfasst Stromerzeuger, Speicher, Ladepunkte, Wärmepumpen, Kälteanlagen, Heizkessel, Wärmenetzanschlüsse, Übergabestationen, Blockheizkraftwerke, Notstromanlagen, Steuerboxen, Energiemanagementsysteme, Messstellen und größere Verbraucher.

Eine solche Liste darf nicht nur technische Spalten enthalten. Sie muss organisatorisch und haushalterisch lesbar sein. Mindestfelder sind:

Asset-ID und Objektbezug,
Asset-Kategorie,
Standort und Gebäudeteil,
technische Leistung, Kapazität oder Anschlusswert,
Inbetriebnahmedatum und Status,
Eigentümer,
Betreiber,
Nutzer oder begünstigte Organisationseinheit,
Netzanschluss, Marktlokation und Messlokation,
MaStR-ID, soweit relevant,
Wartungs- und Betriebsvertrag,
Liefer-, Einspeise-, Pacht-, Contracting- oder Dienstleistungsvertrag,
Fördermittel- oder Vergütungsstatus,
Haushaltsstelle oder Beteiligungsbezug,
Datenquelle und letzter Prüfstand,
offene Sperren.

Die offene Sperre ist keine Schwäche, sondern eine Steuerungsinformation. Ein Speicher ohne Messkonzept, eine PV-Anlage ohne Betreiberklärung, ein Ladepunkt ohne Netzbetreiberantwort oder eine Wärmepumpe ohne Anschlussleistungsprüfung ist kein fertiger Datensatz. Er ist ein Arbeitsauftrag.

Cernion Energy Tools wurden für dieses Kapitel read-only geprüft. Der Evidence Router fand keinen passenden Endpunkt für kommunale Asset-Tabellen, Anlagenlisten, Messpunkte oder lokale Lastgänge. Die Knowledge-RAG-Abfrage lieferte methodische Hinweise, aber keine ausreichende primärquellengestützte Evidenz für harte Rechts-, Rollen- oder Prozesspflichten. Daher wurden keine Cernion-Zahlen, Rechtsbewertungen oder lokalen Asset-Fakten übernommen. Diese Begrenzung passt zur Kapitelthese: Ein Datenwerkzeug kann die Struktur verbessern, aber fehlende lokale Assetdaten nicht ersetzen.

Datenschutz und Datenberechtigung: Nicht jede nützliche Zahl darf frei wandern

Energiedaten können personenbezogen, betriebsrelevant, sicherheitsrelevant oder vertraulich sein. Das gilt besonders bei Messwerten, Lastgängen, Nutzungsprofilen, Betreiberinformationen, kritischer Infrastruktur, Feuerwehr- und Betriebsstandorten, Mietern, Schulen, Vereinen und Wohngebäuden. Eine kämmereitaugliche Datenarchitektur muss deshalb nicht nur fragen, ob Daten vorhanden sind, sondern ob sie für den konkreten Zweck verarbeitet und weitergegeben werden dürfen.

§ 49 MsbG nennt die berechtigten Stellen zur Verarbeitung personenbezogener Daten aus dem Messwesen, darunter Messstellenbetreiber, Netzbetreiber, Bilanzkoordinatoren, Bilanzkreisverantwortliche, Direktvermarktungsunternehmer, Energielieferanten, Aggregationsverantwortliche, Messwertweiterverarbeiter sowie Stellen mit Einwilligung des Anschlussnutzers. § 50 MsbG begrenzt Zulässigkeit und Umfang der Verarbeitung auf Einwilligung oder erforderliche Zwecke, etwa Vertragserfüllung, rechtliche Verpflichtungen, Netzbetrieb, Belieferung, Abrechnung, Bilanzierung, Registerpflichten, Flexibilitätsvermarktung, §-14a-Steuerung oder variable Tarife.

Für die Kommune entsteht daraus eine praktische Governance-Regel:

Datenzugang ist kein Besitzrecht. Jede Nutzung braucht Zweck, Rolle, Berechtigung, Datensparsamkeit und Lösch- oder Archivierungsregel.

Die Datenarchitektur sollte deshalb für jede Datenklasse festhalten:

Zweck der Verarbeitung,
Rechts- oder Vertragsgrundlage,
Datenverantwortlicher,
Empfänger und Zugriffskreis,
Aggregationsgrad,
Personenbezug oder Vertraulichkeitsstatus,
Speicherort,
Aufbewahrungs- und Löschregel,
Freigabe für interne Vorlage, nicht öffentlichen Draft, öffentliche Veröffentlichung oder gesperrte Nutzung.

Gerade im Buchprojekt ist diese Trennung wichtig. Der BookStack-Draft ist nicht öffentlich. Trotzdem dürfen lokale Messwerte, Verträge oder personenbezogene Informationen nicht ungeprüft in einen redaktionellen Text wandern. Für die Veröffentlichung sind aggregierte, anonymisierte oder ausdrücklich freigegebene Werte zu verwenden.

Datenqualität: Ein Ampelsystem mit Abbruchpunkten

Ein Energiedatenraum wird nicht dadurch besser, dass alle Felder gefüllt sind. Er wird besser, wenn jedes Feld seinen Qualitätsstatus trägt. Für kommunale Entscheidungen reicht ein einfaches Ampelsystem, wenn es konsequent verwendet wird.

Grün: belegt und entscheidungsfähig. Die Quelle ist benannt, der Zeitraum passt, der Messpunkt ist zugeordnet, die Rolle ist geklärt, der Wert ist aktuell genug und die Haushaltswirkung ist nachvollziehbar.

Gelb: plausibel, aber prüfbedürftig. Die Quelle ist vorhanden, aber unvollständig; Zeitraum, Rolle, Messpunkt, Vertragsbezug oder Datenqualität sind nicht vollständig geklärt. Der Wert darf für Vorprüfung, Priorisierung oder Szenario verwendet werden, aber nicht als harte Haushaltszahl.

Rot: gesperrt. Die Quelle fehlt, widerspricht anderen Quellen, ist veraltet, nicht freigegeben, personenbezogen ohne Berechtigung, methodisch unpassend oder für die konkrete Aussage ungeeignet. Der Wert darf nicht zur Begründung eines Umsetzungsbeschlusses verwendet werden.

Grau: nicht erforderlich. Die Information ist für die konkrete Entscheidung nicht nötig oder würde Scheingenauigkeit erzeugen.

Dieses Ampelsystem braucht Abbruchpunkte. Ein Abbruchpunkt ist die Stelle, an der eine Rechnung, Bewertung oder Vorlage bewusst nicht weitergeführt wird. Beispiele:

MaStR-Fund ohne Betreiberklärung: keine kommunale Erzeugungsaussage.
Jahresverbrauch ohne Lastgang: keine Speicher- oder Lastspitzenrechnung.
OSM-Dachfläche ohne kommunale Objektprüfung: keine PV-Investitionsentscheidung.
Day-Ahead-Preis ohne Liefervertrag: keine kommunale Stromkostenersparnis.
Ladepunktliste ohne Netzanschlussdaten: keine §-14a- oder Netzentgeltbewertung.
Wärmeplan-Gebiet ohne Betreiberangebot: keine Anschlusskostenentscheidung.
Messdaten ohne Berechtigung: keine Auswertung und keine Veröffentlichung.

Abbruchpunkte sind für Kämmerer hilfreich, weil sie Beschlüsse nicht verhindern, sondern richtig begrenzen. Aus "Umsetzung" wird dann "Datenerhebung", "Netzbetreiberklärung", "Variantenprüfung", "Vorplanung" oder "Rückkehr ins Gremium".

Datenraum und Verantwortlichkeiten

Eine gute Datenarchitektur braucht keine perfekte zentrale Plattform im ersten Schritt. Sie braucht klare Verantwortlichkeiten. Die Kommune sollte einen Datenraum definieren, in dem fachliche Daten zusammengeführt werden, ohne Zuständigkeiten zu verwischen.

Ein arbeitsfähiges Modell unterscheidet fünf Rollen:

Datenhalter: Stelle, bei der die Daten entstehen oder originär liegen, etwa Gebäudemanagement, Kämmerei, Netzbetreiber, Messstellenbetreiber, Lieferant, Stadtwerk, Eigenbetrieb oder Dienstleister.

Datenverantwortlicher: Stelle, die für Richtigkeit, Aktualität und Freigabe im kommunalen Arbeitsstand verantwortlich ist.

Fachprüfer: Stelle, die die energiewirtschaftliche, technische, rechtliche oder haushalterische Bedeutung bewertet.

Nutzer der Entscheidung: Rat, Ausschuss, Verwaltungsvorstand, Fachamt, Eigenbetrieb oder Beteiligung.

Archiv- und Nachweisverantwortlicher: Stelle, die Versionen, Quellen, Beschlussstände und spätere Prüfungen nachvollziehbar hält.

In kleineren Kommunen können mehrere Rollen in einer Person liegen. Trotzdem sollten sie im Datenmodell getrennt bleiben. Sonst ist unklar, ob ein Wert fachlich geprüft, nur geliefert oder bereits politisch entschieden wurde.

Mindestarchitektur: Die fünf Kernregister

Für den Einstieg reicht eine überschaubare Mindestarchitektur. Sie besteht aus fünf Kernregistern, die über IDs miteinander verbunden sind.

1. Objektregister: Gebäude, Grundstücke, Liegenschaften, technische Standorte, Nutzung, Eigentum, Zuständigkeit, Kostenstelle, Geometrie und Datenqualität.

2. Messpunktregister: Marktlokationen, Messlokationen, Zähler, Netzanschluss, Netzbetreiber, Messstellenbetreiber, Lieferant, Messverfahren, Datenauflösung und Zeitraum.

3. Asset-Register: Erzeugungsanlagen, Speicher, Ladepunkte, Wärmepumpen, Wärmeerzeuger, Übergabestationen, EMS, Steuertechnik, kritische Verbraucher und relevante Großverbraucher.

4. Zeitreihenregister: Strombezug, Einspeisung, Erzeugung, Wärmeverbrauch, Gasverbrauch, Lastgänge, Zählerstandsgänge, Preisreihen, Wetter- oder Nutzungsparameter, jeweils mit Quelle, Einheit, Zeitauflösung und Fehlwertstatus.

5. Entscheidungsregister: Beschlüsse, Prüfaufträge, offene Sperren, Haushaltsstellen, Verträge, Vergaben, Zuständigkeiten, Fristen, Wiedervorlagen und Reviewstatus.

Die technische Umsetzung kann einfach beginnen: strukturierte Tabellen, ein Dokumentenablagekonzept, klare Dateinamen, Versionsstände und ein Nachweisregister. Entscheidend ist, dass die Verknüpfungen stabil sind. Wenn später eine Datenplattform, ein GIS, ein Energiemanagementsystem oder ein Cernion-/STROMDAO-naher Datenprozess hinzukommt, kann er auf dieser Struktur aufsetzen.

Beispiel: Aus 15 offenen Nachweisen wird ein Arbeitsplan

Ein typischer kommunaler Prüfpunkt lautet: "PV, Speicher und Ladepunkte am Bauhof prüfen." Ohne Datenarchitektur klingt das nach einer technischen Machbarkeitsstudie. Mit Datenarchitektur wird daraus ein Arbeitsplan.

Die offenen Nachweise lauten:

Objekt-ID, Adresse, Gebäudeteile und Grundstücksbezug des Bauhofs.
Zuständiges Amt, Nutzer, Betriebszeiten und Fuhrparkprofil.
Strom-Marktlokation, Messlokation und Zähler.
Jahresverbrauch und verfügbare Viertelstundenwerte.
Anschlussleistung und Netzbetreiberangaben.
Liefervertrag, Preisbestandteile und Laufzeit.
Dachflächen, Statik, Brandschutz, Sanierungsfenster und Verschattung.
MaStR-Abgleich für bestehende Anlagen am Standort.
Geplante PV-Leistung und Betreiberrolle.
Ladepunkte, Fahrzeugklassen, Ladezeiten und Mindestverfügbarkeit.
Speicherzweck, Kapazität, Leistung, Betriebsstrategie und Reservelogik.
§-14a-Einordnung, Mess- und Steuerungskonzept.
Investition, Betriebskosten, Wartung, EMS und Messstellenkosten.
Haushaltsstellen, Fördermittel und Vergabepfad.
Datenschutz-, Zugriffs- und Veröffentlichungsstatus der Daten.

Jeder Nachweis erhält eine Ampel und einen Datenhalter. Daraus entsteht keine fertige Umsetzung, aber eine beschlussfähige Vorstufe. Der Rat kann entscheiden, ob die Verwaltung diese Nachweise beschaffen, eine Vorplanung beauftragen oder eine Variante vertiefen soll. Das ist besser als eine pauschale Wirtschaftlichkeitsrechnung, die fehlende Daten verdeckt.

Beschlussreife-Gate für Kapitel 9

Eine kommunale Energieentscheidung ist datenarchitektonisch beschlussreif, wenn folgende Fragen beantwortet sind:

Welche Objekte, Messpunkte, Anlagen und Haushaltsstellen sind eindeutig betroffen?
Welche Daten stammen aus Primärquellen, welche aus Registern, welche aus Modellen und welche aus Schätzungen?
Welcher Zeitraum, welche Datenauflösung und welcher Stichtag gelten?
Sind Marktlokation, Messlokation, Zähler und Kostenstelle zusammengeführt?
Sind MaStR-Funde mit Betreiberrolle, Objektbezug, Netzanschluss und tatsächlichen Erzeugungs- oder Einspeisedaten abgeglichen?
Sind Lastprofile als Modell und gemessene Lastgänge als Messdaten getrennt?
Sind OSM-, GIS- und Gebäudedaten nach Quellenstatus markiert?
Sind Datenschutz, Einwilligung, Berechtigung, Zugriff und Veröffentlichungsfähigkeit geklärt?
Sind fehlende Daten als Sperre oder Prüfauftrag markiert?
Ist erkennbar, welche Zahl im Haushalt wirkt und welche nur System-, Klima-, Standort- oder Szenariokontext ist?
Gibt es eine verantwortliche Stelle für Aktualisierung, Versionierung und Wiedervorlage?
Ist der Beschluss passend begrenzt, falls eine dieser Fragen offen bleibt?

Wenn diese Fragen nicht beantwortet sind, ist die Entscheidung nicht automatisch falsch. Sie ist nur nicht umsetzungsreif. Dann gehört in die Vorlage kein Umsetzungsbeschluss, sondern ein begrenzter Prüf-, Daten- oder Planungsauftrag.

Zusammenfassung für Kämmerer

Datenarchitektur ist die stille Infrastruktur der kommunalen Energiewende. Sie entscheidet, ob ein Stromlagebild belastbar ist, ob ein Liegenschaftsprojekt haushaltsreif wird, ob Speicher- und Flexibilitätsrechnungen tragen, ob Wärme- und Gasentscheidungen nachvollziehbar bleiben und ob der Rat zwischen politischem Ziel, technischer Möglichkeit und finanzieller Wirkung unterscheiden kann.

Die wichtigsten Regeln sind:

MaStR ist ein Registeranker, kein kommunaler Eigentums- oder Erzeugungsbeweis.
SLP ist ein Bilanzierungs- und Prognoseinstrument, kein gemessener Betrieb eines konkreten Gebäudes.
SMARD ist Markt- und Systemkontext, keine kommunale Rechnung.
OSM ist ein hilfreicher Geodatenbaustein, kein amtliches Liegenschaftsregister.
Marktlokation, Messlokation, Zähler, Kostenstelle und Objekt müssen getrennt und verknüpft werden.
Jede lokale Zahl braucht Quelle, Zeitraum, Rolle, Qualitätsstatus und Haushaltsbezug.
Fehlende Daten sind nicht peinlich; sie sind der Arbeitsplan.

Für die Kämmerei ist die beste Datenarchitektur nicht die größte Datenbank. Es ist die Struktur, die eine klare Antwort ermöglicht: Diese Aussage ist belegt, diese ist plausibel, diese ist gesperrt, und diese Lücke muss vor der nächsten Entscheidung geschlossen werden.

Quellen- und Prüfstand

MaStRV § 5 und § 13, geprüft über Gesetze im Internet am 2026-07-12.
Bundesnetzagentur: Marktstammdatenregister und MaStR-Datendownload, geprüft am 2026-07-12.
EnWG § 111d und SMARD-Datennutzung, geprüft am 2026-07-12.
MsbG §§ 49, 50, 55 und 60, geprüft über Gesetze im Internet am 2026-07-12.
Bundesnetzagentur BK6-20-160 / Marktkommunikation 2022, geprüft am 2026-07-12.
BDEW: Standardlastprofile Strom, Stand 18.03.2025, geprüft am 2026-07-12.
Cernion Energy Tools read-only: Evidence Router und Knowledge RAG am 2026-07-12; keine belastbare primärquellengestützte Cernion-Evidence für kommunale Asset-Tabellen, Messpunktlisten oder lokale Lastgänge.

BookStack-Notizen

BookStack-Ort:

Book: Der Kaemmerer und die Energiewende
Page: Kapitel 9: Datenarchitektur: MaStR, Lastprofile, OSM, Messpunkte und Anlagenlisten
Page ID: 322

Interne Linkkandidaten nach redaktioneller Prüfung:

Kapitel 3: Stromverbrauch, lokale Erzeugung und Importkosten.
Kapitel 5: Kommunale Liegenschaften als erster Umsetzungsraum.
Kapitel 8: Netzbetreiber-Kommunikation und Prozessrisiken.
Kapitel 10: Speicher, Flexibilität und steuerbare Verbrauchseinrichtungen.
Nachweisregister.
Rechenlogik und Tabellen.

Offene Nachweise vor Veröffentlichung:

lokale Messpunktliste mit Marktlokation, Messlokation, Zähler, Kostenstelle und Lieferstelle,
kommunales Liegenschaftsregister mit Objekt-ID,
MaStR-Export mit reproduzierbarem Filter und Exportdatum,
Netzbetreiber- und Messstellenbetreiberantworten,
lokale Lastgänge und Einspeisegänge,
Anlagen-/Asset-Tabelle,
Datenschutz- und Freigabestatus,
Haushaltsstellen und Beschlussbezüge,
redaktionelle Gegenprüfung gegen Kapitel 3, 5, 8, 10 und Nachweisregister.