GModG for Property-Management Platforms: Integrating the Energy Certificate as a Platform Feature via API

Joost Jansky

Energieberater, Blogger

Note — cabinet draft, not yet binding law. Status: cabinet decision of 13 May 2026. Entry into force only after the Bundestag, Bundesrat and promulgation. Section references point to the GModG cabinet draft; for the full fact-check see the pillar article on the cabinet draft.

What changes for property managers under the GModG

Four sections move the energy performance certificate out of the issuer's office and into the property manager's day-to-day business — and therefore into your platform:

These four duties land directly in the property manager's daily routine. Platforms that absorb them in their own workflow keep the property manager inside the system; platforms that only link out hand the touchpoint and the lead to a third-party provider. Which of these duties translates how into a platform workflow — let's look at them one by one.

Four GModG sections, four platform workflows

§ 80 — lease renewal becomes the new issuing trigger

§ 80 (3) GModG draft expands the list of occasions on which an energy performance certificate must exist. From now on, a certificate must be issued whenever a building, an apartment or a self-contained usable unit is to be "let, leased or rented, or such a tenancy, lease or rental contract is to be renewed" — unless a valid certificate already exists for the building. The explanatory memorandum to the cabinet draft is explicit: "now also for lease renewals, and not only when a tenancy contract is concluded", a certificate is required.

For your platform that means: the lease-management module becomes a trigger. Every contract renewal has to fire a certificate status check — question 1: is a valid certificate in place? Question 2: does the validity cover the new contract term? Question 3: does the certificate type (demand-based, consumption-based, smart) match the constellation? Whoever runs this logic manually today will move it into an automatic workflow after entry into force. The end-customer perspective on this duty is covered in the sister articles on the new freedom of choice for the consumption-based certificate and on getting ready for 24 monthly values.

§ 82 — 24 monthly values per energy carrier in the consumption-based certificate

§ 82 (1) sentence 2 GModG draft requires significantly more granular source data than current law. From now on, final energy consumption must be "recorded, differentiated by energy carrier, at least monthly over 24 consecutive months". The underlying EU rule — Annex I number 1 sentence 5 of the EU Energy Performance of Buildings Directive (EU) 2024/1275 — is unambiguous: monthly, and separated by energy carrier.

For the platform architecture, this means shifting from a yearly aggregate to a matrix unit × energy_carrier × month = kWh. In concrete terms, each building grows a table of the form:

Anyone who imports the heating-cost-ordinance bill on a yearly basis today from Techem, ista, Brunata-Minol or KALO portals will need to store this monthly grid cleanly from now on, separated for heating, hot water and cooling. The flat-rate add-ons of +16 kWh/(m²·a) for hot water and +6 kWh/(m²·a) for cooling remain permitted under § 82, but they do not change the underlying monthly grid.

§ 84 — modernisation recommendations as structured data

§ 84 GModG draft implements Art. 19 (7) to (9) of the EU EPBD and requires a quantified renovation roadmap inside the certificate: estimated energy saving per measure, estimated greenhouse-gas saving, assessment of the remaining useful life of heating and air-conditioning systems, and a low-temperature suitability check (heat pump). The recommendation duty is waived only in classes A+ and A.

For the platform, the question is not whether the issuer supplies these values — it is how. If you receive the recommendations only as a PDF image, they are not reusable for condominium refurbishment plans and owner reports. An API that returns the modernisation recommendations as a structured JSON list — per measure with the fields label, saving_kwh_per_year, saving_ghg_kg_co2, investment_gross_eur, heating_remaining_life_years, low_temperature_suitable — turns every certificate into a reusable data source: for the next owners' meeting, for the condominium association's renovation roadmap and for subsidy advice (BEG-EM, individual renovation roadmap).

§ 87 — mandatory data from the master file for every listing

§ 87 GModG draft requires, in every commercial property listing, mandatory information that comes directly from the certificate: certificate type (demand-based or consumption-based), final or primary energy demand/consumption in kWh/(m²·a), the energy efficiency class (for residential buildings still A+ to H), the main heating energy carriers, and the year of construction. A transitional rule (§ 112 GModG draft) applies to certificates issued before entry into force. What this means for estate agents is covered in the sister article GModG for estate agents.

For property-management platforms with a letting or exposé module, this is a pre-fill problem: if the platform keeps the certificate mandatory fields structured in the master file, every new listing can be filled automatically and correctly — without typos, without classes guessed from memory, and without the risk of an unfair-competition warning letter.

Timeline: Art. 9 GModG and the real implementation window

Art. 9 GModG draft is the single most important section for your sprint planning — and the one most regularly mis-summarised in public reporting:

So the often-cited "six-month grace period" is no grace period at all. The six-month period applies to consequential amendments in other statutes, not to the certificate duties themselves. For property-management platforms that means: §§ 80, 82, 84, 87 and § 108 take effect with promulgation.

A realistic implementation window therefore looks like this: if the Bundestag and Bundesrat give their consent during the summer or autumn session of 2026, promulgation would follow a few weeks later. Anyone who starts an API integration today can ship a productive integration inside that corridor — provided the schema migration for 24 monthly values and modernisation-recommendation data is parallel-tracked in the backlog.

Where it gets hard: HeizkostenV data and make-or-buy

Anyone translating the four sections into a backlog will quickly hit two pain points: where do the 24 monthly values actually come from, when the property manager has no direct meter access? And is it realistic to issue the certificate inside the platform itself — or does an issuer have to deliver it? Both questions can be answered clearly today.

Where the 24 monthly values actually come from

For let units, the data that § 82 GModG draft requires exists already today — it comes from the Heating-Cost Ordinance (HeizkostenV). § 5 (2) HeizkostenV requires all existing heating and hot-water meters to be retrofitted to remotely readable devices by 31 December 2026. Where remotely readable equipment is in place, § 6a HeizkostenV additionally applies: owners and property managers must provide users with monthly consumption information — current consumption, comparison with the previous month and the same month a year earlier, and a benchmark against a standard user.

That monthly grid is precisely the basis for § 82 GModG draft. Three gaps remain:

• Owner-occupied single-family homes outside the HeizkostenV scope — no structured monthly data, only yearly bills for gas, oil or pellets.
• Transition phase 2026–2028 — even after the retrofit deadline, it takes months before gap-free 24-month histories from remotely readable devices are available.
• Data-format heterogeneity — Techem, ista, Brunata-Minol and KALO deliver monthly data through their own portals and APIs in different structures. A common industry standard does not yet exist.

Platforms therefore need two layers: a data adapter to the metering service providers and an upload module for cases in which the property manager submits documents manually. Both are one-off investments — and they pay off as soon as consumption-based certificates move from special case to routine.

Three options for certificate provisioning

For property-management platforms the make-or-buy verdict is usually unambiguous. Three paths are open, and only one scales:

Option (a) generally fails because of § 88 GModG draft — the entitlement to issue a certificate is tied to the person and cannot be substituted by a software licence. Option (b) is the de-facto standard on many platforms today; it works, but every order costs you the lead contact and your own touchpoint. Option (c) is the third path, deepened in the next section.

How to plan the integration today

A realistic pilot starts with a clearly scoped workflow, not with a full integration. Three building blocks have proven themselves:

1. Use-case workshop. Which workflows trigger a certificate order? Owner changes, lease renewals, condominium refurbishment resolutions, an existing certificate approaching expiry. Which workflows need data back? The listing module, the condominium refurbishment plan, the owner report and the master file.
2. Data model and audit trail. Mandatory fields in the schema: 24 monthly values per unit and energy carrier, DIBt registration number, date of issue, expiry date (10-year validity) and PDF hash. Condominium resolution documentation: who commissioned what and when? Audit trail inside the property-management system for at least ten years.
3. Pilot with a reference property manager. A property manager with around 500 units, one clearly scoped workflow (for example only owner changes in the first step), two to four sprints. Success metrics: time per order, drop-off rate, data completeness, number of follow-up queries per order.

If you want to put the three building blocks alongside your first sprint as a pre-flight checklist, it looks like this:

Under condominium law, § 27 WEG entitles the property manager to take measures of ordinary administration of "subordinate importance" ((1) no. 1) or "to avert detriment" ((1) no. 2) without an individual resolution — the routine ordering of an energy certificate where a § 108 fine is looming can regularly be brought under no. 2. § 19 WEG (ordinary administration) additionally requires deadline monitoring; alerting on expiring certificates in good time is a core duty of the property manager. If that is missed culpably, liability under the management contract — backed by professional indemnity insurance — is the more likely sanction than the fine. For exactly that reason, the platform is the better carrier of the deadline logic than the Outlook inbox of an individual case handler.

Solution: the Energyausweis API as a platform building block

Architecture in one paragraph

The Energyausweis API connects a property-management platform to the issuer stack through a REST interface with OpenAPI 3.1.2 specification, rendered with Scalar as an interactive "Try it" console — you can execute a call against the test environment directly in the browser, with cURL, fetch or axios snippets ready to copy. Authentication runs through a Bearer token per partner, with separate test and production environments. Images and documents flow via presigned-URL upload directly from the platform to the issuer's storage layer — you don't need to run your own storage stack. Status and mandatory fields (class, kWh, energy carrier, year of construction, date of issue, DIBt registration number, expiry date) come back as structured JSON; the finished certificate is available as a PDF download. Status polling is the default; webhooks are available on partner onboarding if you need them.

Trust anchors that hold up in the owners' meeting

API integration solves the technical question. The second, often underestimated question is one of credibility: behind the certificate, is there a person authorised to issue, a vetted methodology, an unambiguous registration? Seven anchors can be named concretely in the owners' meeting and in a compliance audit:

• Certified energy consultants issue every certificate — not pure automation, but personal review per order.
• DIN V 18599 quality mark of the Gütegemeinschaft Gebäudebilanzierung e. V. — the calculation software in use is quality-assured.
• DIBt registration by the Federal Institute for Building Technology (DIBt) — every certificate carries an unambiguous registration number that remains referenceable in the audit trail.
• Existing platform partnership with Immodio — a productive integration, available as a reference.
• OpenAPI 3.1.2 + Scalar Try-it — developer onboarding without a sales process.
• White-label branding — your platform's logo in the ordering flow and on the PDF; the end customer keeps seeing the familiar brand.
• GModG updates arrive through API versioning — the platform does not have to track legal changes itself.

None of these is a marketing argument. In owners' meetings and vendor reviews they regularly decide whether the platform is accepted as the certificate source or whether the community fetches a second opinion — with all the consequences for workflow, schedule and lead retention.

Typical integration efforts

Costs vary with the maturity of the platform; based on experience, standard integrations sit in the low five-digit range as a one-off development cost. That is below the software and training investment for an in-house DIN V 18599 module — and it relieves your own roadmap of every future GModG update.

If you want to see how the architecture looks in concrete comparison to estate-agent CRMs and property portals, the foundation article on the Energyausweis API for online portals lays that out.

FAQ for platform decision-makers

What does using the API cost our platform? For platform partners, API usage is free of charge. The end customer pays for the individual certificate, and the issuer returns the finished product into your platform. This removes the classic SaaS-licence argument that regularly blocks vendor reviews.

Can we try the API in a sandbox first? Yes. Test and production environments are separated, and Bearer tokens are issued separately per environment. The interactive OpenAPI 3.1.2 reference lets you execute individual REST endpoints directly in the browser — cURL, fetch and axios snippets can be copied straight from the Scalar console.

Do we have to license DIN V 18599 software ourselves if we use the API? No. The issuer brings the software, the quality-mark licence and the person authorised to issue. You only consume the API — § 88 GModG draft does not apply to you because the platform does not issue the certificate itself.

How do we obtain the 24 monthly values from the HeizkostenV data? Through two routes: an adapter to the metering service providers (Techem, ista, Brunata-Minol, KALO) or an upload module in which the property manager submits the monthly data as a CSV or Excel file. Both run in a 2- to 6-week pilot — and we know the typical quirks of the individual metering exports from live practice.

Can we get white-label branding? Yes. The platform logo appears in the ordering flow and on the PDF; the end customer never leaves the familiar brand. An existing reference integration with Immodio shows the white-label setup in productive use.

What happens to existing certificates issued before the GModG? They remain valid for 10 years (§ 112 GModG draft, transitional provision). For the platform this means: no migration burden for certificates already stored in master files; only certificates newly issued after entry into force follow the new schema.

How quickly do GModG updates become available in the API? Automatically through API versioning. As soon as the issuer stack delivers the new GModG schema (class A+ to H, annex 10a mandatory fields, annex-4 primary-energy factors of 1.5 for electricity and 0.7 for wood), the structured mandatory fields come back over the same endpoints — no platform release required.

Conclusion: four sections, one platform feature

With the GModG draft, the energy performance certificate moves from a one-off compliance document to a recurring platform function for property-management SaaS. § 80 turns every lease renewal into a workflow trigger; § 82 forces a monthly grid into the data model; § 84 converts modernisation recommendations into a structured data source for condominium refurbishment plans; § 87 forces listing modules to pre-fill automatically from the master file. Entry into force on the day after promulgation leaves no grace period for the sections named here; the implementation window opens with promulgation, not six months later.

Anyone who keeps the certificate inside their own stack instead of linking out keeps three things: the property manager in the system, the end customer in your branding, and compliance responsibility with the specialist. An API integration in 8 to 12 weeks of pilot effort costs less than an in-house consultant team — and it scales automatically with every future GModG update. In concrete terms, the next two weeks mean: prioritise one use case in the backlog, draft the unit × energy_carrier × month schema, and line up a reference property manager as a pilot partner.

Three next steps for the platform roadmap:

• Open the API documentation: /api — OpenAPI 3.1.2 with Scalar Try-it, Bearer-auth sandbox.
• Arrange a pilot: /contact — onboarding conversation with the engineering team.
• Read the pillar fact-check: The A–G scale is coming — just not for your apartment building.