EUDAMED registration by 28 November 2026: UDI data straight from ERP and PIM

If you still maintain your UDI data in Excel lists, email attachments and three separate item masters, you have a problem that has been sitting in your ERP for years and is now sending you the bill. On 28 November 2026 it stops being a compliance issue and becomes a delivery-stop issue.

The BfArM (German Federal Institute for Drugs and Medical Devices) and the European Commission just put it more politely: anything without an EUDAMED registration by the end of November may no longer be placed on the market after that. As of the end of October 2026, that essentially leaves you November. This text is not legal advice. But you can decide today which of your systems should supply the data.

What has applied since the end of May and what ends on 28 November

For devices that were already on the market before the mandatory start and continue to be sold, the BfArM puts it unambiguously in its FAQ: such devices “must be registered in EUDAMED by 28 November 2026”, and devices not registered by then may no longer be placed on the market.

For devices you have placed on the market for the first time since the end of May, the rule already applies: register first, then deliver. This is enforced not by the BfArM but by the market surveillance authorities of the German federal states.

Behind this is a simple mechanism: each EUDAMED module starts its own clock as soon as its functionality is published in the Official Journal. Regulation (EU) 2024/1860 sets it out as follows: six months after the notice, the associated obligations become applicable, and for existing devices after twelve months (Art. 123(3) MDR; for in vitro diagnostic devices, Art. 113(3) IVDR in parallel).

That notice was Decision (EU) 2025/2371, Official Journal of 27 November 2025. The European Commission’s overview page confirms: since 28 May 2026, the first four modules have been mandatory, including actor registration and UDI/device registration.

Two details from the Commission services’ Q&A on the gradual roll-out make the mountain smaller. You don’t register every sales unit, but each device identifier: once per UDI-DI, with batch and serial numbers left out. And a legacy device does not need its own registration if “the same device” is already registered as an MDR device, i.e. the same UDI-DI, item number or trade name without any identifier-relevant change. For a manufacturer with 300 medical devices, the effort is therefore determined by the number of device identifiers, however many pallets it ships.

For Germany, there is one more point: according to the BfArM, new entries in DMIDS (the German medical devices information and database system) were switched off at the mandatory start. If you used to report there, you have had no second channel for new devices since May.

Manual, XML upload or machine-to-machine: the three routes to EUDAMED registration

In its Guidelines on Data Exchange with EUDAMED, the European Commission describes three input routes. The web interface: PC, browser, form, field by field. XML upload via the same interface: you generate XML files that are validated against the XSD schemas of the EUDAMED DTX service; generating them can be automated, while the upload remains a manual click. And machine-to-machine (M2M DTX): your backend talks directly to EUDAMED via an eDelivery Access Point, without human involvement.

The Commission itself dampens expectations of M2M: it calls it “the most complex and expensive solution”, which only makes sense under certain conditions, for example if a database exists outside EUDAMED, the volume cannot be handled manually and submissions are frequent. Then there is the Access Point, which has to be installed and maintained on your own hardware. For a group with ten thousand UDI-DIs, that is a project. For a laboratory supplies manufacturer with 300 medical devices, it is overengineering.

My recommendation for SMEs is therefore clear: generate XML from the leading system, validate it, upload it. You get the data quality of automation without the operational burden of an interface that might send four times a year. M2M becomes interesting when product changes, certificate updates and vigilance reports are part of day-to-day business.

Validation errors in the XML upload and what no validator finds

An example scenario, deliberately simplified: a manufacturer of laboratory consumables has 1,200 items in its ERP, 300 of them medical devices, some under the MDR (class I and IIa), some in vitro diagnostic devices under the IVDR (class A and B). Regulatory affairs maintains the regulatory attributes in an Excel file, and the product texts sit in the shop system.

The first exporter pulls everything together, and XSD validation rejects the file. For some of the devices, a mandatory field is empty because there was never a column for it in the Excel file. A text field exceeds the permitted length because the shop name was copied into it.

Now the question is who fills this in, and in which system.

The Commission’s guidelines themselves name exactly these classes of error, including field sizes, the position of tags and mandatory versus optional fields; anything that does not pass XSD validation is returned. The Commission explicitly recommends generating the XML files automatically to avoid validation errors.

Identification weighs more heavily. According to the Commission’s UDI page, the Basic UDI-DI is the main key in the database and the access key to all device-related information; the UDI-DI is manufacturer-specific per device. Both must come from one of the designated issuing entities (GS1, HIBCC, ICCBBA, IFA).

If your ERP holds the GTIN in the item master but the Basic UDI-DI in a regulatory table next to it, the question is which one wins when the two don’t match. No validator answers this question; it has to be decided in the system before the export runs.

Then there is the identifier logic for product changes. The Commission services’ Q&A makes it clear: if the MDR device has been changed in a way that requires a new UDI-DI, it no longer counts as “the same device” as the legacy device. If this mapping is kept not in the system but in the head of a colleague in regulatory affairs, you end up with duplicate registrations or gaps.

UDI data from ERP and PIM: which system owns which field

Now for the real point. The deadline forces you into an architecture decision: which system is the source of truth for which product data field? EUDAMED registration is just one more recipient alongside hospital purchasing portals, PunchOut catalogs and the B2B shop. Each of these recipients wants the same master data in a slightly different form. If you maintain it four times separately, you also have to reconcile it four times.

The rule of thumb I recommend: the ERP owns whatever is transactional and identifying. Item number, GTIN or UDI-DI, packaging hierarchies, batch and serial number logic, status “on the market” or “discontinued”. A PIM owns whatever is descriptive, multilingual and document-heavy: product names, risk class and nomenclature codes, instructions for use, certificate references, marketing copy. The dividing line is not dogmatic, but it has to be drawn and documented.

Back to the example manufacturer with its 300 medical devices. For EUDAMED, it needs a mapping per device: the ERP supplies identifiers and status, the PIM supplies names, classification and document references, and an exporter builds the XML from this against the current XSD. The Excel file is imported, and that is exactly where it becomes clear why it has to go afterwards.

For some of the devices, the trade name in the Excel file differs from the shop, for others the Basic UDI-DI is missing entirely, and some items are set to “discontinued” in the ERP but still to “on the market” in the Excel file. Each of these discrepancies is a decision that someone has to make and document. In the example, sales wants the shop name as the trade name, regulatory affairs wants the one from the technical documentation. For the status, the ERP decides, because that is where the discontinuation is booked.

With a different mapping, the same exporter also generates the catalog for the hospital portals and the shop feed. For this, the PIM system needs approval workflows and versioning, otherwise during an audit you won’t know which data state went to EUDAMED and when. Whether a dedicated system pays off for this is broken down in our article on when a dedicated PIM really pays off. If your product group later falls under an ESPR delegated act on the digital product passport, that will also need the GTIN and product identifier. That is an argument for setting up the mapping properly now.

One export, several target formats. EUDAMED is simply the recipient with the hardest deadline.

After the deadline: certificates by 28 May 2027 and ongoing maintenance

On 28 November, the work only changes direction. The next trap lies in the “Notified bodies and certificates” module: registering the certificates is the notified body’s job, not yours. Even so, the error lands on your desk if the Basic UDI-DI on the certificate does not match the one you registered in the UDI module. In that case the certificate cannot be assigned to any of your registered devices in EUDAMED.

The deadlines for this are in the Commission document on the transition period: certificates issued under the MDR or IVDR before mandatory use must be registered by 28 May 2027. According to the Q&A, this 18-month deadline only applies to MDR and IVDR devices that are, or must be, registered in the UDI/Device module; only the latest certificate version, together with the latest decision, is entered in each case. New certificates issued since the mandatory start must go in immediately.

Anyone who completes their device registration in November should therefore check with their notified body by May 2027 that both sides hold the same identifiers. For the example manufacturer, this only concerns the items whose conformity assessment involved a notified body, reconciled per Basic UDI-DI on the certificate.

The interface itself also keeps moving. According to the guidelines, as long as EUDAMED is not fully functional, the Commission announces changes to the DTX format only four to six weeks before a release. Only after that does the usual lead time of six months apply, during which the old and new XSD run in parallel.

On top of that come product changes with a new UDI-DI, discontinuations and certificate renewals. According to the Commission, two modules, vigilance and clinical investigations, are still in development and will become mandatory without a voluntary lead-in phase. The exporter therefore needs a change history and must be adaptable to new XSD versions.

Conclusion: the deadline is the smaller problem

With clean master data, EUDAMED registration by the end of November is a manageable project. Because that essentially leaves November, a clear order applies: register what you have, if necessary via the web interface or with an XML file that you pull from the ERP once and clean up before uploading. The export from ERP and PIM is the project for the period after that, and it should start in parallel now.

What I advise against is a stand-alone solution that serves EUDAMED and nothing else. Set up the XML route from ERP and PIM, document the mapping, version every submission. That will also carry the certificates through to May 2027, the hospital portals and, as soon as your product group is covered, the product passport. Doing it manually via the web interface will get you through November. You will only get through the years after that with data that is right once and arrives the same everywhere.