Do manufacturer details belong on the article or in a master record of their own?

In a master record of their own. An article points to an operator; it does not describe one. The difference becomes visible at the first change of registered name: in the free text model thousands of article texts are affected, in the master data model a single record. On top of that, only a structured record can be checked by machine - for an address with a house number, a valid contact address and a country code from which the question of establishment in the Union can be answered. Free text offers each of those checks nothing but a string.

Does a wholesaler have to pass the data on to its specialist trade customers?

Specialist retailers are distributors under the regulation themselves and must populate their own listings completely. In practice they can only do that with their supplier's data, which is why the wholesaler has to build the return channel anyway - otherwise the details are created at the customer by copying. A dedicated endpoint that serves the operator block as an independent object with a change timestamp makes sense, so the retailer can catch up selectively instead of reprocessing the whole catalogue on every change.

How do you stop articles going live without complete details?

With a gate before publishing. The interface only reports an article as active once the operator block is complete per language and per channel; if a mandatory field is missing, the article stays unpublished and lands in an error queue with a reason. That queue becomes the work list for purchasing. What matters is that the check stays visible in operations: a rule that holds nothing back for weeks is usually not armed but miswired.

How much effort is it to introduce this in an existing shop?

The technical part is manageable: one master record, one assignment table with a time axis, one rule before publishing and one endpoint for the handover. The effort usually sits in gathering the data, because in many assortments the manufacturers' addresses were simply never collected. We therefore suggest building the model and the check first and closing the gaps afterwards through a work list sorted by revenue. That moves the bulk of the assortment into a controlled state early while the stragglers are filled in.

GPSR: Economic Operator Data From ERP Into Every Listing

Q: Which details does the product safety regulation require in an online listing?

The offer must contain at least four unambiguous and clearly visible details: first, the name, registered trade name or registered trademark of the manufacturer together with a postal address and an email address; second, where the manufacturer is not established in the Union, the name, postal address and email address of the responsible person; third, information allowing identification of the product including a picture, its type and any further product identifiers; fourth, any warnings or safety information in a language easily understood by consumers. The regulation has applied since 13 December 2024.

Q: What applies when the manufacturer sits outside the EU?

Then the product may only be placed on the market if an economic operator established in the Union takes on the tasks set out in Article 4(3) of Regulation (EU) 2019/1020. Four roles qualify: a manufacturer established in the Union, an importer, an authorised representative mandated in writing, or, subordinately, a fulfilment service provider established in the Union for the products it handles. In the data model that role is a field of its own, and its name and contact details additionally belong in the listing.

Regulation (EU) 2023/988 on general product safety has applied directly in every member state since 13 December 2024. For online trade its consequence looks less like law and more like a data model: every distance offer has to name the manufacturer with a postal address and an email address, add the responsible person in the EU where the manufacturer sits outside the Union, and carry information identifying the product together with any safety warnings. Four details, unambiguous and clearly visible, per article - and those four rarely sit in a wholesaler's ERP where an interface can find them. They live in a long description, in a supplier remark or in a data sheet no system can read. This article describes the economic operator as a master data object in its own right, the route through middleware into shop and catalogue API, the mandatory field check before publishing, and the return channel to specialist trade customers who need the same data in their own listings, which is why it belongs in the wholesale ERP integration.

Key takeaways

A distance offer must carry at least four unambiguous and clearly visible details: the manufacturer with address and email, the responsible person for non-EU manufacturers, information identifying the product, and any safety warnings (GPSR, Article 19).
The economic operator is a master record of its own, with a number, a role, a structured address and a validity period - not a long text on the article. When a manufacturer changes its registered name, one record changes instead of thousands of article texts.
A product may only be placed on the market if an economic operator established in the Union is responsible for the tasks set out in Article 4(3) of Regulation (EU) 2019/1020 (GPSR, Article 16).
Before making a product available, distributors verify that the manufacturer and, where applicable, the importer have met their labelling duties (GPSR, Article 12). That check belongs in the interface as a mandatory field rule, not on a list in purchasing.
For its specialist trade customers the wholesaler is the data source. Without a return channel over a catalogue API they build their own listings from copied addresses, with every error that copying brings.

The economic operator is not a free text field

The regulation works with a fixed list of roles: manufacturer, authorised representative, importer, distributor and fulfilment service provider. Each role carries its own duties, and none of them can be derived from the article master. An article does not have a manufacturer in the sense of an attribute; it has a relationship to a legal entity with a name, a registered trade name, a postal address and an email address at which it can actually be contacted. The regulation asks the manufacturer for exactly those details, including the single contact point where it differs. This is why the obvious approach - writing everything into one more long text field on the article - falls apart. Such a text cannot be checked, cannot be handed to a catalogue API and cannot be changed without touching every affected article. When a manufacturer changes its registered name, the free text model puts thousands of articles in scope; the master data model puts one record in scope. Careful master data practice therefore treats the economic operator like a supplier or a cost centre: a record of its own, with its own number, its own history and a named owner in the business.

Cardinality is where most models fall short. An article has exactly one manufacturer, but it may be sourced through several suppliers, and each sourcing route can involve a different importer. Conversely, one responsible person in the Union often represents an entire manufacturer brand across hundreds of articles. From the data model's point of view that is three tables: the operator itself, the role assignment per article, and validity per period. The last point is easily forgotten, yet it is what keeps a listing from last year traceable later - for instance when a market surveillance authority wants to know who was recorded as the responsible person at the time of sale. Keep the assignment without a time axis and every change overwrites the past, leaving you able to narrate what once applied but not to show it.

What Article 19 requires in a listing

For distance selling the regulation sets out a short, clearly bounded list. In its own words the offer must contain at least the following unambiguous and clearly visible details: the manufacturer with postal address and email address; where the manufacturer is not established in the Union, the responsible person; information allowing identification of the product including a picture; and any warnings or safety information in a language easily understood by consumers. For an interface that is not four paragraphs but a whole set of individual fields that have to be rendered per language and per target channel. Treat them as one block and you lose the ability to report precisely which field is missing - and that report is the only way to close the gap in purchasing instead of exposing it in the listing.

Manufacturer

Name, registered trade name or registered trademark, plus the postal address and email address at which the manufacturer can be contacted (GPSR, Article 19 point a).

Responsible person

Where the manufacturer is not established in the Union, the name, postal address and email address of the responsible person take that place (GPSR, Article 19 point b).

Product identifier

Information allowing identification of the product, including a picture, its type and any further product identifiers, belongs visibly in the listing (GPSR, Article 19 point c).

Safety warnings

Warnings and safety information are rendered in a language easily understood by consumers, which means maintaining them separately for each language version of the shop.

Type and batch number

Products carry a type, batch or serial number or another element allowing easy identification (GPSR, Article 9(5)). In the shop it is the anchor for later recalls.

Technical documentation

Manufacturers keep the technical documentation available to market surveillance authorities for ten years from placing the product on the market (GPSR, Article 9(3)). The distributor needs the reference to it.

The data model: one record per operator

A workable model has three parts. The operator record carries a number, a role, the legal form, the name, the registered trade name, the postal address in structured fields and a contact address that somebody actually reads. The assignment links article and operator, carries the role and a validity period. The third layer is provenance: where did the value come from, when did the supplier last confirm it, which document underpins it. Without that third layer you cannot say later whether an address was maintained or guessed, and that is precisely the question asked when something goes wrong. In projects that grew out of a product data pipeline the operator record usually exists as an entity already and only needs the mandatory fields and the role logic added; in projects without a product information system it is created in the interface layer and served from there in both directions.

Keep the postal address structured

An address in a single text field is fine for display and useless for everything else. Street, house number, postal code, town and country belong in separate fields, the country as a two-letter code. Only then can you answer by machine whether the manufacturer is established in the Union - and that answer decides whether the listing additionally has to show a responsible person. A free text field never answers this reliably, because country entries appear in it in every conceivable spelling.

economic operator (data model)

operator
  operator_no      unique, technical key
  role             manufacturer | authorised_rep | importer |
                   distributor | fulfilment | responsible_person
  name             company name per register
  trade_name       registered trade name or trademark
  street, house_no, postcode, town, country_iso2
  email            monitored, not a no-reply address
  source, confirmed_on

article_operator
  article_no + operator_no + role
  valid_from, valid_to
  supplier_no      sourcing route, may repeat

rule before publishing
  if role = manufacturer and country_iso2 not in EU:
      additionally require role = responsible_person
  if email empty or address incomplete:
      hold the listing, do not publish
  if a warning is missing in an active language:
      do not publish that language version

Where the fields come from in the ERP

In SAP, Dynamics and the inventory systems used by mid-sized companies there is no field called economic operator. What does exist is the supplier master, the manufacturer part number, foreign language texts and a handful of classification attributes. The first project step is therefore not programming but an inventory: which field carries the manufacturer name today, in which spelling, and how often does that spelling differ between two articles from the same manufacturer. This survey produces the mapping specification that later sits in the field mapping. Experience says the hit rate is high for own brands and low for merchandise from drop shipping, because nobody there ever asked for a full postal address. That is not negligence but the result of a purchasing practice in which the manufacturer's address simply was not needed until recently.

Survey fields per supplier, not per article: manufacturer name, address and contact address are collected per supplier. A supplier usually delivers for a manageable number of manufacturers, which keeps the survey tractable.
One address, five fields: keep street, house number, postal code, town and the two-letter country code apart. Only that separation allows the machine answer to the question of whether the manufacturer is established in the Union.
Record provenance: every value gets a source and a confirmation date. Without those two fields you cannot tell later whether an address was confirmed by the supplier or lifted from a catalogue.
Map in the interface, not in the shop: translating ERP fields into listing fields belongs in the inventory and ERP integration so that the same rule applies to shop, marketplace and catalogue export.
Make gaps visible: articles without a complete operator block appear on a work list for purchasing instead of quietly publishing with empty fields. A gap nobody sees does not get closed.

The mandatory field check before publishing

The regulation asks distributors to run a check of their own: before making a product available on the market, they verify that the manufacturer and, where applicable, the importer have met their labelling duties. In a shop with tens of thousands of articles that is not a task for a list in purchasing but a rule in the data path. Technically it is a gate before publishing: an article is only reported to the shop as active once the operator block is complete. If a mandatory field is missing, the article stays orderable in the ERP for the internal sales desk but does not appear in the catalogue. In an SAP integration the gate can hang off the distribution status; in smaller systems it hangs off a flag the middleware sets and withdraws.

The direction of the message matters. An article that fails the check must not disappear silently, or sales will look for it in the shop and find nothing. The middleware writes the reason into an error queue and names the missing field in plain language: address without a house number, contact address empty, country code missing, warning present in only one of two languages. That queue becomes the work list purchasing processes. It is also the proof that the check runs at all - because a rule that never holds anything back is usually not armed but miswired.

Aspect	Without an operator model	With an operator model
Manufacturer details	long text on the article, kept per article	master record with a number, linked per article
Change of registered name	touch thousands of article texts	one record changed, history preserved
Non-EU manufacturer	surfaces only when a complaint arrives	rule fires on the country code
Listing without a mandatory field	goes live, gap unnoticed	held back and reported
Handover to specialist trade	addresses are copied by hand	catalogue API serves the same fields
Recall	search through documents and mail	query by batch and period

The return channel to specialist trade

A wholesaler does not only sell to end customers; it supplies specialist retailers who offer the same articles in their own shops. The regulation applies to their listings in the same way - and the details they need sit with the wholesaler. If that route is not built, listings are assembled from copied addresses, from old price lists or from a data sheet somebody sent by mail. Every one of those transfers is a source of error, and every correction then has to travel back the same way. A catalogue interface that serves the operator block as an object of its own is cleaner: the retailer pulls article and operator separately and joins them in its own system. Such a catalogue API is technically unremarkable and saves most of the rework on both sides.

When designing it, it pays to separate by rate of change. Article master data changes rarely, prices change often, operator data hardly ever - but when it does, it affects many articles at once. A pull that delivers everything in one package forces the recipient into a full processing run even though only one record moved. An interface that versions operators independently and ships them with a change timestamp lets the retailer catch up selectively. For an integration in specialist trade that means one extra endpoint and one timestamp, and the duty to pass data on is modelled in the system instead of hanging in a mail thread.

Third country manufacturers and the responsible person

In wholesale this case is the rule rather than the exception: the manufacturer sits outside the Union and goods are imported through a European importer or directly. The regulation is unambiguous here - a product may not be placed on the market unless there is an economic operator established in the Union who is responsible for the tasks set out in Article 4(3) of the market surveillance regulation. Who can take that role is listed in the market surveillance regulation: the manufacturer established in the Union, an importer, an authorised representative mandated in writing, or - subordinately, for products it handles - a fulfilment service provider established in the Union. For the data model that means the role is a field of its own with four possible values, not a tick box on an address.

Besides the detail in the listing, the regulation requires the contact details of that economic operator on the product, on its packaging, on the parcel or in an accompanying document. That is a requirement on the goods, not on the shop - but it reaches back into the interface, because both statements have to agree. If the carton shows a different address from the online listing, not only is one of the two wrong, the provenance of the data is unclear. Run the operator record as the single source and feed both the label data and the listing from it, and the problem does not arise. Run two maintenance paths and sooner or later you get two truths, and the contradiction regularly surfaces only when somebody asks from outside.

The role is a field, not a matter of interpretation

As long as the master record holds nothing but an address, it is open whether that address denotes the manufacturer, the importer or a mandated responsible person. Only an explicit role turns the address into a statement that can be checked - and only with it can a rule decide whether a listing is complete or not.

Marketplaces and the catalogue API

The same listing duties apply on marketplaces, except that the field schema is dictated from outside. Every marketplace names the fields differently, sometimes requires its own approvals and sets its own length limits. That is why the mapping belongs in the interface layer and not in a maintained spreadsheet: once the operator block is kept cleanly, marketplace integration is pure mapping work. There is also a deadline that matters for operations: providers of online marketplaces process notices on product safety matters without undue delay and in any event within three working days of receipt. Anyone selling there should be able to answer within the same window, and that only works if the data can be queried instead of sitting in mailboxes.

For the build the order matters. First the operator block is completed in the leading system, then it is mapped, then it is published. Reverse that order and start with the mapping onto target fields, and you create workarounds that make every later change expensive - for instance a concatenated address field the marketplace accepts and from which the country code can no longer be recovered. The rules by which source fields meet target fields are documented and versioned in a clean data mapping so that a change to the target schema does not turn into a search through source code.

Recalls: when the data is actually needed

The real purpose of the data model shows in an emergency. When a product is recalled, all affected consumers who can be identified must be informed directly and without delay. The recall notice itself names, among other things, the production numbers such as batch or serial number and, where it helps, a graphic showing where they are found on the product. Both presuppose that batch and article number were recorded with the order and that the manufacturer details valid at the time of sale can be reconstructed from it. That is exactly why the assignment between article and operator carries a validity period. Anyone who already keeps hazard attributes will recognise the same structure in the integration of hazardous goods data - except that it is about transport and labelling there, and about the identity of the responsible party here.

What a project works through, in order

Settle the roles: which of the five roles occur in your own assortment, and who in the business maintains them. Without a named owner every data path stays empty, because nobody closes the gaps.
Create the operator record: master record with number, role, structured address, contact address, source and confirmation date. The number is technical; the name is allowed to change.
Assignment with a time axis: article, operator, role, valid from and valid to. Only then does an old listing stay traceable instead of being overwritten by current maintenance.
Gate before publishing: the middleware checks completeness per language and channel and holds incomplete articles back instead of publishing them with empty fields.
Build the handover: an endpoint for specialist trade customers that serves operators with independent versioning. The same mechanism later carries the data requirements of neighbouring regulations, for instance packaging data, the digital product passport or the mandatory food details.

An address without a role is not a statement but a guess. Only the role beside it turns the record into something a listing can rest on.

Principle of master data integration

Sources and legal basis

This article draws on Regulation (EU) 2023/988 on general product safety, in particular Articles 9, 12, 16, 19, 22, 35, 36 and 52, and on Article 4 of Regulation (EU) 2019/1020 on market surveillance and compliance of products. All verbatim quotations are taken from the official German versions published in the Official Journal of the European Union. Implementing this in your own system does not replace legal advice; for the technical side you can contact the integration agency, and for the assortment side there is advice for wholesale.