Prepare EUDAMED bulk XML that can survive submission
A reliable bulk-upload process converts approved device data into the current EUDAMED XML structure, validates the service envelope and entity model, checks controlled values and business rules, then reconciles every processing result. It is semi-automated: software prepares the file, while an authorised user performs the upload.
Need an XML batch produced, checked, and reconciled—not only explained?
Yarify implements the controlled path from approved source records to a reviewable bulk-upload package, then connects EUDAMED processing results back to the records and owners who can resolve them.
What the engagement produces
- A versioned source-to-EUDAMED mapping and generation pipeline
- XML packages with layered validation and reviewer-readable evidence
- Record-level response handling, correction, and reconciliation
What bulk upload is—and when it is the right path
The Commission describes XML upload/download as a semi-automated mode: XML generation can be automated, but the upload or download action is manual. The same guidance distinguishes it from individual UI entry and automatic M2M backend exchange. See the official data-exchange comparison.
Bulk XML is usually useful when repeated UI entry is no longer proportionate, but the organisation does not need—or is not ready to operate—the Access Point and support model required for M2M. It is also a practical controlled release path when device data already comes from Excel, ERP, PIM, PLM or a normalized internal database.
The Commission gives indicative bands of up to 100 devices for the UI, 100–1,000 for XML upload and above 1,000 for M2M. These are guidance, not legal thresholds. Update frequency, data quality, repeated structures, approvals and operating capacity can matter more than the raw count. See modes of data input.
Good fit
Recurring, reviewable batches; structured source data; repeated attributes; a permitted uploader; and a need to reduce manual re-entry without operating M2M.
Weak fit
A handful of low-change records, no governed source dataset, or an expectation that XML generation will decide missing regulatory facts.
Signal to assess M2M
Frequent releases, sustained high volume or a requirement for unattended transport and automated response collection. The data and validation foundation is still needed.
Prerequisites before XML generation starts
A generated file cannot repair missing account permissions, unresolved product facts or ambiguous record ownership.
Actor and user access
The official Devices module training identifies the actor as a Manufacturer or System/Procedure Pack Producer and requires the logged-in user to have the Confirmer profile for UDI Devices. Confirm the production account and role before scheduling a batch—not after the XML is approved. See the official training material.
Approved device facts
Basic UDI-DI and UDI-DI relationships, device attributes, packaging and applicable references must come from an accountable source. Software can expose missing or contradictory values; it should not invent classification or applicability decisions.
Current technical baseline
Download and version the applicable service and entity XSDs, samples, definitions, business rules, enumerations and dictionaries. EUDAMED publishes these as separate technical artefacts; do not treat one schema file as the whole contract. See the technical documentation catalogue.
Source data to reconciled upload: the complete workflow
XML creation is one stage in a controlled data operation. The highest-value controls sit on both sides of the serializer.
| Stage | Input | Required control | Evidence produced |
|---|---|---|---|
| Freeze the source extract | Excel, CSV, ERP, PIM, PLM or database records | Record the source system, export time, record keys and owner so the batch can be reproduced. | Versioned source snapshot |
| Normalize the device data | Source-specific tables and repeated columns | Represent actors, Basic UDI-DIs, UDI-DIs, packages and dependent records explicitly rather than inferring them during XML generation. | Canonical device dataset |
| Transform approved values | Internal codes, labels, dates and identifiers | Apply documented mappings to current EUDAMED enumerations and formats; return unknown values to an owner. | Target-ready values with provenance |
| Run completeness preflight | Normalized target data | Check required, conditional and cross-record dependencies before serializing a batch. | Resolvable exception report |
| Generate the XML | Approved, normalized records | Use the service operation, entity model and version that match the current EUDAMED technical release. | Deterministic XML package |
| Validate structure and rules | Generated XML | Check well-formedness, the applicable XSD, enumerations and pre-implementable business rules in separate layers. | Validation report and release status |
| Approve and upload | Validated file plus a human-readable manifest | An accountable reviewer approves the facts; a permitted EUDAMED user performs the authenticated upload. | Submitted batch and correlation evidence |
| Process the result | EUDAMED response, notifications and record outcomes | Separate accepted records from rejected records and map every issue back to the source key and field. | Correction queue and accepted-state ledger |
| Reconcile and retry | Corrected exceptions and accepted versions | Regenerate only the intended changes, prevent duplicate operations and preserve the complete submission history. | Reconciled internal and EUDAMED states |
The XML contract is a set of artefacts, not one XSD
The official catalogue separates service schemas, model schemas, samples, definitions, rules, enumerations and data dictionaries. A production generator must record which compatible versions it used for each batch.
| Artefact | Question it answers | Risk if ignored |
|---|---|---|
| DTX service XSD | Is the service envelope structurally valid? | The XML can fail before the entity payload is evaluated because elements, types or ordering do not match the service contract. |
| Entity model XSD | Does the device data use the expected model structure? | Device elements, repeated groups, relationships or data types can be serialized in an unsupported form. |
| Official XML samples | How are supported operations represented in example messages? | A team may interpret the schema correctly in isolation but assemble the service and entity layers incorrectly. |
| Service definition | Which operation, message and response semantics apply? | A structurally valid payload can request the wrong operation or be handled with incorrect response assumptions. |
| Business rules | Which submitted values and relationships are allowed together? | The file may pass XSD validation but fail semantic checks during EUDAMED processing. |
| Enumerations | Which controlled values are accepted for limited-choice fields? | Internal labels or legacy codes may not match the code expected by the active data model. |
| Data dictionaries | What does each entity and attribute mean in its module context? | Technically correct values can be mapped to the wrong target field or at the wrong level of the hierarchy. |
| Version and compatibility documentation | Which service and entity-model releases work together? | Previously accepted XML can fail after a release if schemas, rules or compatibility assumptions are stale. |
Illustrative processing structure
This deliberately schematic example is not a valid EUDAMED payload and must not be uploaded. It shows the boundaries a generator should manage; use the active official XSDs and samples for real element names and structure.
<Submission
service="[current service operation]"
modelVersion="[compatible entity version]">
<CorrelationId>[internal batch id]</CorrelationId>
<DeviceRecords>
<Device sourceKey="[stable internal key]">
<BasicUdiDi>[approved identifier]</BasicUdiDi>
<UdiDi>[approved identifier]</UdiDi>
<Attributes>[mapped target values]</Attributes>
</Device>
</DeviceRecords>
</Submission>Do not copy current schema versions or file-size limits from an old implementation note. Confirm the active technical package, compatibility rules and operation-specific limits before every release. The official service definition explains operation and versioning semantics.
Why XSD-valid does not mean EUDAMED-valid
XSD validation checks document structure and types. The Commission separately publishes business rules and enumerations, which means semantic and controlled-value checks are not exhausted by schema validation.
The exact returned messages depend on the service, record and active release. The table uses failure classes rather than inventing stable error codes.
| Validation / processing layer | Typical symptom | Likely cause | Useful resolution path |
|---|---|---|---|
| XML syntax | The parser cannot read the document. | Malformed tags, unescaped characters, invalid encoding or an incomplete file. | Reject the generated file automatically and fix the serializer or source character handling. |
| Schema selection | Expected elements or namespaces are not recognised. | The generator used an incompatible service or entity-model version. | Pin compatible artefact versions for each run and regenerate; do not hand-edit the XML. |
| XSD structure | An element is missing, out of sequence or has the wrong data type. | The canonical model or serializer does not reflect the active XSD cardinality and ordering. | Map the XSD path back to the source record and correct the model or transformation. |
| Enumeration | A submitted value is outside the accepted controlled list. | An ERP label or legacy code was passed through instead of mapped to the current EUDAMED value. | Use a versioned lookup and send unmapped values to a data owner rather than guessing. |
| Conditional dependency | A value becomes required, prohibited or inconsistent because of another value. | The batch passed field-level checks but not cross-field business logic. | Evaluate the relevant dependency before release and show both fields in the exception. |
| Record relationship | A child record cannot be resolved or the hierarchy is inconsistent. | Basic UDI-DI, UDI-DI, package or referenced-record keys were duplicated, omitted or joined incorrectly. | Validate graph relationships and submission order in the canonical dataset before serialization. |
| Operation or state | A create or update request conflicts with the record already known to EUDAMED. | The internal system has stale identifiers, versions or outcome status from an earlier submission. | Reconcile accepted state first, then generate the correct operation from that state. |
| Actor permission | The user cannot perform the device bulk-upload action. | The selected actor context or user profile does not meet the module prerequisite. | Confirm the actor and authorised Confirmer profile before the release window. |
| Batch outcome | The team records one upload result while individual records need different actions. | Batch-level tracking hides record-level acceptance and rejection details. | Parse and retain outcomes by source key, correlation reference and operation; retry only resolved failures. |
A useful error report points back to the source
Return at least: batch identifier, source system, source record key, Basic UDI-DI or UDI-DI where available, operation, XML path, validation layer, rule or message, offending value, severity, suggested owner and resolution status. A raw parser message without source context forces RA and data teams to reverse-engineer the file.
The dedicated EUDAMED XML validator guide covers this validation pipeline in depth.
The upload package should be operable, not just valid
Treat the manual transmission boundary as a release process. The uploader needs to know exactly what is in the file, who approved it and where to place the response.
Release checklist
- Source snapshot and immutable batch identifier
- Mapping, enumeration, XSD and business-rule versions used
- Machine-readable XML file generated from approved data
- Human-readable manifest listing operations and source record keys
- Zero unresolved blocker errors in the preflight report
- Named data owner and regulatory approver for unresolved judgement calls
- Named EUDAMED user with the required actor context and profile
- Storage location for the submitted file, response and correction evidence
Before upload
Freeze the approved payload, validation report and manifest. Verify account access in advance. Preserve the exact file; do not allow last-minute spreadsheet or XML edits outside the generator.
During processing
Capture the upload time, user, actor context and any correlation or response references. A successful file transfer is not proof that every intended record was accepted.
After processing
Reconcile outcomes at record level. Lock accepted versions, route rejected records to owners and create a new controlled batch for corrections. Never overwrite the evidence from the original run.
What Yarify can implement
We can build source adapters, a canonical device-data model, versioned field transformations, XML generators, validation pipelines, review manifests, error worklists and reconciliation tooling around your EUDAMED upload process. The manufacturer and its qualified regulatory advisers remain responsible for classification, applicability and approval of the submitted facts. The software does not guarantee MDR or IVDR compliance.
Continue with the guide that owns your next problem
This page covers the bulk file and upload lifecycle. These guides own source transformation, deep validation, transport selection and portfolio migration.
Excel to EUDAMED XML
Prepare spreadsheet columns, controlled values and one-to-many device structures before XML generation.
Open guide →EUDAMED XML validator
Go deeper into syntax, XSD, enumeration, dependency and business-rule validation layers.
Open guide →UDI registration requirements
Review technical data prerequisites and dependencies without turning software rules into regulatory conclusions.
Open guide →Manual vs XML vs M2M
Choose a submission mode using portfolio size, update frequency, setup effort and operating workload.
Open guide →EUDAMED M2M integration
Assess automatic backend exchange when manual file transmission is no longer proportionate.
Open guide →EUDAMED data migration
Convert legacy portfolio data into a normalized, validated and reconciled device dataset.
Open guide →For the broader operating model, see UDI registration automation or return to the EUDAMED automation hub.
Bulk XML questions
What is EUDAMED bulk XML upload?
It is a semi-automated data-exchange mode. Software can prepare and validate structured XML against current EUDAMED technical artefacts, while an authorised user still uploads the file through EUDAMED and reviews the processing result. It is different from M2M, which automates backend transport.
Who can bulk upload UDI/device records?
The official Devices module training states that the actor must be a Manufacturer or System/Procedure Pack Producer and the logged-in user must have the Confirmer profile for UDI Devices. Teams should re-check the active module guidance and their actual account permissions before a planned upload.
How many devices justify EUDAMED bulk upload?
The Commission gives indicative—not legally binding—guidance of UI entry up to 100 devices, XML upload for 100–1,000 and M2M above 1,000. Update frequency, source-data quality, repeated attributes, approval flow and support capacity can make a different route more appropriate.
Is XSD-valid XML guaranteed to be accepted by EUDAMED?
No. XSD validation tests structure and data types. EUDAMED also publishes controlled enumerations and business rules, and processing can depend on relationships, references, operation semantics and existing record state. These layers need separate checks.
Can EUDAMED XML be generated from Excel or an ERP?
Yes, but the source must first be mapped into an explicit device-data model. The workflow should detect missing values, transform internal controlled values, preserve record relationships and trace every generated field back to its source or approved rule.
Does EUDAMED XML preparation guarantee MDR or IVDR compliance?
No. Technical preparation and validation can identify structural, controlled-value and rule conflicts. They do not determine device classification, regulatory applicability or the correctness of approved product facts. Yarify provides software implementation, not regulatory advice or a compliance guarantee.
Primary sources
Reviewed 9 September 2026. EUDAMED technical artefacts are versioned and can change. Re-check active schemas, rules, enumerations, service definitions, compatibility guidance and module release notes before production generation.
European Commission — EUDAMED overview
Official module status, including mandatory use of the UDI/Device module since 28 May 2026
EUDAMED Information Centre — Guidelines on Data Exchange
Official distinction between manual UI entry, semi-automated XML upload/download and automatic M2M exchange
EUDAMED Information Centre — Bulk uploading and downloading
Official entry point for structured XML exchange guidance and module-specific bulk operations
European Commission — Devices module training material
Official device bulk-upload prerequisites, user profile requirements and references to the technical artefacts used to prepare XML
EUDAMED Information Centre — Modes of data input
Official indicative portfolio-size guidance for the UI, XML upload and M2M data-exchange modes
EUDAMED Information Centre — Technical documentation
Official catalogue of DTX XSDs, XML samples, service definitions, business rules, enumerations and data dictionaries
EUDAMED Information Centre — Service definition
Official explanation of message types, operations, queries, responses, security, pagination and service versioning
European Commission — EUDAMED business rules
Official common data-exchange rules describing conditions evaluated when information is submitted
European Commission — EUDAMED enumerations
Official controlled values used for fields with a limited set of accepted options