For the wider context of XML upload as one of three EUDAMED submission methods, see the EUDAMED registration pillar.
What the EC actually publishes (and what it does not)
There is no single Excel file or single PDF named EUDAMED XML template. The asset that turns a manufacturer’s device data into a portal-ready file is assembled from the EC EUDAMED Information Centre Technical Documentation page. Six asset categories sit on that page: a set of data dictionaries in Excel naming every element the schema expects; a set of business-rule and enumeration PDFs naming the semantic constraints the XSD cannot encode; three sample-XML ZIPs split by actor type (competent authorities, economic operators, and notified bodies); the XSD schemas ZIP holding the structural definitions for every data-exchange service; three services-definition PDFs naming the machine-to-machine services per actor type; and a Format of the Unique Device Identifiers for the Legacy Devices PDF. A separate Annex 2 (XML files index) page on the EUDAMED Information Centre maps every published sample to its use case.
The misnaming is the reason the related-search queries cluster on template excel, template pdf, template free, and bulk upload template. The Excel files the EC publishes are the data dictionaries, the field-level reference. The PDFs are the business rules and the services definitions. The free downloads are the whole asset set. The “bulk upload template” the reader expects is the combination of the right sample XML, the relevant dictionary as a field map, the XSD validated against, and the business-rule PDF read for semantic constraints. The asset list and the route into it are the page’s load-bearing reframing.
The XSD schema set: versions, downloads, and version drift
The XSD schemas the EC publishes sit in a single archive, XSD schemas.zip, on the Technical Documentation page. The archive contains the structural definitions for every data-exchange service the platform exposes: actor download and assessment services, device upload and update services, certificate download services, and the rest. As of June 2026 the page’s version note names XSD schemas v3.0.25 mapped to platform release v2.22.0. The version moves with the platform; a release affects the XSD version number that data-exchange service requests have to declare. The EC’s note on the page is explicit: the XSD version number in service requests has to be adapted before each platform release.
Three implications follow. First, the version your file declares has to match the version the platform currently accepts. The Technical Documentation page is the source of truth. Verify the version before every production generation run and again before every quarterly review of your tooling. Second, third-party tools and downstream member-state databases reference different XSD versions at different times. As one example, the Swissmedic Technical Documentation page for Swissdamed references its own XSD version, which may sit ahead of or behind the EUDAMED page on any given day. The version drift across tooling is the reason an XML file emitted from one vendor’s converter and validated against that vendor’s bundled XSD can still fail at the EUDAMED upload step: the version checked locally was not the version the platform expects. Third, an XSD validates structure: required elements, type constraints, enumeration restrictions, cardinality. It does not validate semantic constraints across elements (a Basic UDI-DI grouping rule, an EMDN code being terminal, a certificate being properly linked). Those constraints live in the business-rule PDFs and the platform itself enforces them at upload.
| Asset | What it is | Format | Where it lives | Free or paid |
|---|---|---|---|---|
| XSD schemas.zip | Structural schema for every data-exchange service | ZIP of XSD files | EC Technical Documentation page | Free |
| Data dictionaries | Field-level reference per data domain (Common, Actor, UDI/Devices, Certificates) | XLSX | EC Technical Documentation page | Free |
| Business-rule and enumeration PDFs | Semantic constraints the XSD does not encode; enumeration lists | EC Technical Documentation page | Free | |
| Sample XML packs | Worked sample files split by actor type (CAs, EOs, NBs) | ZIP of XML files | EC Technical Documentation page | Free |
| Annex 2 (XML files index) | File-by-file index of every sample mapped to use case and actor | HTML reference | EUDAMED Information Centre | Free |
| Services-definition PDFs | Per-actor machine-to-machine service definitions | EC Technical Documentation page | Free | |
| Format of UDIs for Legacy Devices | Legacy device identifier format spec | EC Technical Documentation page | Free |
The EC sample XML files: where to start, what each file shows
The most direct route from “I have a device to register” to “I have a working sample to adapt” runs through the Annex 2 (XML files index) page. The page presents a single table mapping every published sample file to a use case, an actor type, and a result type (positive scenario or negative scenario, where negatives demonstrate validation failures). The naming convention follows a domain prefix and a use-case number: ACT for actor services, UDI for device services, CRF for certificate services. Inside each domain the number identifies the service variant.
For the in-house RA preparing a first device upload, the most-used UDI samples are:
- SAMPLE_DTX_UDI_001.xx.xml for registering a new MDR device Basic UDI-DI and UDI-DI. Sub-variants cover Class I (001.01), Class III with certificate linkage (001.03), and several negative scenarios that show what the validator catches.
- SAMPLE_DTX_UDI_002.xx.xml for registering a new IVDR device. Sub-variants cover Risk Class A (002.01) and Risk Class C with the Submitted-to-Registered status transition on notified-body linking (002.03).
- SAMPLE_DTX_UDI_003.01.xml for a system or procedure pack with a single Basic UDI-DI.
- SAMPLE_DTX_UDI_005.xx.xml for legacy devices, with sub-variants for Class I MDD (005.01), AIMDD (005.02), and IVD legacy under Annex II List A (005.03).
- SAMPLE_DTX_UDI_007.xx.xml for market-information updates; 008.02 for adding a new UDI-DI under an existing Basic UDI-DI; 009.xx and 010.xx for Basic UDI-DI and UDI-DI updates respectively; 015.xx for product-original-manufacturer updates.
The Actor samples follow the same pattern with the SAMPLE_DTX_ACT_xxx prefix; certificate samples use SAMPLE_DTX_CRF_xx. The negative-scenario files (001.02, 001.04, and so on) are reference material for the validation-errors satellite: they show the schema responses to the most common rejection cases.
Once the sample is identified, the work is to replace the sample data with your own values per the relevant data dictionary, keep the structure intact, validate against the current XSD, and read the relevant business-rule PDF for the semantic constraints that the XSD does not encode. The samples are the closest thing the EC publishes to the template the search query asks for, and they ship as part of the three actor-split ZIPs on the Technical Documentation page.
Four routes to a valid XML, and which one fits which shop
The asset set supports four realistic routes to a working file. Each fits a different combination of device count, engineering capacity, and budget. The decision matrix below names the inputs.
| Route | Device count fit | Engineering effort | Time to first valid file | Ongoing cost driver | Article 50 surface |
|---|---|---|---|---|---|
| Excel-driven hand assembly against the EC dictionaries, manual or scripted conversion to XML | 1 to ~50 devices | Low to medium; RA-led | Days | RA hours per quarterly update | Low unless AI is used in extraction |
| Vendor XML converter (commercial tool that ingests Excel and emits validated XML) | ~10 to ~500 devices | Low engineering; vendor configuration | Days to weeks | Tool subscription plus RA review hours | Medium where the tool layers AI in extraction |
| In-house pipeline emitting XML from PLM, QMS, or ERP source systems against the EC XSD | 50 to 1,000+ devices, recurring updates | Medium to high; engineering-led | Weeks to months | Build cost, ongoing maintenance, validation infrastructure | Medium where data extraction layers AI |
| Managed-service handoff to a regulatory consultancy or specialist provider that produces and uploads the file | Any | Zero engineering on the manufacturer side | Negotiated | Service fee per submission or per device | Depends on the provider’s own data-extraction practice |
The first route assumes the source data is reasonably clean and the manufacturer has the RA capacity to map it field by field. The second shifts the conversion to a vendor; the schema and the business rules still apply, but the manufacturer is paying for the conversion layer and the upload-feedback loop rather than for the file itself. The third is the right shape when devices update frequently (label changes, packaging revisions, periodic market-information refreshes) and the cost of re-running the conversion manually exceeds the build cost of automating it. The fourth removes the file from the manufacturer’s day-to-day workflow and pays a regulatory consultancy to operate it. The public regtech framing of this question, often reduced to a binary between “build it yourself” and “enter the data manually”, omits routes one and four; both are real choices.
Where any route uses AI-assisted extraction or transformation against upstream technical documentation (extracting fields from IFUs, labels, declarations of conformity), the Article 50 disclosure obligation under Regulation (EU) 2017/745 applies. Frame any LLM-assisted extraction as structured assistance for manual review by the PRRC, not as autonomous regulatory judgment.
The constraints the schema does not show
A reader who reads the XSD straight through will miss several constraints that decide whether the file uploads cleanly. The Swissmedic Technical Documentation page for Swissdamed, which mirrors the EUDAMED-side limits, names two of the most consequential.
The first is the 300 Basic UDI-DI / UDI-DI pair limit per file. A manual XML upload cannot exceed 300 pairs. Larger portfolios are split across multiple files and uploaded sequentially. The split is operational, not regulatory: there is no requirement for any particular grouping, but the file size has to respect the limit.
The second is the 1:1 Basic UDI-DI / UDI-DI grouping constraint for the manual upload service. A file that registers multiple UDI-DIs under a single Basic UDI-DI uses a different service path (the multi-UDI add service, represented in Annex 2 by samples such as SAMPLE_DTX_UDI_008.02.xml). Trying to register a multi-UDI-DI group through the manual upload service returns a schema-level rejection.
Beyond these two, the DTX services-definition PDFs (one per actor type: CAs, EOs, NBs) name the per-service constraints that decide what each actor is allowed to do through the data-exchange layer. The economic-operator definition covers the upload and update services manufacturers use day-to-day. The competent-authority definition covers the assessment and download services. The notified-body definition covers the certificate-publication services. The mapping between actor type and service availability is the reason a file that passes XSD validation can still be rejected on a service-eligibility basis: the actor whose credentials the file is being submitted under is not authorised for the service the file invokes.
A final set of constraints comes from the status transitions. A device registered through SAMPLE_DTX_UDI_001.03 or SAMPLE_DTX_UDI_002.03 will start in Submitted status and transition to Registered only on notified-body linking. A device whose certificate has not yet been published in the Notified Bodies & Certificates module stays in Submitted; this is a process gate, not a file defect.
Pre-upload validation: XSD layer, business-rule layer, and what only EUDAMED catches
Two validation layers exist on the manufacturer side; a third only the platform itself runs. The first is XSD validation, which any generic XML validator (xmllint, the XML tools in most IDEs, the validators built into M2M libraries) will run if given the file and the relevant XSD from the schemas ZIP. The XSD catches missing required elements, type mismatches, invalid enumeration values, malformed XML, and cardinality breaches. It does not catch anything that depends on semantic relationships between elements.
The second is business-rule validation, which the EC publishes as a set of PDFs on the Technical Documentation page. The PDFs cover common rules (EUD Common), actor rules (ACT, AIM), certificate rules (CRF), and device rules (UDI Devices). The rules name semantic constraints the XSD cannot encode: a Basic UDI-DI / UDI-DI hierarchy has to be consistent, an EMDN code has to be terminal (a leaf in the EC’s nomenclature tree) for the device category named, a certificate referenced on a device record has to exist and link back to the right notified body, a sterile-flag has to align with the device category enumerations, and so on. The PDFs are read in advance; the rules are then implemented either as a validation pass in the conversion pipeline or as a manual review against the rule list.
The third layer is the platform’s own response. The EC Guidelines on Data Exchange v2.12 document the response model: when EUDAMED accepts a file the response is asynchronous and arrives as a status update against the original submission. When it rejects, the response cites an error code from the Annex 1 catalogue and sometimes, but not always, an element-level location. Schema-layer rejections are usually element-precise; business-rule rejections are not. The post-rejection page covers the common codes and fixes; common EUDAMED XML validation errors and the fixes is the place to go after a rejected upload.
The practical sequence is short: validate against the current XSD locally before upload (xmllint or any equivalent works), read the relevant business-rule PDF before generation, then upload and read the asynchronous response. Skipping the XSD pre-validation step is the cheapest source of avoidable rejection cycles.
Free assets, paid tooling, and where the differentiation actually sits
Every asset the EC publishes on the Technical Documentation page is free, as are the Annex 2 index, the error-code annex, and the rest of the EUDAMED Information Centre documentation. The platform itself charges no fee for the upload.
Paid offerings exist around all of this in three categories. Paid Excel templates sold as data containers with mappings pre-built against the EC dictionaries; what they sell is the mapping layer, not the underlying dictionaries (which are free). XML converter tooling that ingests Excel or another structured source and emits validated XML; what they sell is the conversion layer, the XSD pre-validation, and a feedback loop that catches some business-rule failures locally rather than at upload time. Managed-service handoffs that produce and submit the file on the manufacturer’s behalf; what they sell is consultancy time and the operational handling of the upload cycle, not the file itself.
The decision is not free-versus-paid in the abstract. It is about where the manufacturer’s time and risk sit. A 12-device portfolio in stable categories does not justify an in-house build; it might justify a paid converter; it usually does not justify a managed-service handoff. A 200-device portfolio with frequent updates and an internal data engineering function justifies the build. The EC asset set is the floor for all four routes.