An EUDAMED XML validation error is a rejection emitted by the EUDAMED data exchange (DTX) service when an uploaded XML file fails one of three sequential validation layers: XSD schema validation, business-rule validation, or Notified Body confirmation. This page catalogues the common rejection patterns at each layer and pairs each with the literal fix. It assumes you have already signed in, attempted at least one bulk upload, and received either an HTTP error or a per-object error list back. Current EUDAMED platform release: v2.22.0. Current XSD schema version: v3.0.25.
XSD schema validation rejects the whole file when the XML is structurally invalid. Nothing is processed. Fix the file, resubmit.
Business-rule validation runs per object. Valid objects in the same payload are accepted; only the failing objects come back in the response with an error message attached.
Notified Body confirmation is the third layer and applies only to Class III and Class IIb implantable devices. The Basic UDI-DI sits in Submitted status until the NB confirms.
What EUDAMED tells you when your upload fails, and what it doesn’t
The EUDAMED bulk upload service returns a structured response for every submission. The response is downloadable from the Response column in the Upload management table once the upload has finished processing. The EC’s help page on the bulk upload flow describes the model directly: “If the XML payload request contains multiple objects (e.g. a DEVICE.POST with multiple devices), the DTX service will process each object individually and gather the response in one single file related to the initial request.” Some objects come back as SUCCESS and others as ERROR; only the ERROR objects need a resubmit.
What the response gives you is the error code from the EUDAMED Annex 1 code dictionary, the object identifier where the error attaches to a recognisable object, and a short rule violated text. What it does not always give you is an XPath to the failing element. For some rejection classes the EUDAMED side has no element-level location to report; the rejection is at the object level, and finding the specific field involves comparing the failing object against a known-good sample. The mismatch between the structured detail in the response and the diagnostic detail the reader needs is the reason this page exists.
A response row looks like this, conceptually:
ErrorCode: E-I-40000
ObjectId: 0123ABC-BASIC-UDI-DI
RuleViolated: Element could not be mapped to known objects
Location: (not provided)The fix path differs by which layer fired: at the XSD layer the response is binary (the whole file rejected, no per-object detail); at the business-rule layer the response carries the rule identifier per object; at the NB confirmation layer the device sits in Submitted status with no rejection at all until the NB acts.
The three validation layers
EUDAMED applies three layers in sequence. A payload that fails layer 1 never reaches layer 2; a payload that fails layer 2 never triggers layer 3. The fix path runs in the same order.
| Layer | What it checks | What rejection looks like | Partial-batch processing | Who can fix |
|---|---|---|---|---|
| 1. XSD schema | Structural validity of the XML against the published XSD pack | Whole file rejected, no per-object processing, no per-object detail in the response | No (file-level rejection) | RA data team or IT / engineering, depending on where the XML is generated |
| 2. Business rule | Semantic validity of each object against the EC’s published business rules | Per-object rejection, with rule identifier and short message; valid objects in the same payload are accepted | Yes | RA data team for content issues; NB coordination for certificate linkage |
| 3. NB confirmation | Confirmation by the Notified Body for Class III and Class IIb implantable Basic UDI-DI | No explicit rejection; the Basic UDI-DI persists in Submitted status until the NB confirms or refuses | n/a | Notified Body operations, on the NB-side workflow the manufacturer does not control |
Layer 1 validates against the XSD pack the EC publishes at the Technical documentation page; the current version is v3.0.25, mapped to platform release v2.22.0. Layer 2 validates against the business-rule PDFs published next to the XSD. Layer 3 invokes Article 29 of Regulation (EU) 2017/745 for the Notified Body confirmation step on devices in scope for Annex IX or Annex X.
The Playground environment runs the same three layers against a parallel platform version (v3.27.3 at the time of writing). A Playground upload catches most XSD and business-rule failures before they hit Production.
XSD schema validation errors
XSD validation is the first gate. The DTX service loads the relevant XSD from the XSD schemas.zip pack at the Technical documentation page, parses the submitted XML against it, and rejects the whole file when any element violates the schema. The response does not carry a per-object catalog at this layer; it tells you the file failed structural validation and stops. The fix is in the file, not in the data.
A generic XML validator (xmllint, or an XML-aware editor with XSD support) loaded with the EUDAMED XSD pack catches every error in the table below. The pack is the same one the DTX service uses; local results match production behaviour at this layer.
The XSD failure catalog
| Error pattern | Root cause | Fix | Who can fix | Pre-export check that would have caught it |
|---|---|---|---|---|
| Malformed XML, parser cannot read the file | Unescaped character in a text field; unclosed element; encoding declared as UTF-8 but file is Windows-1252 | Validate and escape special characters (&, <, >, ', "); close every opened element; save as UTF-8 without BOM | RA or IT, depending on the generator | Run xmllint against the file before upload; the parser error names the line |
| Sequence violation | Child element appears in an order the schema does not allow under its parent | Re-order child elements to match the schema’s sequence definition | RA or IT, where the generator emits the wrong order | XSD validation locally reports sequence violation with the offending element |
| Missing mandatory element | Required field omitted (UDI-DI code, risk class, EMDN code, intended purpose) | Add the missing field; populate from source data | RA data team | XSD validation reports minOccurs violation with the element name |
| Invalid data type | Text in a numeric field; a date written as 01/03/2026 rather than ISO 8601 2026-03-01 | Use ISO 8601 (YYYY-MM-DD) for every date field; cast numeric values without quotes | RA data team | XSD validation reports the type-mismatch element name |
| Field length exceeded | Free-text description longer than the schema’s max-length annotation | Trim to the limit defined in the relevant data dictionary; the dictionary lists the cap per field | RA data team | XSD validation reports maxLength violation |
| Invalid enumeration value | Risk class entered as the human-readable label (Class IIa) instead of the schema code (IIA); EMDN code from a stale extract | Use the schema enumeration code from the relevant enumerations PDF, not the human-readable label | RA data team | XSD validation reports enumeration violation against the element |
| Incorrect namespace declaration | XML emitted against an older XSD namespace; vendor library hardcoded to a previous version | Update the namespace declaration to the current XSD version; regenerate from the current schema | IT or vendor | XSD validation rejects the file at namespace resolution |
| XSD version mismatch | File produced against a stale XSD version after EUDAMED has bumped the schema | Download the current XSD schemas.zip from the Technical documentation page and regenerate | IT or vendor | The Technical documentation page lists the current version against the platform release |
Worked example: enumeration-value mismatch
The most common XSD failure is the enumeration-value mismatch on the risk class field. Risk class is an enumerated field with codes defined in UDI Devices - enumerations. The human-readable label is Class IIa; the schema code is IIA. Files generated by hand-mapping from a labelling spreadsheet routinely fail this rule.
Invalid:
<Device>
<UDIDICode>05012345678901</UDIDICode>
<RiskClass>Class IIa</RiskClass>
<EMDNCode>W0101010101</EMDNCode>
<IntendedPurpose>Diagnostic imaging accessory</IntendedPurpose>
</Device>Valid:
<Device>
<UDIDICode>05012345678901</UDIDICode>
<RiskClass>IIA</RiskClass>
<EMDNCode>W0101010101</EMDNCode>
<IntendedPurpose>Diagnostic imaging accessory</IntendedPurpose>
</Device>Only the codes on the published enumeration list pass. A human-readable label, a translation, or a vendor-internal code all fail with the same enumeration violation message.
Business-rule validation rejections
The second layer is semantic. The XML parsed cleanly against the schema; every required element is present, every type is correct, every enumeration code resolves. EUDAMED now checks each object against the published business rules and rejects only the objects that fail. Valid objects in the same payload are accepted and written to the database. The response file lists the failing objects with the rule identifier the EC publishes in the relevant business-rule PDF (EUD Common - business rules, ACT - business rules, CRF - business rules, UDI Devices - business rules). Each rule has a numeric identifier the response cites; the mental model is per-object, not per-file.
Basic UDI-DI rejections
| Error pattern | Root cause | Fix | Who can fix | Pre-export check that would have caught it |
|---|---|---|---|---|
| Duplicate Basic UDI-DI | A Basic UDI-DI already registered against the manufacturer SRN is being submitted as an insert | Use the update service path (UDI_009), not the insert (UDI_001); the Annex 2 sample set covers both | RA data team | Cross-check the source list against the EUDAMED-side already-registered Basic UDI-DI export |
| Grouping mismatch | Basic UDI-DI groups devices with different risk classes, different intended purposes, or different conformity assessment procedures: violates Annex VI part C | Split the group into per-risk-class, per-intended-purpose, per-procedure Basic UDI-DIs and reassign UDI-DIs accordingly | RA data team, with PRRC sign-off on the regrouping | The data dictionary’s grouping section names the rule; verify before bulk-assigning Basic UDI-DI |
| Conformity-assessment procedure mismatch | Procedure declared on the Basic UDI-DI does not qualify under the Annex combination for the device’s risk class | Realign the declared procedure with the device’s Annex combination; consult MDCG 2018-1 Rev. 4 | RA data team and NB coordination | Compare the declared procedure against the certificate’s Annex coverage line by line |
| Missing parent link | A UDI-DI submitted without a resolvable link back to its parent Basic UDI-DI | Submit the Basic UDI-DI first (or update the UDI-DI to reference an existing parent); the UDI-DI cannot exist as an orphan | RA data team | The data model requires Basic UDI-DI before UDI-DI; sequence the upload accordingly |
| Legislative-framework mismatch | A legacy device tagged as Regulation rather than Directive (MDD / AIMDD / IVDD); a new device tagged as legacy | Set the correct legislative-framework tag; the legacy path uses an EUDAMED-DI rather than a Basic UDI-DI | RA data team | The legacy path is in scope only for devices on extended certificates under Regulation (EU) 2024/1860 |
UDI-DI, EMDN, certificate, and operator rejections
| Error pattern | Root cause | Fix | Who can fix | Pre-export check that would have caught it |
|---|---|---|---|---|
| UDI-DI length wrong | GTIN not padded to 14 digits (GTIN-8 needs 6 leading zeros; GTIN-12 needs 2; GTIN-13 needs 1) | Pad to 14 digits in the source data before XML generation | RA data team or IT | GTIN length check at the source extract |
| UDI-DI check-digit failure | Check digit recomputed incorrectly during relabelling or transcribed from poor OCR | Recompute per the issuing-entity rule (GS1 / HIBCC / IFA / ICCBBA) and regenerate | RA data team | A check-digit validator across the source list |
| Orphan UDI-DI | UDI-DI submitted without a resolvable Basic UDI-DI parent | Submit the Basic UDI-DI first, or update the UDI-DI to reference an existing parent | RA data team | Sequence: Basic UDI-DI then UDI-DI |
| Obsolete EMDN code | Code from a stale EMDN extract; the EC has pruned the selection list since export | Refresh the EMDN extract against the current EC portal; pick the active leaf-level code | RA data team | Re-pull EMDN within seven days; the EC publishes update notices |
| Non-leaf EMDN code | A parent (non-terminal) EMDN node selected; only the most granular term validates | Re-select the most specific leaf-level term under the same branch | RA data team | The EMDN portal flags terminal vs non-terminal; pick only terminal |
| Certificate not in EUDAMED at link time | NB has not yet uploaded the certificate to the Certificates module | Coordinate with the NB to upload the certificate; resubmit once visible | RA data team and NB | Verify every cited certificate number resolves in the EUDAMED-side list |
| Certificate-device scope mismatch | Certificate does not cover the device’s risk class, Annex combination, or intended purpose | Use a certificate whose scope covers the device; query the NB if scope is unclear | RA data team and NB | Compare certificate scope against the device record line by line |
| Expired certificate | Certificate expired or withdrawn before the device record was submitted | Cite the active certificate; without one the device cannot register under this path | RA data team and NB | Check every cited certificate is in Active status |
| NB designation scope mismatch | NB not designated for the Annex combination declared, per the NANDO database | Switch to a properly designated NB, or change the declared procedure | RA data team and NB | NANDO lookup against the NB SRN before submission |
| SRN not active for the asserted role | Actor record exists but the asserted role (manufacturer, importer, distributor, SPP producer) is not active | Verify the role on the actor record; the Actor module activates roles separately from actor existence | RA data team | Pull the actor’s role list before submitting |
| Product Designer SRN missing | A device that requires a Product Designer SRN omits the field | Populate the SRN per the data dictionary’s mandatory-field list for the relevant classes | RA data team | Cross-check the data dictionary against the source data |
| Non-EU manufacturer without Authorised Representative | A non-EU manufacturer submits without a linked EU AR, contrary to Article 11 | Link the appointed AR’s actor record; the AR must be registered with an active role | RA data team and AR | Verify the AR’s actor record before submission |
If the business-rule layer is the dominant rejection class on your batch, the upstream source data is the lever. A pre-export validator can run the published rules against the candidate XML and surface the rule identifier on each rejection before the file reaches EUDAMED.
Notified Body confirmation bottlenecks
The third layer applies only to Class III devices and Class IIb implantable devices under Annex IX or Annex X conformity assessment, per Article 29 of Regulation (EU) 2017/745. After the Basic UDI-DI passes the XSD and business-rule layers, it sits in Submitted status until the relevant Notified Body confirms it. Confirmation is an NB-side workflow the manufacturer does not control.
| Blocker | Root cause | Who can fix |
|---|---|---|
| Wrong Annex declared on the manufacturer side | The submitted Basic UDI-DI declares an Annex combination that does not match the device’s actual conformity assessment route | Manufacturer’s RA team, with PRRC sign-off on the revised declaration |
| NB designation scope does not cover the Annex combination | The NB cited holds the certificate but is not designated in NANDO for the Annex combination declared on the Basic UDI-DI | Manufacturer’s RA team and NB; resolved by realignment of either the declaration or the certificate |
| Certificate not uploaded to the Certificates module | NB has not yet uploaded the certificate; the device cannot confirm against a certificate the database cannot see | NB operations; manufacturer waits |
| Basic UDI-DI grouping changed after certificate issuance | Device regrouping after the certificate was issued leaves the certificate scope no longer covering the new grouping | Manufacturer’s RA team and NB; resolved by a revised certificate or revised grouping |
| NB processing backlog ahead of the deadline | NB queue depth exceeds the manufacturer’s planning window in the run-up to 28 November 2026 | NB operations; mitigated by submitting Basic UDI-DI confirmations early in the run-up window |
Submitted status is not a rejection: the device record exists in EUDAMED; what is outstanding is the NB confirmation that moves it to Registered. Readers outside the Class III and Class IIb implantable scope can skip this layer.
Pre-export validation: what to run before you upload
The pattern that scales is to run XSD validation and business-rule validation locally against the published artefacts before any Production upload. The EC publishes both at the Technical documentation page; a Playground upload exercises both layers end-to-end. The fifteen-row checklist below covers the patterns that surface most often in the rejection tables above.
| # | Pre-export check | Layer addressed |
|---|---|---|
| 1 | XSD validated against the current schema (v3.0.25 / platform v2.22.0) | XSD |
| 2 | Every mandatory field populated against the data dictionary | XSD |
| 3 | All date fields written in ISO 8601 (YYYY-MM-DD) | XSD |
| 4 | UDI-DI padded to the issuing entity’s length spec (14 digits for GS1) | Business rule |
| 5 | Risk class matches the technical file’s classification rationale and the certificate’s coverage | Business rule |
| 6 | Conformity-assessment procedure matches the NB certificate’s Annex combination | Business rule |
| 7 | EMDN codes are current (refresh within seven days) and leaf-level terminal terms | Business rule |
| 8 | Basic UDI-DI grouping is internally consistent (one risk class, one intended purpose, one CA procedure per group) | Business rule |
| 9 | Device description matches the Declaration of Conformity | Business rule |
| 10 | Actor SRN active and role correct (manufacturer, importer, distributor, system or procedure pack producer) | Business rule |
| 11 | Certificates uploaded by the NB to the Certificates module before the device record references them | Business rule |
| 12 | Legacy versus Regulation framework tag correct per Regulation (EU) 2024/1860 status | Business rule |
| 13 | Attachments referenced inside the XML are included in the ZIP under the correct FileURI path | XSD and business rule |
| 14 | No duplicate UDI-DI within the same batch | Business rule |
| 15 | Playground upload completed end-to-end against the same payload | All three |
EUDAPrep runs the XSD layer and the business-rule layer against the current published EUDAMED schema and the EC business-rule documents, surfaces failures with the XPath of the failing element where the schema reports a location and with the rule identifier where the business-rule layer reports a rule, and emits bulk-upload-ready XML once both layers pass. The validator is deterministic: schema and rule comparisons, no language-model inference. The PRRC reviews and signs off; the manufacturer uploads through the EC portal.