An EUDAMED XML validation error is a rejection the EUDAMED bulk upload service returns when your file fails one of three checks: a structural check on the whole file, a data check on each device, and, for some devices, a Notified Body confirmation step that follows later. This page pairs the common rejections at each check with the literal fix. It assumes you have already signed in, run a bulk upload, and had a rejection come back, rather than that you are still working out what EUDAMED is. Which of the three checks fired is the fastest thing you can read off the response, and it points straight at who fixes what. As of this article’s last review, the current schema is v3.0.30 and the platform release is v2.27.0.
The structural check on the file rejects the whole upload when the XML does not match the schema. Nothing is processed. Fix the file and resubmit.
The per-device data check runs on each device on its own. Valid devices in the same batch are accepted; only the failing ones come back in the response, each with the EC business rule that broke.
Notified Body confirmation is the third check and applies only to Class III and Class IIb implantable devices. The Basic UDI-DI sits in Submitted status until the notified body confirms it.
What EUDAMED tells you when your upload fails, and what it doesn’t
The bulk upload service returns a response file for every submission. You download it from the Response column in the Upload management table once processing has finished. Each device you submitted comes back marked either SUCCESS or ERROR, and only the ERROR rows need another look. The EC’s help page on the bulk upload flow sets out the model plainly: a batch of several devices is processed one device at a time, and the outcomes are gathered into a single response.
What an ERROR row gives you is the error code, the identifier of the object it attaches to when there is a recognisable one, and a short note on the rule that was broken. What it does not always give you is the exact field that failed. For some rejections the response sits at the record level, not the field level, and finding the field means comparing the failing record against a known-good sample. That gap, between what EUDAMED returns and what your team needs to fix the source, is the reason this page exists.
A response row looks like this, in outline:
ErrorCode: E-I-40000
ObjectId: 0123ABC-BASIC-UDI-DI
RuleViolated: Element could not be matched to a known object
Location: (not provided)The shape of the response depends on which check fired. A structural failure rejects the whole file with no per-device detail. A per-device failure returns each failing device with the rule that broke. A device waiting on notified-body confirmation sits in Submitted status with no rejection at all until the notified body acts.
Why one file gets rejected outright and another gets rejected in pieces
The three checks run in order. A file that fails the first never reaches the second, and a device that fails the second never reaches the third. Which one fired is the fastest read on your response. If the whole file bounced, the problem is structural. If some devices came back accepted and others rejected, the problem is in the data of the ones that failed. If a Class III device is sitting in Submitted status with no rejection, you are waiting on your notified body, not on a fix.
The plain names are worth pinning to the formal ones once, because the EC documents and the vendor tools use the formal set. The structural check is XSD validation. The per-device data check is business-rule validation. The third is Notified Body confirmation. This page uses the plain names from here on.
| What EUDAMED did | What your response looks like | Where the fix lives |
|---|---|---|
| The structural check rejected the whole file | Whole file rejected, no per-device detail | The XML itself: your RA data team, or IT if a tool generates the file |
| The per-device check rejected specific devices | Some devices come back SUCCESS, the failing ones ERROR with the rule that broke | The source record for each failing device, with the notified body on certificate rows |
| Notified Body confirmation is pending | No rejection; the Basic UDI-DI sits in Submitted status | The notified body’s workflow: you wait |
On a small team those labels collapse into the people you actually have. The structural fixes are the file itself, so they sit with whoever generates it: your IT function, or the external consultant who runs your uploads today. The per-device fixes are your source data, so they sit with your Quality Engineer or RA, with the PRRC signing off on anything that changes a device’s grouping or declaration. Reading which check fired tells you which of the two to hand the response to.
The structural check runs against the schema the EC publishes on its Technical Documentation page; the current version is v3.0.30, matched to platform release v2.27.0. The per-device check runs against the business-rule PDFs the EC publishes beside the schema. The confirmation step applies Article 29 of Regulation (EU) 2017/745 to devices in scope for Annex IX or Annex X.
The common rejections and the specific fix for each
The two checks that produce almost every rejection are the structural check on the file and the per-device data check. The rules behind the per-device check are the ones the EC publishes in its UDI Devices business rules, and they validate against the UDI Devices data dictionary on the same page. The two catalogs below pair each rejection with the fix and name who on your side does the fixing. Your response gives you a code and a short rule text; match the rule text to the pattern in the catalogs below, and use the EC’s Annex 1 to translate the numeric code if you need to.
Structural rejections: what breaks the whole file
A structural rejection means the XML itself does not match the schema. The response is all or nothing: the whole upload bounces, with no per-device detail. The fix is in the file, not in the data.
| Error pattern | Root cause | Fix | Who fixes this |
|---|---|---|---|
| Malformed XML the parser cannot read | An unescaped character in a text field, an unclosed element, or a file saved in the wrong encoding | Escape the special characters, close every element, save as UTF-8 | Your RA data team, or IT if a tool generates the file |
| Missing required field | A core mandatory field left out: UDI-DI code, risk class, EMDN code, intended purpose | Add the field and populate it from the source data | Your RA data team |
| Wrong data type | Text in a number field, or a date written as 01/03/2026 rather than 2026-03-01 | Use the type the schema expects; dates in ISO 8601 (YYYY-MM-DD) | Your RA data team |
| Field too long | A free-text field longer than the schema allows | Trim to the limit the data dictionary lists for that field | Your RA data team |
| Value not on the allowed list | Risk class entered as the label (Class IIa) instead of the schema code (IIA), or a code from a stale extract | Use the code from the EC’s published list, not the human-readable label | Your RA data team |
| Too many or too few of a field | A field repeated more often than the schema allows, or a required group left out | Match the count of each element to what the schema allows | Your RA data team |
| Schema version mismatch | The file was built against an older schema after EUDAMED moved to a newer one | Download the current schema from the Technical Documentation page and regenerate | IT, or the vendor whose tool emits the file |
| Attachment reference does not resolve | The XML points at an attachment by a path that is not in the upload | Check every attachment reference points at a file included under the right path | Your RA data team, or IT if a tool assembles the upload |
The most common structural rejection is a value that is not on the allowed list, and the usual culprit is the risk class. Risk class is a coded field. The label is Class IIa; the code the schema wants is IIA. Files hand-mapped from a labelling spreadsheet fail this constantly.
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 EC’s published list pass. A label, a translation, or a vendor’s internal code all fail the same way. The element names and values here are illustrative; take the exact tags and codes from the data dictionary and the published enumerations.
If becoming your own in-house EUDAMED XML expert is not the capability you want to build, EUDAPrep runs the same structural check against the EC’s current schema and tells you which field failed and why. The RA team reads the flagged field, the source or the emitting tool gets the fix, and the file re-runs. The check is deterministic, not a guess.
Per-device rejections: what breaks specific devices
A per-device rejection means the file was structurally clean but one or more devices failed the EC’s business rules. Valid devices in the same batch are accepted and written to the database; the failing ones come back with the rule that broke and, where the rule allows, a short note pointing at the field. The rules are the ones the EC publishes in the UDI Devices business rules beside the schema.
| Error pattern | Root cause | Fix | Who fixes this |
|---|---|---|---|
| Duplicate Basic UDI-DI | A Basic UDI-DI already registered under your SRN is submitted again as new | Use the update path, not the insert path; the EC samples cover both | Your RA data team |
| Grouping mismatch | A Basic UDI-DI groups devices with different intended purposes, risk classes, or essential design characteristics, against the Basic UDI-DI grouping rules in MDCG 2018-1 Rev. 4 | Split the group into per-purpose, per-risk-class, per-design Basic UDI-DIs and reassign the UDI-DIs | Your RA data team, with PRRC sign-off on the regrouping |
| Conformity-assessment mismatch | The procedure declared does not qualify under the Annex combination for the device’s risk class | Realign the declared procedure with the device’s Annex combination; MDCG 2018-1 Rev. 4 is the reference | Your RA data team and the notified body |
| Legacy tagged as new, or new tagged as legacy | The legislative-framework tag is wrong; the legacy path uses a EUDAMED-DI rather than a Basic UDI-DI | Set the correct framework tag; legacy devices follow a separate path | Your RA data team |
| UDI-DI length wrong | A 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 the file is generated | Your RA data team, or IT |
| UDI-DI check-digit failure | The check digit was recomputed wrong during relabelling, or transcribed from poor OCR | Recompute per the issuing entity’s rule (GS1, HIBCC, IFA, ICCBBA) and regenerate | Your RA data team |
| Orphan UDI-DI | A UDI-DI submitted without a Basic UDI-DI parent it can resolve to | Submit the Basic UDI-DI first, or point the UDI-DI at an existing parent | Your RA data team |
| Obsolete EMDN code | A code from a stale extract; the EC has pruned the list since you pulled it | Refresh the extract and pick a terminal EMDN code from the current list | Your RA data team |
| Non-terminal EMDN code | A parent node picked instead of a leaf; the device needs the most granular, terminal term | Re-select the terminal (leaf-level) term under the same branch | Your RA data team |
| Certificate not in EUDAMED yet | The notified body has not uploaded the certificate to the Certificates module | Coordinate with the notified body to upload it, then resubmit | Your RA data team and the notified body |
| Certificate scope mismatch | The certificate does not cover the device’s risk class, Annex combination, or intended purpose | Cite a certificate whose scope covers the device, or query the notified body | Your RA data team and the notified body |
| Expired certificate | The certificate expired or was withdrawn before the device was submitted | Cite the active certificate; without one the device cannot register on this path | Your RA data team and the notified body |
| SRN role not active | The actor record exists but the asserted role (manufacturer, importer, distributor, pack producer) is not active | Activate the role on the actor record; roles are activated separately from the actor | Your RA data team |
| Non-EU manufacturer without an Authorised Representative | A non-EU manufacturer submits without a linked EU AR, against Article 11 | Link the AR’s actor record; the AR has to be registered with an active role | Your RA data team and the AR |
When the per-device check is where your batch is failing, the lever is the upstream source data, not the XML. EUDAPrep runs every one of the EC’s published business rules against your file and, on each rejection, names the rule that broke and the field it broke on. Your RA team reads the list, fixes the source record, and re-runs the batch. There is no rules document to hand-parse and no in-house rule set to keep in sync with the EC’s next revision. EUDAPrep uses the EC’s published rules directly and updates when the EC does.
Notified Body confirmation: the sub-population case
The third check applies only to Class III devices and Class IIb implantable devices under Annex IX or Annex X, per Article 29 of Regulation (EU) 2017/745. Once a Basic UDI-DI clears the first two checks, it sits in Submitted status until the relevant notified body confirms it. Confirmation is the notified body’s workflow, not something you control. If your devices are outside that scope, you can skip this section.
| Blocker | Root cause | Who fixes this |
|---|---|---|
| Wrong Annex declared | The Basic UDI-DI declares an Annex combination that does not match the device’s actual conformity-assessment route | Your RA team, with PRRC sign-off on the revised declaration |
| Notified body not designated for the Annex combination | The notified body holds the certificate but is not designated in NANDO for the Annex combination declared | Your RA team and the notified body |
| Certificate not uploaded | The notified body has not uploaded the certificate to the Certificates module | The notified body; you wait |
| Grouping changed after the certificate issued | Regrouping after the certificate was issued leaves its scope no longer covering the new group | Your RA team and the notified body |
| Notified-body backlog before the deadline | The notified body’s queue runs longer than your planning window before 28 November 2026 | The notified body; ease it by submitting confirmations early |
Submitted status is not a rejection. The record exists in EUDAMED; what is outstanding is the notified-body step that moves it to Registered.
Before you upload: catching these upstream
The way to stop the next batch going the same way is to run the same two checks EUDAMED runs, on your file, before you upload. The first is the structural check against the current schema. The second is the field-by-field check against the business rules the EC publishes beside it. Both live on the EC Technical Documentation page. The EC also runs a Playground environment alongside Production, so you can push a full test upload through the same checks without writing to the live database.
| # | Pre-upload check | What it catches |
|---|---|---|
| 1 | Validated against the current schema (v3.0.30 / platform v2.27.0) | Structural |
| 2 | Every required field populated against the data dictionary | Structural |
| 3 | All dates written in ISO 8601 (YYYY-MM-DD) | Structural |
| 4 | UDI-DI padded to the issuing entity’s length (14 digits for GS1) | Per-device |
| 5 | Risk class matches the technical file and the certificate’s coverage | Per-device |
| 6 | Conformity-assessment procedure matches the certificate’s Annex combination | Per-device |
| 7 | EMDN codes current and terminal (leaf-level) | Per-device |
| 8 | Basic UDI-DI grouping consistent: same intended purpose, risk class, and essential design per group | Per-device |
| 9 | Device description matches the Declaration of Conformity | Per-device |
| 10 | Actor SRN active and role correct | Per-device |
| 11 | Certificates uploaded by the notified body before the device references them | Per-device |
| 12 | Legacy versus Regulation framework tag correct | Per-device |
| 13 | Attachments referenced in the XML are included under the right path | Structural |
| 14 | No duplicate UDI-DI in the batch | Per-device |
| 15 | A Playground test upload completed end-to-end | All three checks |
The real decision the checklist forces is whether to build that pre-upload check in-house, with the engineering time and the standing job of tracking every EC revision that comes with it, or to run the file through a tool that already carries the current EC files and updates when the EC does. EUDAPrep is the second option. It runs both checks on your file, the structural check against the current schema and every published business rule against your file, and shows you which fields failed and why before the file leaves the tool. The check is deterministic, not a guess. The workflow is the same whether your in-house RA function or an external consultant runs it: the operator reviews what failed and fixes the source, the PRRC signs off, and you upload through the EC portal. For the CFO, the comparison is not the tool price alone. It is the tool cost plus the review hours your PRRC and consultant still put in, set against a full from-scratch engagement. EUDAPrep does not submit to EUDAMED on your behalf.