EUDAMED accepts data through three input modes: the Web user interface, an XML bulk upload through that same interface, and machine-to-machine (M2M) data exchange over the Commission’s eDelivery infrastructure. Every method writes to the same EUDAMED data dictionary, validates against the same XSD schemas and EC business rules, and assumes the underlying device data already exists in a structured form. The choice between them turns on four axes: portfolio size, internal data readiness, engineering capacity, and time before the 28 November 2026 legacy-device deadline. Most vendor comparison guides frame M2M as the only viable industrial approach; other discussions reduce the realistic options to building it yourself or entering the data manually. Both framings skip the upstream problem most SME manufacturers actually face: the structured device data that any submission method assumes. This page sits where the comparison decision is made and routes the reader downstream by method.
What EUDAMED actually offers: three methods, one data dictionary
EUDAMED’s Information Centre documents three input modes for actor, device, certificate, and other module records: the Web user interface, XML bulk upload through that interface, and machine-to-machine data exchange. The Commission describes the UI as the simplest option from a data handling, manipulation and implementation point of view for a user with a PC, an internet connection, and a browser. XML bulk upload uses the same interface but accepts an XML file, validated against the published XSDs and EC business rules, that carries one or more records per submission. M2M transmits XML messages automatically between an external system and EUDAMED over CEF eDelivery using the AS4 protocol.
All three methods write to the same EUDAMED data dictionary. The fields, enumerations, codes, and identifiers EUDAMED requires are the same whether a manufacturer types them into a form, uploads them inside an XML envelope, or pushes them over an access point. So are the failure modes: a record that fails an EC business rule fails the same rule regardless of the channel that submitted it. The 28 May 2026 cutover made mandatory use of the Actor, UDI/Devices, Notified Bodies & Certificates, and Market Surveillance modules apply to every manufacturer placing devices on the EU market. The method choice does not change the obligation; it changes how a manufacturer satisfies it.
For the wider context of how EUDAMED registration fits together, see the EUDAMED registration pillar.
Method 1, Web UI: when manual entry is the right choice
Manual UI entry is the EUDAMED submission method the Commission supports for ad-hoc, low-volume, or one-off device registrations. The user signs in to EUDAMED with an active actor record, opens the relevant module, and enters records field by field. Validation runs per-record at submit time; the database returns errors inline.
A common vendor framing positions manual entry as a method that should not be a default. That framing is anti-aligned with several real reader segments: start-ups with three or four devices on the EU market, manufacturers with a single legacy device they need to register and walk away from, and reseller-style structures where one product line was not designed in-house. For these readers the Web UI is the correct choice, and time spent on XML or M2M tooling is misspent.
The UI breaks down in three specific ways at scale. Multi-variant device families are awkward where one Basic UDI-DI groups many UDI-DIs: the form was built for record-by-record entry, and the per-variant entry pattern multiplies clicks linearly. Version drift is heavy: updating a registered device through the UI is a per-field click-walk against the existing record. Per-language IFU language-list entry is slow at scale: the structured language picker accepts one language at a time and re-loads the form between picks. Whether these matter depends on portfolio size and how often the manufacturer expects to update records. The four-axis decision below gives the place to weigh them.
Method 2, XML bulk upload: when the structured data already exists
XML bulk upload is the EUDAMED submission method that accepts an EC-XSD-validated XML file containing one or more device, certificate, or other entity records per upload. The user logs in, navigates to Data transfer → Bulk Upload, selects a DTX service, attaches the XML payload, and submits. EUDAMED processes the payload, returns per-object SUCCESS or ERROR statuses inside a single XML response file, and asks the user to resubmit a new payload only for the objects that failed. The EC’s bulk-upload help page gives the worked example: of ten DEVICE.POST records, seven processed successfully and three were rejected; the manufacturer resubmits a payload containing only the three failed records.
XML bulk upload is the right method when the underlying device data already lives in a structured system, a PIM, an MDM, an Excel of record, and the manufacturer can extract it into an XSD-conformant XML envelope. The implementation effort is real but bounded: the Commission publishes the entity-model XSD and the DTX-service XSDs, and the EUDAMED business rules, all downloadable from the Information Centre. Validation against these is deterministic.
Two recurring reader confusions are worth defusing. First, EUDAMED itself does not accept Excel uploads. Several vendor pages offer an Excel-to-XML workflow as a paid intermediate; the workflow is a vendor service on top of XML, not an EC-supported input mode. The related-search refinement EUDAMED Excel template surfaces this segment, but the answer to the underlying question is that the file EUDAMED accepts for bulk submission is XML. Second, a per-file object cap forces multi-file submission for large portfolios. Vendor reference pages disagree on the exact unit (objects vs UDI-DIs); the source of truth is the current revision of the EC Guidelines on Data Exchange, which a manufacturer should consult against their own portfolio size before generating the payload.
The bulk-upload lifecycle has six steps:
- Extract the device data from source systems into the structures the EUDAMED data dictionary requires.
- Generate an XML payload conformant to the relevant DTX-service XSD.
- Validate the payload against the XSDs and the EC business rules before upload.
- Upload through Data transfer → Bulk Upload; wait for the DTX service to process.
- Read the per-object response file; identify any objects with ERROR status.
- Re-submit a payload containing only the failed objects.
A summary of the mechanics:
| Element | EUDAMED’s XML bulk upload |
|---|---|
| Schemas required | Entity-model XSD plus DTX-service XSD per module |
| Per-file object handling | XML payload may contain multiple objects; EUDAMED processes each independently |
| Validation rules | XSD validation plus EC business rules; deterministic |
| Per-object response | Single XML response file with SUCCESS or ERROR status per object |
| Resubmission pattern | Resubmit a new payload containing only the failed objects |
| Per-file object cap | Documented in current EC Guidelines on Data Exchange; consult current revision against portfolio size |
For the XML structure itself and a worked-example payload, see the XML template and schema page. For the most frequent XSD failures and business-rule rejections EUDAMED returns, see the validation errors page.
Method 3, M2M: when the integration cost is worth it
M2M is the EUDAMED submission method that exchanges XML messages automatically between an external system and EUDAMED over the Commission’s CEF eDelivery infrastructure. The external system must convert its data into the XML format EUDAMED supports, install and configure a dedicated eDelivery access point on its premises, and run the AS4 protocol against the EUDAMED side, which uses Domibus. The Commission publishes the list of AS4 eDelivery conformant access-point products and services and the M2M architecture model.
The Commission’s own guidance is direct on when M2M is appropriate. The Information Centre frames M2M as the most complex and costly solution and lists five conditions any one of which should be satisfied before adopting it: the organisation already operates a database outside EUDAMED for the data in question; the volume to be uploaded or extracted is too large for manual entry; exchanges with EUDAMED will be frequent; the cost of manual input outweighs the cost of automation; and the organisation has the resources, competence, and infrastructure to implement and maintain the integration. The SME manufacturer registering thirty devices once does not fit those conditions; the multinational pushing device updates and vigilance reports across hundreds of registered records continuously does.
Four provider categories operate in the EUDAMED M2M space. Managed-service vendors operate the access point and the integration on the manufacturer’s behalf. Software vendors ship M2M connectors as part of a UDI-management product. Enterprise platforms bundle M2M into a wider regulatory data platform. The Commission’s own Domibus reference implementation is published as an open-source AS4 access point any organisation can deploy. The provider-directory category has emerged as the M2M market matures, evidence of fragmentation rather than consolidation.
EUDAPrep does not provide an M2M connector. M2M sits in Phase 3 of the product roadmap and is not part of the current scope. A reader who fits the Commission’s M2M conditions should evaluate the provider categories named above against their existing infrastructure and budget, not against EUDAPrep.
How to choose: the four-axis decision
Four axes settle which method fits a given portfolio. The matrix below summarises; each axis is short.
Portfolio size. The UI scales linearly with click count; large portfolios pay a fixed per-record cost in entry and review time. XML bulk upload handles mid-to-large portfolios in a single or small number of files; the lifecycle is unchanged whether the file carries five records or fifty. M2M handles continuously churning portfolios where new records, updates, and module entries are routine rather than burst events. A useful orientation: portfolios above the low hundreds of UDI-DI records typically reach the point where XML’s setup cost pays back, though the exact threshold varies with update frequency and team capacity.
Internal data readiness. This is the axis the comparison pages skip. None of the three methods help if the underlying device data is not already structured. A manufacturer whose device fields live in IFU PDFs, label artwork, declarations of conformity, technical files, and the responsible engineer’s memory will spend the same effort building the dataset whether they then use the UI, XML, or M2M to upload it. That preparation work is the load-bearing job, and it sits upstream of the upload step.
Engineering capacity. XML bulk upload is implementable by an RA team without dedicated engineering support when the XML is generated by a tool that already understands the XSDs and the business rules. Building XML by hand against the XSDs is harder. M2M requires either a managed-service vendor that operates the access point or in-house engineering time to deploy Domibus and integrate with the EUDAMED-side endpoints.
Deadline pressure. With 28 May 2026 in the rear-view mirror and 28 November 2026, the legacy-device cutoff under Regulation (EU) 2024/1860, approaching, the time available to evaluate, procure, and deploy an M2M integration is short for most SME readers. Manual UI for a small portfolio or XML bulk upload for a mid portfolio is the realistic deadline-aligned answer for many readers in the second half of 2026.
| Method | Portfolio size | Data readiness | Engineering capacity | Deadline pressure |
|---|---|---|---|---|
| Web UI | Small (typically tens of records or fewer) | Light; data can be entered as it is identified | None required | Compatible with short windows for small portfolios |
| XML bulk upload | Mid to large (tens to hundreds of records) | Structured data assumed; XML conforms to published XSDs | RA team plus an XML-generating tool, or developer time | Compatible with second-half 2026 deadlines if the data is ready |
| M2M | Continuous-churn portfolios at multinational scale | Structured data assumed and maintained in an external system | Managed-service vendor or in-house engineering plus operations | Insufficient runway in 2026 for most new integrations |
How EUDAPrep fits (and where it does not)
EUDAPrep prepares the XML for the bulk-upload method. The tool extracts device-data fields from uploaded source documents (instructions for use, labels, declarations of conformity, technical files, safety data sheets), proposes candidate values for the fields the EUDAMED data dictionary requires, proposes EMDN codes from the Commission’s published list, and runs deterministic validation of the assembled record against the EC’s published XSDs and business rules before generating the XML file. The manufacturer (or their PRRC) downloads the validated XML and uploads it through the EC portal. EUDAPrep does not submit to EUDAMED.
None of the three submission methods help if the underlying device data is not already structured. Building that structured data, extracting fields from IFUs, labels, declarations of conformity, and technical files into the rows EUDAMED’s data dictionary requires, is the load-bearing work. The upload step sits at the end of that preparation, not in place of it.
The upstream point is the load-bearing one. The M2M tools available for EUDAMED solve the upload step; they assume the structured device data already exists. For most SME manufacturers, building that structured data, turning IFUs, labels, and declarations of conformity into the rows EUDAMED’s data dictionary requires, is the actual work. EUDAPrep sits at that upstream step. The bulk-upload mechanic at the end is the result of the preparation, not the substitute for it.
EUDAPrep’s extraction layer uses LLM-assisted parsing of unstructured source documents with explicit disclosure consistent with the AI Act Article 50 transparency principle. The deterministic validator that runs against the EUDAMED XSDs and the EC business rules does not depend on LLM output.