Skip to content
Law & data protection

Property Listings: Mandatory Energy Certificate Data

If an energy certificate exists, every property listing needs five mandatory details. Here is how they become required fields in the record, appear in list, detail page and PDF, and flag their own expiry.

13 min read ImmobilienEnergieausweisPflichtangabenHildesheim

In short and in plain language

Do you show houses or flats on your website? If an energy certificate exists, some details must be in the listing. This also applies to your own site.

It shows how much energy a building needs. The listing must include things like its type, its value and the heating. Missing details can lead to a fine.

With free text, it is easy to miss something. Fixed required fields work better. Then the details show in the list, on the page and in the PDF.

An energy certificate does not last forever. A date in the system can warn you before it runs out.

We build these fields into the site for agents and property managers.

A property is supposed to go online today. The photos are cropped, the copy is written, the address is correct - and the energy performance certificate sits in a folder as a PDF because nobody feels like opening it. This is exactly where the expensive mistake starts: as soon as an energy certificate exists, Section 87 (1) of the German building modernisation act (GModG) requires five details to appear in the property listing. Leaving them out is a regulatory offence, and the framework goes up to a fine of ten thousand euros (Section 108 (2) GModG). This article is not a legal guide but a build manual for property management: how the five details become mandatory fields in the record, how their output is enforced in the result list, on the detail page and in the listing PDF, and how the ten-year period turns into a warning that raises itself. Written for estate agents, property managers and developers in Hildesheim, Sarstedt, Laatzen and Hameln who show their properties on their own site - the framework for that is described under web design for property professionals.

Key takeaways

  • The duty applies as soon as an energy certificate exists and a property listing is placed in commercial media. Your own agency website is such a medium, not a protected inner room.
  • Five details under Section 87 (1) GModG belong in every listing: the type of certificate, the final energy demand or consumption figure, the main energy sources used for heating, and for residential buildings the year of construction and the energy efficiency class.
  • Free text forgets things, a mandatory field does not. Five separate fields in the property record plus a block before publication solve the problem at the root - and feed the list, the detail page and the PDF at the same time.
  • An energy certificate is issued for a validity period of ten years (Section 79 (3) GModG). Keeping the issue date as a data field turns that into an expiry warning long before a property with an expired certificate is online.
  • Missing mandatory details are a regulatory offence (Section 108 (1) no. 21 GModG) with a framework of up to ten thousand euros. The effort for the technical safeguard is considerably below that.

When the duty applies - and whom it hits

The provision is shorter than its reputation suggests. Section 87 (1) GModG ties three conditions together that must all be met at once: the matter concerns the sale, letting, leasing or lease-financing of a building, a flat or another self-contained unit; a property listing is placed in commercial media for it; and at that moment an energy certificate exists. If all three are met, the listing has to carry the mandatory details - not four of them, not in substance, and not outsourced into a linked PDF, but inside the listing itself.

Whom the duty hits is written in the same sentence: the seller, the landlord, the lessor, the lease provider or the estate agent, where one of those persons is responsible for publishing the listing. On your own website that question answers itself, because nobody else decides what appears there. A portal can enforce mandatory fields because it has built them in; your own property management only does so if somebody built it that way.

The phrase commercial media is often talked down. It covers any listing placed in the course of business: the property page of the firm, the property archive, the teaser card on the home page and the listing document an interested party downloads. Anyone who maintains the mandatory details only inside a portal and treats their own site as a shop window is missing them precisely where they would have full control. How far mandatory information on a company website reaches otherwise is covered in legal notice requirements under the DDG.

No certificate, no mandatory details - but keep a note

The duty depends on an energy certificate existing. Under Section 79 (4) GModG the provisions of that part do not apply to a small building; there the duty never arises in the first place. That is not a licence to leave things out but a piece of information that belongs in the record: a field for whether a certificate exists, including the reason, so that nobody has to guess later why a property went online without the five details.

The five details as data fields, not as free text

The difference between a complete and an incomplete listing is rarely unwillingness; it is almost always free text. Where the property description is one large text area, the mandatory details drift to the end of a paragraph, and with the next property one of them is missing because the template was copied and only half adjusted. Five separate fields fix that at the root: an empty mandatory field stops publication, a forgotten half-sentence does not.

Type of certificate

A select field with exactly two values: demand-based certificate or consumption-based certificate. Section 87 (1) GModG asks for the type explicitly, and the two versions are not the same thing - one calculates the building, the other evaluates recorded consumption. As a select field nothing third can appear here and nothing can stay empty.

Figure with a fixed unit

The final energy demand or final energy consumption figure stated in the certificate belongs in a numeric field with a stored unit, not in a sentence. Kilowatt hours per square metre and year is the unit the certificate uses; it belongs in the output and not in the hands of whoever happens to be typing.

Sources, year, class

The main energy sources for heating are a multi-select from a fixed list, the year of construction stated in the certificate is a four-digit year field, the energy efficiency class is a select field. The last two are mandatory for a residential building - for a non-residential building they fall away, and that is exactly what the record has to be able to tell apart.

A non-residential building actually demands more: under Section 87 (2) GModG the final energy demand or consumption has to be stated there separately for heat and for electricity. One figure field therefore becomes two as soon as the property type is set to non-residential. Anyone who does not model this in the record will eventually write the second figure into the description text - and then it sits on the detail page but not in the result list and not in the listing PDF.

The energy efficiency class is not a free assessment. Under Section 86 (2) GModG it follows directly from the final energy consumption or final energy demand; the scale is set out in Annex 10 to the act and runs from A+ to H. In the record that is a select field with nine steps, and the selection can be checked against the figure entered: anyone who enters 180 kilowatt hours per square metre and year and picks class B gets a warning before the property becomes visible.

Mandatory detail under Section 87 (1) GModGField in the property recordWhat goes wrong in free text
Type of energy certificateSelect: demand or consumptionThe type is missing entirely because only a figure is given
Final energy demand or consumption figureNumber with a stored unitThe unit is missing or changes from property to property
Main energy sources for heatingMulti-select from a fixed listPhrases such as "modern heating" instead of the actual source
Year of construction per certificate (residential)Four-digit year fieldThe building's year is confused with the one stated in the certificate
Energy efficiency class (residential)Select from A+ to HThe class is estimated instead of read off the certificate
Non-residential: heat and electricityTwo separate figure fieldsThe second figure ends up in the description text

One field per detail - and a block before publication

The check belongs on the switch that makes a property visible, not in a reminder email. As long as one of the mandatory fields is empty and no reasoned note saying no certificate is required has been set, the switch stays locked. That is inconvenient when things need to move fast, and that is exactly why it works. A block that can be waved through with one click is not a block.

Enforcing the output in every place

A neatly filled record is of little use if the details only appear on the detail page. A property shows up in several places, and each of them is a listing: the result list, the card on the home page, the property archive, the internal search results, the listing PDF and the print view. If a detail is missing in one of those places, the duty is not met there - no matter how complete the detail page looks.

Technically the answer is unspectacular and durable for exactly that reason: a single output component that renders the five details from the record and is included everywhere a property appears. No second construction site, no copy in the template text, no special case for the home page. Whoever includes the same component in six places changes it once when something changes - and misses no place while doing so.

  • Result list and filter results: the details in short form under every card, not only after the click.
  • Detail page: the full version with unit, the certificate type spelled out and the issue date.
  • Listing PDF: generated by the same component from the same record, never a separately maintained document.
  • Card on the home page and in the property archive: a three-line teaser is a listing too.
  • Internal search and preview link: the preview shows what would be published, mandatory details included.
  • Print view and email dispatch: whatever leaves the firm carries the same details as the page.

For readability it pays to keep the order the statute uses anyway: type, figure, energy sources, year, class. Always printing the same sequence makes a missing detail visible instead of hiding it. And because the details sit in the record in a structured way, they can be passed along as structured data in the same step, without anyone typing them a second time.

Terminal
$ rg -l "mandatory_block" templates/
templates/property-detail.html templates/property-card.html templates/listing-pdf.html ; Three templates include the component - the result list is missing.
$ rg -c "mandatory_block" templates/property-list.html
0 ; Exactly the place that was overlooked on the first pass.
$ jq -r '.[] | select(.certificate.type == null) | .id' properties.json | wc -l
4 ; Four properties without a certificate type - clarify before the next publication.
$ jq -r '.[] | select(.certificate.issued_on < "2019-10-01") | .id' properties.json
hi-2026-014 hi-2026-031 ; Two certificates expire within the next twelve months.

Searches like these do not replace a look at the finished page, but they show in seconds where an output place was forgotten. After that comes the comparison on a real property: publish in draft mode, look at the result list, the detail page and the listing document, and compare the three outputs line by line. Whatever reads identically in all three is done; everything else is an open item.

Ten years becoming an expiry warning

Under Section 79 (3) GModG an energy certificate is issued for a validity period of ten years. Ten years is long enough that nobody remembers on their own, and short enough that in a portfolio of thirty properties one of them is affected regularly. The issue date therefore belongs in the record as its own date field and not as a subordinate clause in the description, because only a date field lets you calculate a warning.

  1. Capture the issue date as a mandatory field the moment the certificate is attached to the property. The system derives the expiry date from it instead of letting someone type it.
  2. Set two thresholds: an early warning six months before expiry and a hard limit on the expiry day. The first appears in the property overview, the second blocks publication.
  3. Put the warning where the work happens - as a column in the property list and as a note inside the property itself, not as an email that drowns in an inbox.
  4. Do not quietly hide expired certificates. A property that is to stay online needs a new certificate; a property that goes offline needs a note saying why.
  5. Add the cut-off date to ongoing maintenance: once a quarter, a report on every property whose certificate expires within the coming year.

Ten years is the ceiling, not a promise

A certificate can lose its validity earlier: independently of the period it ends when a new energy certificate becomes necessary under Section 80 (2) GModG - for instance after changes to the building for which the whole building is recalculated. The ten-year period is therefore a ceiling, not an assurance. In the record that means a second field for invalid since, with a reason, which overrides the calculation from the issue date.

The period has a second, practical use: it is the natural occasion to go through the whole portfolio once. Anyone who gets the early warning half a year ahead can commission the new certificate calmly instead of pulling a property offline at short notice. For a running portfolio this is the same thought as in website maintenance: a fixed rhythm beats any reminder kept in someone's head.

Special cases that shape the record

Three cases turn up in almost every portfolio that has grown over time, and all three are a question of data modelling, not of wording. Building them into the fields from the start saves a march through every property later on.

The old certificates first. For energy certificates issued after 30 September 2007 and before 1 May 2014, Section 87 applies under Section 112 (3) GModG with special provisos: the figure to be stated is determined differently there depending on the type of certificate and the type of building, and for residential buildings that do not yet state an energy efficiency class it may be given voluntarily. In the record the issue date plus a flag derived from it is enough; the output then decides which field it shows and which it demands.

The second case is the consumption-based certificate. Under Section 82 (4) GModG it has to be based on billing data covering at least a continuous period of 36 months. That changes nothing about the five mandatory details, but a lot about the conversation with an interested party: a consumption figure also describes the behaviour of the previous occupants, while a demand figure calculates the building. Anyone who keeps the certificate type cleanly in the record can explain that difference in one sentence on the detail page instead of repeating it on the phone.

The third case concerns not the listing but what comes after it: under Section 80 (4) GModG the seller or the estate agent has to present an energy certificate or a copy of it to the prospective buyer at the viewing at the latest. That is not a job for the website - but the website can keep the certificate file attached to the property so that nobody has to search during the appointment. A side case concerns public administration: for a building with more than 250 square metres of usable floor area with heavy public traffic resulting from official use, Section 80 (6) GModG requires an energy certificate and its display.

CaseWhat is added to the recordWhat changes in the output
Non-residential buildingSecond figure field for electricityState heat and electricity separately, Section 87 (2) GModG
Certificate from the years 2007 to 2014Flag derived from the issue dateFigure source per Section 112 (3) GModG, class voluntary
Consumption-based certificateCertificate type as a select fieldA note about the data basis of 36 months
Small buildingNote saying not required, with a reasonThe mandatory block falls away, the reason stays internal
Expired certificateExpiry date derived from the issue datePublication blocked, warning in the overview
Viewing appointmentCertificate file attached to the propertyNo output place on the site, but one grab at the appointment

What a missing detail can cost

Anyone who, contrary to Section 87 (1) GModG, fails to ensure that the property listing contains the mandatory details named there commits a regulatory offence under Section 108 (1) no. 21 GModG. The framework under Section 108 (2) GModG is a fine of up to ten thousand euros. On top of that comes the competition-law side, which in practice often bites faster than an authority: an incomplete listing can be challenged, and the effort for that is far smaller than the effort for fine proceedings.

The pass through the existing portfolio

On an existing site the order decides everything, otherwise you correct outputs that sit on incomplete data. First create the fields, then import the existing properties and make the gaps visible, then switch the output over - and only after that arm the block. Starting the other way round locks out half the portfolio, and the check gets switched off again in frustration after two days.

property.json
{
  "id": "hi-2026-014",
  "building_type": "residential",
  "energy_certificate": {
    "exists": true,
    "type": "consumption",
    "final_energy": 148.0,
    "unit": "kWh/(m2 a)",
    "energy_sources": ["natural_gas", "district_heating"],
    "construction_year_per_certificate": 1994,
    "efficiency_class": "E",
    "issued_on": "2019-04-02",
    "valid_until": "2029-04-01"
  }
}

The valid_until field is shown here for illustration only: it is calculated from the issue date so that no second value has to be maintained which could drift apart later. Everything else is deliberately kept flat. The less nested the record is, the easier it is to output in the result list, on the detail page and in the listing PDF - and the easier a later move to another system becomes.

  • Create the fields and use the building type as a switch, so that a non-residential building gets two figure fields.
  • Import the portfolio and produce a list of the gaps: one property per row, one field per column.
  • Fill the gaps from the certificates on hand, not from memory. Whatever is missing stays empty and gets requested.
  • Build the output component and include it everywhere a property appears.
  • Hold the preview against the published version - what the preview shows has to be live as well.
  • Only at the end arm the block, and counter-check it with a deliberately incomplete test property.

The last point is the most important one and the most frequently skipped. A block that has never seen an error is an assumption with a timestamp. A test property without energy sources that can still be published answers the question in thirty seconds - and does so before somebody outside asks it.

Two neighbouring topics belong in the same pass because they hang off the same property data: the rights situation of the property photos, described in image rights on your website, and the question of how openly a listing deals with figures - more on that in publishing prices on your website. If every property is being touched once anyway, both can be done in one go.

If the property page also works with voices of satisfied sellers or with seals, the same pass is the best moment to check the evidence needed for those: customer testimonials on your website and master craftsman titles and seals describe what has to be provable and what is better left out.

Property pages are image-heavy, so loading behaviour deserves a look in the same step: a block of mandatory details costs nothing, an unchecked set of images does - what counts there is set out in Core Web Vitals 2026. That the details are also reachable with a keyboard and a screen reader is not an extra but part of accessibility: a table with marked-up header cells does most of that work.

For firms in the surrounding area the effort pays off twice. A property listing that stands complete and structured on its own site can be placed better in local search than one that is only complete inside a portal. What that looks like for a location between Hildesheim and Hannover is shown on the page about the web agency in Sarstedt.

A mandatory detail that depends on one person's diligence is not a mandatory detail but a hope. A required field is the entire difference.

Internetagentur Hildesheim

Sources and legal basis

This article draws on the official text of the German building modernisation act in the version published on gesetze-im-internet.de, in particular on Sections 79, 80, 82, 86, 87, 108 and 112 as well as Annex 10. The statements describe the state of the version available there; in an individual case this does not replace legal advice.

Related Articles

Law & data protection

Email signatures: the mandatory details for businesses

Business emails count as business letters in Germany. Which mandatory details each legal form must put in the signature, with a sample and a year-end checklist.

21 min read
SEO & local visibility

Local Backlinks: How Hildesheim Businesses Build Them

Links from your club, guild, supplier and local paper feed into your business's prominence. How to earn them and when a link has to be marked sponsored.

20 min read
Web design & conversion

Menus online: current, readable and with allergen labels

Why an online menu carries mandatory information, how allergens and additives are labelled legibly, and where PDF menus fail on the screen of a phone.

14 min read