GModG für Hausverwaltungs-Plattformen: Energieausweis als Plattform-Feature per API

Joost Jansky

Energieberater, Blogger

Hinweis — Kabinettsentwurf, noch kein geltendes Recht. Stand: Kabinettsbeschluss vom 13.05.2026. Inkrafttreten erst nach Bundestag, Bundesrat und Verkündung. Konkrete Paragraphen-Verweise beziehen sich auf den GModG-Kabinettsentwurf; den vollständigen Faktencheck lesen Sie im Pillar-Artikel zum Kabinettsentwurf.

Was sich für Hausverwaltungen mit dem GModG ändert

Vier Paragraphen verschieben den Energieausweis vom Aussteller in das Tagesgeschäft des Verwalters — und damit in Ihre Plattform:

Die vier Pflichten landen direkt im Tagesgeschäft des Verwalters. Plattformen, die sie im eigenen Workflow auffangen, halten den Verwalter im System; Plattformen, die nur nach außen verlinken, geben Touchpoint und Lead an einen Drittanbieter ab. Welche dieser Pflichten sich wie in einen Plattform-Workflow übersetzen lässt, betrachten wir im Folgenden einzeln.

Vier GModG-Paragraphen, vier Plattform-Workflows

§ 80 — die Mietverlängerung wird zum neuen Auslöser

§ 80 Abs. 3 GModG-E erweitert den Kreis der Anlässe, bei denen ein Energieausweis vorliegen muss. Künftig ist ein Ausweis auszustellen, wenn ein Gebäude, eine Wohnung oder eine selbständige Nutzungseinheit „vermietet, verpachtet oder verleast oder ein solcher Miet-, Pacht oder Leasingvertrag verlängert werden" soll — sofern nicht bereits ein gültiger Ausweis für das Gebäude existiert. Die Begründung zum Kabinettsentwurf benennt das explizit: „nunmehr auch bei Mietverlängerungen und nicht nur bei Abschluss eines Mietvertrages" liege ein Ausstellungsanlass vor.

Für Ihre Plattform heißt das: das Mietmanagement-Modul wird zum Trigger. Jede Vertragsverlängerung muss einen Ausweis-Status-Check anstoßen — Frage 1: gültiger Ausweis vorhanden? Frage 2: Gültigkeit reicht über die neue Vertragslaufzeit? Frage 3: passt der Ausweistyp (Bedarf, Verbrauch, Smart) zur Konstellation? Wer diese Logik heute manuell führt, verschiebt sie nach Inkrafttreten in einen automatischen Workflow. Die Endkunden-Sicht dieser Pflicht beschreiben die Schwester-Artikel zur neuen Wahlfreiheit Verbrauchsausweis und zur Vorbereitung auf 24 Monatsdaten.

§ 82 — 24 Monatswerte je Energieträger im Verbrauchsausweis

§ 82 Abs. 1 Satz 2 GModG-E verlangt eine deutlich feinere Datengrundlage als das geltende Recht. Der Endenergieverbrauch ist künftig „nach Energieträgern differenziert mindestens monatlich über 24 aufeinander folgende Monate zu erfassen". Die EU-Vorgabe dahinter — Anhang I Nummer 1 Satz 5 der EU-Gebäuderichtlinie (EU) 2024/1275 — ist eindeutig: monatlich und nach Energieträger getrennt.

Für die Plattform-Architektur bedeutet das, vom Jahres-Aggregat zur Matrix wohneinheit × energieträger × monat = kWh zu wechseln. Konkret entsteht je Gebäude eine Tabelle mit der Form:

Wer heute die HeizkostenV-Abrechnung jährlich aus Techem-, ista-, Brunata-Minol- oder KALO-Portalen importiert, muss diese Monatsraster künftig sauber speichern, getrennt nach Heizung, Warmwasser und Kühlung. Pauschalen von +16 kWh/(m²·a) für Warmwasser und +6 kWh/(m²·a) für Kühlung bleiben nach § 82 zulässig, ändern aber nichts am Monatsraster-Grundgerüst.

§ 84 — Modernisierungsempfehlungen als strukturierte Daten

§ 84 GModG-E setzt Art. 19 Abs. 7 bis 9 der EU-Gebäuderichtlinie um und verlangt eine quantifizierte Sanierungs-Roadmap im Ausweis: geschätzte Energieeinsparung je Maßnahme, geschätzte THG-Einsparung, Beurteilung der Restlebensdauer von Heizung und Klima, Prüfung der Niedertemperatur-Tauglichkeit (Wärmepumpe). Die Empfehlungspflicht entfällt nur in den Klassen A+ und A.

Für die Plattform ist die Frage nicht, ob der Aussteller diese Werte liefert — sondern wie. Wenn Sie die Empfehlungen ausschließlich als PDF-Bild zurückbekommen, sind sie für WEG-Sanierungspläne und Eigentümer-Reports nicht wiederverwendbar. Eine API, die die Modernisierungsempfehlungen als strukturierte JSON-Liste zurückgibt — pro Maßnahme die Felder bezeichnung, einsparung_kwh_pro_jahr, einsparung_thg_kg_co2, investition_brutto_eur, restlebensdauer_heizung_jahre, niedertemperatur_geeignet — macht aus jedem Ausweis eine wiederverwendbare Datenquelle: für die nächste Eigentümerversammlung, für den Sanierungsfahrplan der WEG und für die Förderberatung (BEG-EM, iSFP).

§ 87 — Pflichtangaben aus dem Bestand für jedes Inserat

§ 87 GModG-E verlangt in jeder kommerziellen Immobilienanzeige Pflichtangaben, die direkt aus dem Ausweis kommen: Ausweisart (Bedarf oder Verbrauch), den Endenergiebedarf bzw. -verbrauch in kWh/(m²·a), die Energieeffizienzklasse (für Wohngebäude weiter A+ bis H), die wesentlichen Energieträger der Heizung und das Baujahr. Eine Übergangsregel (§ 112 GModG-E) gilt für Ausweise, die vor Inkrafttreten ausgestellt wurden. Welche Konsequenz das für Makler hat, beschreibt der Schwester-Artikel GModG für Makler.

Für Verwaltungs-Plattformen mit Vermietungs- oder Exposé-Modul ist das ein Pre-Fill-Problem: Wenn die Plattform die Ausweis-Pflichtangaben strukturiert in der Stammakte hält, kann jedes neue Inserat automatisch korrekt befüllt werden — ohne Tippfehler, ohne aus dem Kopf geschätzte Klasse, ohne UWG-Abmahnungs-Risiko.

Zeitplan: Art. 9 GModG und das echte Implementierungs-Fenster

Art. 9 GModG-E ist der wichtigste Paragraph für Ihre Sprint-Planung — und wird in der öffentlichen Berichterstattung regelmäßig falsch verkürzt:

Die häufig zitierte „Sechs-Monats-Schonfrist" ist also keine. Die Sechs-Monats-Frist gilt für Folgeänderungen in anderen Gesetzen, nicht für die Energieausweis-Pflichten selbst. Für Verwaltungs-Plattformen heißt das: §§ 80, 82, 84, 87 und § 108 greifen mit der Verkündung.

Ein realistisches Implementierungs-Fenster sieht damit so aus: Wenn Bundestag und Bundesrat in der Sommer- oder Herbstsitzung 2026 zustimmen, läge die Verkündung wenige Wochen danach. Wer heute mit einer API-Anbindung beginnt, schafft eine produktive Integration innerhalb des Korridors — vorausgesetzt, die Schema-Migration für 24 Monatswerte und Modernisierungsempfehlungs-Daten ist parallel im Backlog.

Wo es klemmt: HeizkostenV-Daten und Make-or-Buy

Wer die vier Paragraphen ins Backlog übersetzt, stößt schnell auf zwei Knackpunkte: Woher kommen die 24 Monatswerte überhaupt, wenn der Verwalter keinen Direktzugriff auf die Zähler hat? Und ist es realistisch, den Ausweis selbst in der Plattform zu erzeugen — oder muss das ein Aussteller liefern? Beide Fragen lassen sich heute klar beantworten.

Wo die 24 Monatswerte tatsächlich herkommen

Die Daten, die § 82 GModG-E verlangt, existieren für vermietete Einheiten heute schon — sie kommen aus der HeizkostenV. § 5 Abs. 2 HeizkostenV verlangt, dass alle bestehenden Heiz- und Warmwasserzähler bis 31.12.2026 auf fernablesbare Geräte umgestellt werden. Bei fernablesbarem Equipment greift zusätzlich § 6a HeizkostenV: Eigentümer und Verwalter müssen den Nutzern monatlich Verbrauchsinformationen liefern — aktueller Verbrauch, Vergleich zu Vormonat und Vorjahresmonat, Vergleich mit einem Normnutzer.

Genau diese Monatsraster sind die Grundlage für § 82 GModG-E. Drei Lücken bleiben:

• Selbst genutzte Einfamilienhäuser ohne HeizkostenV-Pflicht — keine strukturierte Monatsdaten, nur Jahresabrechnung Gas / Öl / Pellets.
• Übergangsphase 2026–2028 — auch nach Ablauf der Nachrüstpflicht dauert es Monate, bis lückenlose 24-Monatshistorien aus fernablesbaren Geräten vorliegen.
• Datenformat-Heterogenität — Techem, ista, Brunata-Minol und KALO liefern Monatsdaten über eigene Portale und APIs in unterschiedlichen Strukturen. Ein einheitlicher Branchenstandard existiert nicht.

Plattformen brauchen damit zwei Schichten: einen Daten-Adapter zu den Messdienstleistern und ein Upload-Modul für Fälle, in denen der Verwalter Belege manuell zuliefert. Beides sind einmalige Investitionen — und sie zahlen sich aus, sobald Verbrauchsausweise nicht mehr Sonderfall, sondern Routine werden.

Drei Optionen für die Ausweis-Bereitstellung

Make-or-Buy fällt für Verwaltungs-Plattformen meist eindeutig aus. Drei Wege stehen offen, und nur einer skaliert:

Option (a) scheitert in der Regel an § 88 GModG-E — die Ausstellungsberechtigung ist personengebunden und lässt sich nicht durch eine Software-Lizenz ersetzen. Option (b) ist heute der Standard vieler Plattformen; sie funktioniert, kostet aber bei jeder Bestellung den Lead-Kontakt und den eigenen Touchpoint. Option (c) ist der dritte Weg, den der folgende Abschnitt vertieft.

Wie Sie die Integration heute planen

Ein realistischer Pilot startet mit einem klar abgegrenzten Workflow, nicht mit der Vollintegration. Drei Bausteine bewähren sich:

1. Use-Case-Workshop. Welche Workflows triggern einen Ausweis-Auftrag? Eigentümerwechsel, Mietverlängerung, WEG-Sanierungsbeschluss, anstehender Ablauf eines bestehenden Ausweises. Welche Workflows brauchen Daten zurück? Inseraten-Modul, WEG-Sanierungsplan, Eigentümer-Report, Stammakte.
2. Datenmodell und Audit-Trail. Pflichtfelder im Schema: 24 Monatswerte je Einheit und Energieträger, DIBt-Registriernummer, Ausstellungsdatum, Ablaufdatum (10 Jahre Gültigkeit), PDF-Hash. WEG-Beschluss-Dokumentation: Wer hat wann was beauftragt? Audit-Trail im Verwaltungssystem für mindestens zehn Jahre.
3. Pilot mit einer Referenz-Verwaltung. Eine Verwaltung mit ungefähr 500 Einheiten, ein abgegrenzter Workflow (z. B. nur Eigentümerwechsel im ersten Schritt), zwei bis vier Sprints. Erfolgs-Metriken: Zeit pro Bestellung, Drop-off-Rate, Daten-Vollständigkeit, Anzahl Rückfragen je Bestellung.

Wenn Sie die drei Bausteine als Pre-flight-Checkliste neben den ersten Sprint legen wollen, sieht das so aus:

WEG-rechtlich ist der Verwalter gemäß § 27 WEG berechtigt, Maßnahmen ordnungsgemäßer Verwaltung von „untergeordneter Bedeutung" (Abs. 1 Nr. 1) oder zur „Abwendung eines Nachteils" (Abs. 1 Nr. 2) auch ohne Einzelbeschluss zu ergreifen — die routinemäßige Bestellung eines Energieausweises bei drohendem § 108-Bußgeld lässt sich regelmäßig unter Nr. 2 fassen. § 19 WEG (ordnungsgemäße Verwaltung) verlangt darüber hinaus ein Fristen-Monitoring; Kardinalpflicht des Verwalters ist der rechtzeitige Hinweis auf ablaufende Ausweise. Unterbleibt das schuldhaft, ist die Haftung aus dem Verwaltervertrag — abgesichert über die Vermögensschadenhaftpflicht — die wahrscheinlichere Sanktion als das Bußgeld. Aus genau diesem Grund ist die Plattform der bessere Träger der Fristen-Logik als das Outlook-Postfach des einzelnen Sachbearbeiters.

Lösung: Die Energyausweis-API als Plattform-Baustein

Architektur in einem Absatz

Die Energyausweis-API verbindet eine Hausverwaltungs-Plattform mit dem Aussteller-Stack über eine REST-Schnittstelle mit OpenAPI-3.1.2-Spezifikation, gerendert mit Scalar als interaktive „Try it"-Konsole — Sie können also direkt im Browser einen Aufruf gegen die Test-Umgebung ausführen, mit cURL-, fetch- oder axios-Snippets als Vorlage. Die Authentifizierung läuft über Bearer-Token pro Partner, mit getrennter Test- und Produktions-Umgebung. Bilder und Dokumente werden via Presigned-URL-Upload direkt von der Plattform zur Storage-Schicht des Ausstellers geschoben — Sie brauchen keinen eigenen Storage-Stack. Status und Pflichtangaben (Klasse, kWh, Energieträger, Baujahr, Ausstellungsdatum, DIBt-Registriernummer, Ablaufdatum) kommen als strukturiertes JSON zurück, der fertige Ausweis steht als PDF zum Download. Status-Polling ist Standard; Webhooks sind beim Partner-Onboarding möglich, wenn Sie sie brauchen.

Vertrauensanker, die in der Eigentümerversammlung tragen

Eine API-Integration löst die technische Frage. Die zweite, oft unterschätzte Frage ist die der Belastbarkeit: Steht hinter dem Ausweis eine ausstellungsberechtigte Person, eine geprüfte Methodik, eine eindeutige Registrierung? Sieben Anker lassen sich in der Eigentümerversammlung und im Compliance-Audit konkret benennen:

• Zertifizierte Energieberater stellen jeden Ausweis aus — keine reine Automatisierung, persönliche Prüfung pro Auftrag.
• DIN-V-18599-Gütesiegel der Gütegemeinschaft Gebäudebilanzierung e. V. — die eingesetzte Berechnungssoftware ist gütegesichert.
• DIBt-Registrierung durch das Deutsche Institut für Bautechnik — jeder Ausweis trägt eine eindeutige Registriernummer, die im Audit-Trail referenzierbar bleibt.
• Bestehende Plattform-Partnerschaft mit Immodio — produktive Integration, abrufbar als Referenz.
• OpenAPI 3.1.2 + Scalar-Try-it — Entwickler-Onboarding ohne Vertriebsprozess.
• White-Label-Branding — Logo der Plattform im Bestellprozess und auf dem PDF; der Endkunde sieht weiter die vertraute Marke.
• GModG-Updates kommen über die API-Versionierung — die Plattform muss Rechts-Updates nicht selbst tracken.

Keiner dieser Punkte ist ein Marketing-Argument. In Eigentümerversammlungen und Vendor-Reviews entscheiden sie regelmäßig darüber, ob die Plattform als Ausweis-Quelle akzeptiert wird oder ob die Gemeinschaft eine zweite Meinung einholt — mit allen Konsequenzen für Workflow, Zeitplan und Lead-Bindung.

Typische Integrationsaufwände

Kosten variieren mit der Reife der Plattform; Standard-Integrationen liegen erfahrungsgemäß im unteren fünfstelligen Bereich an Einmalentwicklung. Das ist niedriger als die Software- und Schulungs-Investition für ein eigenes DIN-V-18599-Modul — und es entlastet die eigene Roadmap von jedem zukünftigen GModG-Update.

Wenn Sie wissen wollen, wie die Architektur konkret im Vergleich zu Makler-CRMs und Immobilienportalen aussieht, beschreibt das der Grundlagen-Artikel Energieausweis-API für Online-Portale.

FAQ für Plattform-Entscheider

Was kostet die API-Nutzung für unsere Plattform? Für Plattform-Partner ist die API-Nutzung kostenfrei. Bezahlt wird der einzelne Ausweis vom Endkunden — der Aussteller liefert das fertige Produkt zurück in Ihre Plattform. Damit fällt das klassische SaaS-Lizenz-Argument weg, das in Vendor-Reviews regelmäßig blockiert.

Können wir die API zunächst in einer Sandbox ausprobieren? Ja. Test- und Produktions-Umgebung sind getrennt, Bearer-Token werden je Umgebung getrennt ausgegeben. Die interaktive OpenAPI-3.1.2-Referenz erlaubt es, einzelne REST-Endpunkte direkt im Browser zu testen — cURL-, fetch- und axios-Snippets sind direkt aus der Scalar-Konsole kopierbar.

Müssen wir die DIN-V-18599-Software selbst lizenzieren, wenn wir die API nutzen? Nein. Der Aussteller bringt Software, Gütesiegel-Lizenz und die ausstellungsberechtigte Person mit. Sie konsumieren nur die API — § 88 GModG-E spielt für Sie keine Rolle, weil die Plattform den Ausweis nicht selbst ausstellt.

Wie kommen wir an die 24 Monatswerte aus den HeizkostenV-Daten? Über zwei Wege: ein Adapter zu den Messdienstleistern (Techem, ista, Brunata-Minol, KALO) oder ein Upload-Modul, in dem der Verwalter die Monatsdaten als CSV/Excel-Datei zuliefert. Beides läuft im Pilot in 2–6 Wochen — und wir kennen die typischen Quirks der einzelnen Messdienst-Exporte aus der laufenden Praxis.

Können wir White-Label-Branding bekommen? Ja. Logo der Plattform im Bestellprozess und auf dem PDF; der Endkunde verlässt nicht die vertraute Marke. Eine bestehende Referenz-Integration mit Immodio zeigt das White-Label-Setup im produktiven Einsatz.

Was passiert mit Bestands-Ausweisen, die vor GModG ausgestellt wurden? Sie bleiben 10 Jahre gültig (§ 112 GModG-E, Übergangsvorschrift). Für die Plattform heißt das: kein Migrationsaufwand für bereits gespeicherte Stamm-Ausweise; nur die nach Inkrafttreten neu ausgestellten Ausweise folgen dem neuen Schema.

Wie schnell sind GModG-Updates in der API verfügbar? Automatisch über die API-Versionierung. Sobald der Aussteller-Stack das neue GModG-Schema (Klasse A+–H, Anlage 10a Pflichtangaben, Anlage-4-PEF Strom 1,5 / Holz 0,7) ausliefert, kommen die strukturierten Pflichtfelder über dieselben Endpunkte zurück — kein Plattform-Release nötig.

Fazit: Vier Paragraphen, ein Plattform-Feature

Mit dem GModG-Entwurf wird der Energieausweis vom punktuellen Pflichtdokument zur wiederkehrenden Plattform-Funktion für Hausverwaltungs-SaaS. § 80 macht aus jeder Mietverlängerung einen Workflow-Trigger; § 82 verlangt ein Monatsraster im Datenmodell; § 84 verwandelt Modernisierungsempfehlungen in eine strukturierte Datenquelle für WEG-Sanierungspläne; § 87 zwingt Inseraten-Module zum automatischen Pre-Fill aus der Stammakte. Das Inkrafttreten am Tag nach der Verkündung lässt für die genannten Paragraphen keine Schonfrist; das Implementierungs-Fenster öffnet sich mit der Verkündung, nicht erst sechs Monate später.

Wer den Ausweis im eigenen Stack hält statt nach außen zu verlinken, behält drei Dinge: den Verwalter im System, den Endkunden im Branding und die Compliance-Verantwortung beim Spezialisten. Eine API-Integration in 8–12 Wochen Pilot-Aufwand kostet weniger als ein eigenes Berater-Team — und sie skaliert mit jedem neuen GModG-Update automatisch mit. Konkret heißt das für die nächsten zwei Wochen: einen Use-Case im Backlog priorisieren, das wohneinheit × energieträger × monat-Schema entwerfen und eine Referenz-Verwaltung als Pilotpartner gewinnen.

Drei nächste Schritte für die Plattform-Roadmap:

• API-Dokumentation öffnen: /api — OpenAPI 3.1.2 mit Scalar-Try-it, Bearer-Auth-Sandbox.
• Pilot vereinbaren: /kontakt — Onboarding-Gespräch mit dem Engineering-Team.
• Pillar-Faktencheck lesen: Die A–G-Skala kommt — nur nicht für Ihr Wohnhaus.