Anyone selling products with an energy label online, from household appliances to smartphones and tablets since June 2025, shows a label on every listing and provides a product information sheet. The framework Regulation (EU) 2017/1369 expressly requires this of the dealer in online distance selling as well, and the supplier registers the underlying data in advance in EPREL, the product database operated by the European Commission. The legal position has been known for years. What many projects lack is the data flow: where in the item master does the efficiency class live, where the label graphic, where the registration number? How do the values reach the product page, the category listing and the marketplace feed in full? And what happens on the day a product group is rescaled and every label in the shop has to be replaced within 14 working days? This article describes fields, routes and cut-over logic from the interface side, not from the legal department.
Key takeaways
- The dealer displays the label visibly in online distance selling too and makes the product information sheet available. Label and sheet come from the supplier, who registers the model in EPREL beforehand.
- Six attributes belong together in the item master: efficiency class, class range, label graphic, product information sheet, EPREL model registration number and a validity date. Whatever is missing there is missing in every channel.
- In a rescaling the new label may only appear from the cut-over date and must be in place online within 14 working days. That is a mass replacement with date-driven control, not a maintenance task.
- The supplier keeps the model data in the product database for 15 years after the last unit is placed on the market. Versioning label data instead of overwriting it lets you prove any earlier state of a listing.
- Since 20 June 2025 smartphones and slate tablets carry their own label with a repairability class and battery values. It sits close to the price, and the information sheet may be shown via a link to EPREL.
What the online store has to show
The framework regulation assigns the roles clearly. The supplier is whoever places a product on the Union market: the manufacturer established in the Union, the authorised representative of a manufacturer from outside, or the importer (Energy Labelling Regulation, Article 2). Since 1 January 2019 the supplier enters every new model into the product database before placing it on the market (Energy Labelling Regulation, Article 4) and provides the dealer with label and product information sheet. The dealer displays the label visibly for every unit, expressly including online distance selling, and makes the product information sheet available to customers (Energy Labelling Regulation, Article 5). For the shop this means the label is not an extra image in the gallery but a mandatory element of the listing. It has to be present on every item that requires a label for as long as the item is sold, and it has to match the model that is actually delivered.
Advertising comes on top. In visual advertisements and technical promotional material for a specific model, supplier and dealer state the energy efficiency class and the range of efficiency classes available on the label (Energy Labelling Regulation, Article 6). The scale runs from A to G (Energy Labelling Regulation, Recital 11). How exactly the label must appear is set by the delegated acts for each product group. For smartphones and tablets, for instance, it is shown on the display mechanism close to the product price (Smartphone Regulation, Annex VIII). For the data flow this means: wherever a model is advertised or listed, the system needs at least the class of the model and the range of the scale, plus the graphic and the information sheet on the product page. Class and range are structured values. If you only hold them as an image, you can neither filter them nor write them into a feed nor check whether they match the graphic.
The fields in the item master
The data flow starts where items are created. Often that is the item master in the ERP, sometimes an upstream PIM system for product data. What matters is that the label data is maintained in exactly one place and every channel reads from that place. A label that the shop editors upload straight into the image gallery does not exist for the marketplace feed. A class that only sits in the marketplace back end is missing from the category filter. What applies to prices and dimensions applies to the energy label as well: clean master data with clear ownership is the precondition for every output. Six attributes belong together:
Efficiency class
A letter as a selection field, not free text. It drives the category filter, the colour of the class arrow and the alternative text in case the graphic cannot be displayed.
Class range
The range available on the label, A to G on the new labels. It belongs to the product group, not the individual item, and changes for all models of the group at once when the group is rescaled.
Label graphic
The supplier's electronic label file with a version identifier and checksum. The shop shows it close to the price; in a nested display it opens from the class arrow.
Product information sheet
As a file from the supplier, as a link to the public part of the product database, or both. For smartphones and tablets such a link must clearly and legibly carry the words product information sheet.
EPREL model registration number
The number under which the model is registered in EPREL. The supplier passes it on to the dealer (EPREL Implementing Regulation, Article 14). It lets you reconcile graphic and information sheet.
Validity
Valid from and valid to for each label version. Only these two date fields turn a replacement into a planned switch and an overwritten value into a traceable history.
Besides these six attributes the interface needs two helper fields that never appear on the page. The first is the product group with its delegated act, because the act determines the scale, the label format and the display rules. The second is the origin of the record: delivered by the supplier, taken from the product database, or created in-house because your own company is itself the supplier as an importer or own-brand seller. Both fields later decide which check applies and who is contacted when something is missing. A label-required flag on the item or product group completes the model. It is the basis for every completeness check, because without it a missing label cannot be told apart from an item that needs none.
Label graphic and information sheet: file or link
There are two routes for the graphic. Either the supplier delivers the label file, in which case it sits on the item as a document and travels through the interface as a media asset. Or it is retrieved via the EPREL model registration number from the public part of the product database, which the Commission sets up and maintains alongside a compliance part (Energy Labelling Regulation, Article 12). For the information sheet the framework regulation expressly allows the dealer to download it from the product database if the dealer lacks it and the function is available for the product (Energy Labelling Regulation, Article 5). For smartphones and tablets the sheet may be shown directly via a link to the product database, provided the link clearly and legibly carries the words product information sheet (Smartphone Regulation, Annex VIII).
For the interface, the question is less which route is allowed than which route can be checked. A file on the item has fixed content, a checksum and a filing date. A link points to a record whose content may change without the shop noticing. A combination has proven itself: the graphic is held as a versioned file in the media store, the information sheet is kept both as a file and as a link, and the model registration number ties both to the register entry. That way every run can compare whether file and register still match. If the class in the register differs from the class in the item master, that is a finding for the queue and not a reason to silently adopt one of the two values.
Build the nested display from master data
energy_label_version
item_no reference to the item master
product_group smartphone_tablet (act 2023/1669)
eprel_no model registration number from supplier
efficiency_class A | B | C | D | E | F | G
scale_from A
scale_to G
label_file label_v2.png, sha256
sheet_file sheet_v2.pdf, sha256
sheet_link address in the public part of EPREL
valid_from 2026-11-02
valid_to empty while the version applies
source supplier | eprel | own_brand
confirmed_on date of the last checkProduct page, category listing, marketplace feed
One label record produces several outputs. Which field goes where should be defined as a fixed field mapping in the interface rather than rebuilt separately for each channel. The usual targets are these:
- Product page: label graphic close to the price, a link to the information sheet labelled product information sheet, and the efficiency class as a structured value for alternative text and screen readers. The graphic comes from the media store, not from an image upload in the shop.
- Category listing and search: class arrow with letter and class range, generated from master data, plus the class as a filter attribute. A filter on energy efficiency class is only as complete as the attribute in the item master.
- Marketplace feed: class, range, address of the graphic, address or file of the information sheet and, where the marketplace provides a field for it, the EPREL number. Field names differ between marketplaces; the marketplace integration translates one source record into every target format.
- Stores and inventory management: where brick-and-mortar retail is involved, the store prints the same label. The ERP inventory integration makes sure the till, the shelf label and the shop know the same label version.
- Advertising and comparison pages: wherever a model is advertised, class and range are needed. If ads or newsletters are fed from the product feed, they inherit the values instead of someone copying them.
The node in between is a middleware layer that reads the label record once, checks it and distributes it to all targets. Before publishing, it checks whether class, graphic and information sheet exist for every item that requires a label, and holds back an incomplete item instead of putting it live without a label. This gate is easier to build than searching afterwards for listings that are already online without a label. It has a second benefit: purchasing sees in the same list which suppliers have not yet delivered their data and can follow up specifically.
Rescaling as a cut-over project
The framework regulation defines rescaling as a term of its own: the requirements for reaching a class within a product group are raised, so a model may carry a lower class afterwards than before (Energy Labelling Regulation, Article 2). As a rhythm, the recitals name a period of about ten years (Energy Labelling Regulation, Recital 18). For the interface, a rescaling is an appointment with three points (Energy Labelling Regulation, Article 11). Four months before the cut-over date the supplier provides the dealer with both labels and the information sheets for products newly placed on the market. Before the cut-over date the dealer must not show the new scale. After the cut-over date the dealer replaces the existing labels within 14 working days, in shops and online alike. In narrowly defined exceptions, for example stock whose supplier has ceased activity and for which no new label can be obtained, the regulation allows sales with the old label for up to nine months after the cut-over date. The interface therefore has to be able to flag such items as an exception instead of reporting them as a gap.
Technically this is a mass replacement with a fixed window. The data for the new scale arrives months ahead but must not become visible ahead. The pattern for this is date-driven control: the new label version is created in the ERP as soon as the supplier delivers it, with valid from set to the cut-over date. Until then it rests next to the current version. On the cut-over date the middleware publishes only the items whose version changes, via a delta sync instead of a full export. That keeps the load on shop and marketplace interfaces small and produces a list against which progress can be measured day by day. Items for which no new label has arrived by the cut-over date are on that list from the start, not only when someone happens to find them.
The most common stumbling block is the image cache. If the new label file has the same name as the old one, the delivery network, browsers and a marketplace's image import may keep serving the old label for a long time even though the data was swapped correctly. That is why the version belongs in the file name or the address. A new address is a new file for every cache, and the old file can remain as evidence. Marketplaces that only re-read images when the address changes receive the new graphic without special handling. If you also compare the checksum of the delivered file with the checksum in the item master, you can see the day after the cut-over whether the new graphic has really arrived everywhere.
| Step | Without date-driven control | With date-driven control |
|---|---|---|
| New labels arrive | Files in a mailbox, filed per item by hand | New label version in the ERP with valid from set to cut-over date |
| Before the cut-over date | New scale may appear too early | New version rests, the shop shows the current one |
| On the cut-over date | Full export or item-by-item editing | Delta run with exactly the affected items |
| Image delivery | Same file name, caches show the old version | Versioned address, caches reload |
| Deadline of 14 working days | Progress estimated | Daily list of remaining items |
| Evidence | Unclear when which item was switched | Log per item with time of publication |
Smartphones and tablets since June 2025
With Delegated Regulation (EU) 2023/1669 a dedicated energy label for smartphones and slate tablets has applied since 20 June 2025 (Smartphone Regulation, Article 8). For electronics retail this brought a range with many models and short model cycles into the labelling obligation. Besides efficiency class and scale, the label carries further values: battery endurance per cycle, reliability class for repeated free falls, repairability class, battery endurance in cycles and ingress protection rating (Smartphone Regulation, Annex III). In distance selling the dealer provides label and product information sheet as the annexes require, the label close to the price and the information sheet either nested or via a link to the product database.
For the item master this means the graphic remains the mandatory output, but the values on it are interesting for filters and comparisons. If you keep repairability class or protection rating as separate attributes, you have to keep them in sync with the label, otherwise the filter shows something different from the label. Our advice: take the individual values from the same source as the graphic and swap them together with every label change, as one version with one validity date. Which product data the digital product passport will additionally require is covered in a separate article. The energy label, by contrast, is mandatory today and runs over the same data flow that can later carry the product passport.
Model or variant
Versioning: what 15 years of data retention suggest
After the last unit of a model has been placed on the market, the supplier keeps the information on that model for 15 years in the compliance part of the product database (Energy Labelling Regulation, Article 4). The obligation falls on the supplier, not the dealer. For the data flow it is still a signal: label data is not a volatile attribute but a set of versions with a period of validity that may be requested long after the item has sold out. A data model built for this timeline costs little, because labels rarely change and a version consists of a few fields and two files.
In daily shop operations the benefit shows in three places. First, with queries about an order: which label was on the listing on the day of purchase? Second, with rescalings: old and new version have to exist side by side, for a while even simultaneously in the system. Third, with own brands and imports, where your own company is the supplier and carries the retention itself. A model that overwrites the label version answers none of these questions. A model with versions, valid from, valid to and immutable files answers all three. The rule is simple: a version is never changed, only ended and replaced by a new one. Correcting a typo is also a new version, with source and confirmation date.
When label or information sheet are missing
If label or information sheet are missing, the dealer requests them from the supplier (Energy Labelling Regulation, Article 5). The supplier delivers printed labels and product information sheets free of charge, promptly and in any case within five working days of the request (Energy Labelling Regulation, Article 3). For the interface this is a process with a deadline. An item that requires a label and lacks a complete record lands in a dead letter queue, the request to the supplier goes out with a date, and the queue shows which requests have been open longer than planned. If the request is sent from within the system, the date of the request is in the log without extra effort.
For the information sheet there is a second route via the product database. If the EPREL model registration number is available, the interface can check whether the register entry offers an information sheet and take it over as a file. That does not replace the supplier data, but it closes gaps faster. There is also a display requirement: the dealer ensures that the QR code on the label is readable when offering a product model for sale (EPREL Implementing Regulation, Article 14). A label graphic that the shop shrinks heavily for previews or compresses lossily can miss exactly that. The minimum display size and the image format therefore belong in the shop's image rules, not at the discretion of a template.
When the dealer is the supplier
If you have own-brand products manufactured or import devices from third countries yourself, you are on the other side of the data flow. As importer or manufacturer you are a supplier within the meaning of the framework regulation, register the model in EPREL before placing it on the market, create label and information sheet and keep the data for 15 years after the last unit. The Commission describes the order explicitly: before products covered by energy labelling are placed on the EU market, the models must be registered by their supplier in EPREL. For the item master this means registration must be complete before the item is released for sale, and the release should check for it.
Registration takes place either via the interactive EPREL compliance website or by uploading the model data using the latest version of the data exchange model (EPREL Implementing Regulation, Article 15). For a few models the entry form is sufficient. For a range with a steady flow of new models there is much to be said for uploading from the ERP: the technical values are in the item master anyway, and an export module from API development produces the upload file from them. The model registration number that EPREL assigns is stored in the item master and flows from there into all channels, just as for purchased models. Which manufacturer details must appear in the listing alongside is described in the article on economic operator data in listings.
The order of work in a project
- Scope the range: which product groups in the range fall under a delegated act, and which items belong to them. The result is a label-required flag on the item or product group.
- Create the fields: efficiency class, class range, label graphic, information sheet as file and link, EPREL model registration number, valid from and valid to, source. Plus ownership: who maintains in-house, who confirms.
- Collect supplier data: request labels, information sheets and registration numbers per supplier, ideally as files with the model identifier. Every gap goes into the queue, not into a spreadsheet next to the system.
- Mapping per channel: product page, category listing, marketplace feed, stores. Define it once, maintain it in the middleware, extend it for new channels.
- Publishing gate: no item that requires a label goes live without a complete record. The check runs before every publication, not as a nightly report afterwards.
- Rehearse the cut-over run: create a label change with valid from in the future, trigger the delta run, check image addresses and caches. That way the next rescaling is not the first time the process runs for real.
How long such a project takes depends mainly on the state of the supplier data, less on the technology. Once the data flow for the energy label has been built properly, it serves every further mandatory item attribute. If you want to go through your label record with us, write to us via the contact form for ERP interfaces. For electronics retailers with a large labelled range, the page on ERP integration in electronics retail describes the framework in which we build such data flows.
A label only becomes a statement once it has a version: valid from, valid to, source. Without these three fields it is just an image on the item.
Sources and legal basis
Related Articles
Food Labelling Data from the ERP in Your Storefront
Ingredients, allergens and nutrition come from the item master, shelf life and lot number from the batch: how both mandatory data sets reach the shop.
Digital Product Passport: Product Data for ESPR
Digital Product Passport from 2027: aggregate material, repair and origin data per ESPR from ERP and PIM and provide it DPP-compliant via QR code and API.
GPSR: Economic Operator Data From ERP Into Every Listing
The economic operator as a master data object: move manufacturer, responsible person and product identifiers from the ERP into every distance offer.