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

Joost Jansky

Energy consultant, blogger

Note: Section references relate to the promulgated GModG (BGBl. 2026 I No. 226). For the overview of the certificate reform from 2027, see the hub article.

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 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 preparing consumption data.

§ 82 — annual consumption data over two years

From 1 January 2027, § 82 GModG requires annual, energy-carrier-differentiated consumption data over two years; the most recent period may be no more than 18 months old. The consumption-based certificate is only allowed for exclusively residential use — mixed use usually leads to a demand-based certificate under § 81.

For the platform architecture, this means a schema building × energy_carrier × year = kWh (two periods), not a 24-month grid. 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 clean annual periods per energy carrier — separated for heating, hot water and cooling. Monthly § 6a data remain the raw material; for § 82 aggregation is enough. The flat-rate add-ons of +16 kWh/(m²·a) for hot water and +6 kWh/(m²·a) for cooling remain permitted under § 82 when consumption is not known.

§ 84 — modernisation recommendations as structured data

§ 84 GModG 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 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) 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: Article 2 from 1 January 2027

The promulgated GModG (BGBl. 2026 I No. 226) sets fixed cut-off dates — no longer “six months after promulgation”:

For property-management platforms that means clearly: §§ 80, 82, 84, 87 and § 108 take effect from 1 January 2027 (Article 2) — not on promulgation day (28 July 2026). Article 1 (renaming and heating reform) has applied since 29 July 2026 but brings no new certificate duties.

A realistic implementation window: anyone who starts an API integration today can ship a productive integration before the cut-off — provided the schema migration for annual periods × energy carrier 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 annual consumption data 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 annual consumption data actually come from

For let units, the data that § 82 GModG 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.

Monthly § 6a data are the raw material; from 2027, § 82 needs two annual periods per energy carrier (most recent period ≤ 18 months). Three gaps remain:

• Owner-occupied single-family homes outside the HeizkostenV scope — often only yearly bills for gas, oil or pellets (frequently enough for § 82 if two periods exist).
• Mixed use — the consumption-based certificate only for exclusively residential use; otherwise a demand-based certificate under § 81.
• Data-format heterogeneity — Techem, ista, Brunata-Minol and KALO deliver 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 — 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: annual periods over two years per energy carrier (building × energy_carrier × year), 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/TS 18599:2025-10 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/TS 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/TS 18599 software ourselves if we use the API? No. The issuer brings the software (DIN/TS 18599:2025-10), the quality-mark licence and the person authorised to issue. You only consume the API — § 88 GModG does not apply to you because the platform does not issue the certificate itself.

How do we obtain the annual consumption data over two years from the heating-cost ordinance 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 annual periods per energy carrier as a CSV or Excel file. From 1 January 2027, § 82 requires annual data over two years (most recent period ≤ 18 months), not 24 monthly values. Both run in a 2- to 6-week pilot.

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 usually remain valid for 10 years. For the platform this means: no migration burden for certificates already stored in master files; only certificates newly issued from 1 January 2027 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 GModG schema (class A+ to H, annex 10a mandatory fields, DIN/TS 18599:2025-10), the structured mandatory fields come back over the same endpoints — no platform release required.

Conclusion: four sections, one platform feature

With the promulgated GModG, 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 requires annual periods over two years per energy carrier; § 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. Article 2 applies from 1 January 2027 — the implementation window closes on that cut-off.

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 building × energy_carrier × year 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.
• Hub on the certificate reform: New energy certificate from 1 January 2027.