Europe IT Consulting · Practical EUDAMED knowledge
EUDAMED error library: investigate causes and correct UDI data
An EUDAMED error can only be addressed precisely once the feedback has been linked to a record, a field and a processing step. This error library helps Regulatory Affairs, Quality Management and IT systematically check UDI identifiers, mandatory fields, packaging, XML structures and updates.
Start with your source data and the actual message. This establishes a focused review task, a correction confirmed by the responsible specialists and a controlled resubmission. The entries describe editorially prepared error patterns—not official error codes or a ranking of the most frequent EUDAMED rejections.
Europe IT connects this data work with validation and submission processes: in the Global Submission Portal, directly from GUDI/SAP or within the agreed XML project. The actual error and the permitted change procedure determine which correction is required.
Primary sources checked on · Reference framework: European Commission EUDAMED production help and technical documentation
What exactly failed?
“The data did not go through” is not enough for a diagnosis. First record where the feedback originated and which objects are affected. Successful transmission does not automatically mean that all records were processed successfully.
Source & pre-check
An import or validation error before sending? Compare the template, mapping and original data.
Access & transmission
No access or no clearly confirmed dispatch? Check the environment, actor, permissions and technical process.
Authority processing
A response is available? Read the result for each object and identify the rule being challenged.
Internal evidence
The approved version or result cannot be traced? This is initially a process issue.
Before resubmitting: Separate objects that have already succeeded from error cases. EUDAMED explicitly describes mixed results within a bulk upload. How to handle partially successful uploads. Source: Bulk upload: processing and feedback.
How to read the entries: The symptom and possible cause are not a final diagnosis. The original message, field, current service and device context are decisive. The review steps are editorial recommendations; the linked primary sources support the field or process interpretation explicitly stated in each entry. A technical “fix” does not replace a regulatory decision.
Identifiers & data source
SRN, Basic UDI-DI, UDI-DI, labelling and the mapping of your source data.
01 Actor · Permissions
SRN, manufacturer or actor role does not match
How to recognise the issue: The feedback refers to an actor, missing permissions or an incorrect manufacturer assignment.
Check first
Compare the affected record with the actor actually used, its role and the target environment. Distinguish an incorrect SRN in the content from missing permissions for the user or M2M process.
Control the correction
Correct the verified assignment at the data source. For access issues, the responsible administrators check access; using another SRN merely to bypass the message is not a solution.
For the next run: Assign responsibility for actor data and document production assignments separately from test data.
Context: Actor, user profile and M2M permissions are different review points. Source: Actors and roles · M2M prerequisites.
02 Identifier · Relationship
The Basic UDI-DI cannot be found or is referenced incorrectly
How to recognise the issue: A UDI-DI cannot be linked to the expected Basic UDI-DI record.
Check first
Check the Basic UDI-DI, issuer, manufacturer and environment. Clarify whether the selected service includes the reference or whether it already exists in the appropriate state. Distinguish a missing reference from another invalid state.
Control the correction
Resolve transmission or mapping errors using the approved device assignment. Do not spontaneously assign an existing device identity to a different Basic UDI-DI.
For the next run: Use a controlled reference list and check relationships before export.
Context: Stored Basic UDI-DI identification data is subject to restrictions on later changes. Source: Basic UDI-DI: data and conditions.
03 Identifier · Format
Issuing Entity or code format is incorrect
How to recognise the issue: Validation flags an identifier, its issuing entity or its format.
Check first
Compare the original identifier, identifier type and Issuing Entity. Check for spaces, truncated characters and whether another identifier type has accidentally been mapped to the field.
Control the correction
Use the demonstrably assigned value from the authoritative source. Valid codes from different issuing entities must not be rewritten merely to achieve a uniform appearance.
For the next run: Validate issuer and identifier type together; test format checks using approved sample data.
Context: Passing a Basic UDI-DI format check does not prove that the identifier was correctly assigned in substance. Source: Basic UDI-DI: data and conditions.
04 Data quality · Field mapping
Device Name, model and trade name are mixed up
How to recognise the issue: Names cannot be reconciled between the source, device documentation and submitted record.
Check first
First map source fields to the correct EUDAMED field and data level. Determine whether there is an actual mandatory-field error or merely inconsistent internal naming.
Control the correction
Agree approved names with the data owners. Before changing existing registrations, check which field may be changed through which process.
For the next run: Document the mapping between name, model and reference number.
Context: For Basic UDI-DI, name and model requirements depend on the selected model information. Source: Basic UDI-DI: data and conditions.
05 Identifier · Field meaning
Unit of Use, Secondary UDI-DI and packaging UDI are confused
How to recognise the issue: An identifier is in the wrong field or does not match the described packaging situation.
Check first
Check each field individually. Unit of Use, Secondary UDI-DI and the UDI-DI of a packaging level are not interchangeable terms.
Control the correction
Clarify each use case using labelling documentation and the current field help. Only then correct the mapping and affected records.
For the next run: Include field guidance and examples in the template rather than placing every additional code in one combined field.
Context: EUDAMED describes Unit of Use and Secondary UDI-DI as separate data items with their own conditions. Source: UDI-DI: identification data.
06 Labelling · Production identifiers
UDI-PI types do not match the labelling
How to recognise the issue: The stored PI information conflicts with the labelling information actually used.
Check first
Compare the selection with the approved labelling and production process. Distinguish the PI type used from a specific lot or serial number value.
Control the correction
Correct the selection together with those responsible for labelling. Do not activate every conceivable PI type as a precaution.
For the next run: Include labelling changes in the review of UDI master data.
Context: The registration form records UDI-PI types, such as serial number, lot and relevant date types. Source: UDI-DI: identification data.
07 Labelling · Applicability
Direct marking information is incomplete
How to recognise the issue: The direct marking does not match the information stored for it.
Check first
First check whether direct marking applies in the specific device and registration context. Then compare the actual marking with the mapped field.
Control the correction
Document the specialist decision and maintain the applicable identifier information. Do not change a selection merely because doing so makes a mandatory field disappear.
For the next run: Approve the labelling evidence and the record together.
Context: For direct marking, the EUDAMED help distinguishes between identical and different identifiers. Source: UDI-DI: identification data.
08 Data quality · Possible duplicate warning
Catalogue or material numbers are duplicated
How to recognise the issue: Several rows or devices cannot be clearly distinguished in the source system.
Check first
Determine whether the feedback actually concerns the catalogue field or a UDI identifier. A duplicate internal material number is not automatically the same rule violation as a duplicate UDI-DI.
Control the correction
Correct the internal assignment using a unique technical key. Do not renumber assigned device identifiers without a substantive basis.
For the next run: Manage internal keys, catalogue numbers and UDI-DIs as separate data fields.
Context: The Business Rules describe a warning for the same Reference Number used by the same manufacturer/producer. Such a warning must be distinguished from a confirmed rejection. Source: UDI/Devices Business Rules.
09 Identifier · Existing record
The UDI-DI already exists
How to recognise the issue: EUDAMED indicates that an identifier is already registered.
Check first
Search for the record using issuer and UDI-DI. Check the manufacturer, registration context and earlier submission results: a previous submission may already have succeeded.
Control the correction
Use the existing record to decide whether an update, a permitted link or a correction at the source is needed. Do not repeat it as a new registration without checking.
For the next run: Reconcile the existing authority records with the local status before submission.
Context: Special rules on shared identifiers apply to certain legacy/regulation device combinations; check the specific relationship. Source: UDI-DI: identification data.
10 Source · Import/export
Excel or the export changes identifiers
How to recognise the issue: Identifiers lose leading zeros, are truncated or appear in scientific notation.
Check first
Compare the original value with the template, exported file and content actually imported. Find the first point at which the value changes.
Control the correction
Restore the verified original value and correct the import/export configuration. Do not guess missing digits or reconstruct them solely from the displayed number.
For the next run: Treat identifiers as text and test data transfers with zeros, long codes and special characters.
Context: Editorial recommendation on data quality; not a named EUDAMED error code.
Regulatory framework & device characteristics
Check fields in the correct context—not just missing values.
11 Regulatory framework · Applicability
MDR, IVDR or registration context is selected incorrectly
How to recognise the issue: The displayed or expected fields do not match the device documentation.
Check first
Check the approved regulatory framework and registration type before changing individual mandatory fields. Do not copy field logic from another device record without comparing the context.
Control the correction
Have the responsible specialist team confirm the assignment, then correct the mapping and dependent values.
For the next run: Review regulatory framework and registration type as a preliminary step.
Context: The information in the Basic UDI-DI form differs between MDR and IVDR. Source: Basic UDI-DI: data and conditions.
12 Classification · Specialist review
Risk class and device characteristics are inconsistent
How to recognise the issue: The classification, device attributes and technical documentation do not form a coherent picture.
Check first
Compare the approved classification with the submitted characteristics. Identify the specific rule being challenged; not every internally unusual value automatically means an EUDAMED rejection.
Control the correction
Correct verified input or mapping errors. Selecting another risk class to pass validation is not an acceptable correction.
For the next run: Review class and relevant characteristics together.
Context: Several core Basic UDI-DI fields cannot be freely changed in updates. Source: UDI/Devices Business Rules.
13 Characteristics · Field mapping
Latex, tissue or cell information is copied indiscriminately
How to recognise the issue: One Yes/No value is copied into several different characteristic fields.
Check first
Check latex, human or animal tissues/cells and other substance information separately against the device documentation. Also compare the applicable regulatory framework.
Control the correction
Adjust the assignment field by field. A single combined field for all material characteristics is not a sufficient substantive basis.
For the next run: Document a source and a responsible data area for each characteristic field.
Context: The EUDAMED help covers latex and tissue/cell information in separate sections; the fields depend on context. Source: UDI-DI: characteristics · Further device information.
14 IVDR · Device characteristics
IVDR-specific information is missing or incorrect
How to recognise the issue: Information such as self-testing has not been taken from the device documentation.
Check first
Compare the intended purpose and applicable IVDR characteristics with the record. Do not infer a characteristic solely from the product name or a similar MDR record.
Control the correction
Have the substantive assignment confirmed; correct source and mapping together.
For the next run: Include IVDR-specific review questions in data approval.
Context: The Basic UDI-DI form contains device characteristics that depend on the regulatory framework. Source: Basic UDI-DI: data and conditions.
15 Field rule · Language
Language information or multilingual texts do not match
How to recognise the issue: A language-related entry is missing or has been assigned to the wrong text.
Check first
Identify the exact field and its language condition. Distinguish language-dependent device texts from language-independent codes or designations.
Control the correction
Add the appropriate language information and an approved text. Do not force the same language across all fields indiscriminately.
For the next run: Check language and text as a related value pair in the mapping.
Context: Language conditions depend on the field; certain “Other” entries require a description and language. Source: UDI-DI: characteristics.
16 Characteristics · Conditional mandatory fields
Storage & Handling Conditions are incomplete
How to recognise the issue: Storage or handling conditions are missing, or a selected special case is not described.
Check first
Compare the selected conditions with the approved device information. Pay particular attention to additional descriptions and language entries.
Control the correction
Add verified missing values. Free text should not replace an existing suitable code-list option merely to simplify mapping.
For the next run: Validate the selected value and required additional fields together.
Context: For “Other” storage/handling conditions, the EUDAMED help requires a description with a language. Source: UDI-DI: characteristics.
17 Characteristics · Specialist review
Sterility and sterilisation before use are unclear
How to recognise the issue: The stored information cannot be reconciled with the label and instructions for use.
Check first
Check “Device labelled as sterile” and “Needs sterilisation before use” individually in the specific registration context. Do not present a seemingly unusual combination as a technical rejection reason without evidence of the rule.
Control the correction
Correct verified discrepancies with the responsible specialist team, not by automatically switching Yes to No.
For the next run: Review labelling, instructions for use and structured characteristics together.
Context: Editorial review question on data quality. The two entries must be checked separately; no automatic exclusion rule is assumed here.
18 MDR · Device characteristic
Reusable Surgical Instrument is assigned incorrectly
How to recognise the issue: The characteristic field was populated from a general reusability statement.
Check first
Check the exact field context and the approved device classification. Reuse in everyday practice and the specific regulatory characteristic must not be equated without checking.
Control the correction
Have the assignment confirmed by the responsible specialists. For already registered data, check the permitted change procedure first.
For the next run: Explicitly document the meaning of the field in mapping and review.
Context: Restrictions on Basic UDI-DI changes apply to core characteristics such as this one. Source: UDI/Devices Business Rules.
19 Nomenclature · Version
The EMDN code is no longer suitable or has changed
How to recognise the issue: The nomenclature selection triggers a notice or no longer matches the registered device.
Check first
Compare the EMDN code used with the current selection and its change history. Determine whether only the code list has changed or also the appropriate substantive classification.
Control the correction
Have possible successor codes assessed before updating the record. A similar-sounding code is not a sufficient replacement.
For the next run: Include changes to the nomenclature used in the regular data review.
Context: The EUDAMED help describes notices for EMDN codes that have been removed, split or changed in scope. Source: UDI-DI: identification data.
Status & packaging
Distinguish registration, market information and packaging hierarchy.
20 Status · Meaning
Market status, record status and transmission status are confused
How to recognise the issue: A record is considered “finished” internally, but is not in the expected state.
Check first
Read the exact status name and its context. “Transmitted”, a registration state and EU market information describe different matters.
Control the correction
Correct the actual status error or address the outstanding process step. Do not set a device to “active” indiscriminately.
For the next run: Maintain a status table with separate columns for the local process, authority processing and market information.
Context: Depending on the certificate context, the initial state after submission may be “Submitted” rather than “Registered”. Source: Packaging levels and registration status.
21 Packaging · Relationship
The packaging hierarchy is incomplete
How to recognise the issue: A packaging level is missing, or the quantity and relationship cannot be traced.
Check first
Map the packaging levels actually used. Compare identifier, issuer, quantity, parent relationship and status with the submitted data.
Control the correction
Add information that is demonstrably missing. Do not make an incorrect hierarchy fit by changing quantities arbitrarily.
For the next run: Reconcile the packaging specification and master data together before submission.
Context: Higher packaging levels are recorded with their own identifier and quantity. Source: Packaging levels and registration status.
22 Packaging · Status rule
Packaging status cannot be changed as expected
How to recognise the issue: Status options are unavailable or the change has a different effect than expected.
Check first
First check the market status of the associated UDI-DI. Then compare the intended change with the designated packaging process.
Control the correction
Use the permitted update procedure. An internal justification does not replace a technical status condition.
For the next run: Review device and packaging status within a shared change-control process.
Context: The help restricts packaging status changes to the described device market status; packaging information has its own update process. Source: Updating packaging.
Certificate references
Check certificate information where relevant to the specific registration.
23 Certificates · Applicability
Certificate, notified body or revision cannot be traced
How to recognise the issue: The certificate reference does not match the approved documentation or the registration concerned.
Check first
First check whether certificate information is applicable in this context. Then compare notified body, certificate type, number and existing revision information.
Control the correction
Correct transcription or transmission errors using valid documentation. Clarify unresolved certificate questions with the responsible body; do not fill gaps with invented placeholders.
For the next run: Maintain a controlled certificate register and use changes as a trigger for data review.
Context: Certificate information and any confirmation by the notified body depend on the specific device context. Source: Certificate information.
XML, processing & updates
Clearly distinguish technical structure, substantive result and resubmission.
24 XML · Technical validation
XML schema error or EUDAMED business rule?
How to recognise the issue: The feedback names an element, data type, structure or violated rule.
Check first
Record the complete error text, affected object reference and, where applicable, the line. Check whether the file matches the selected service and its schema or whether substantive relationships are being challenged.
Control the correction
Fix structure/mapping problems in the export; correct substantive errors at the approved data source. Then validate again against the appropriate specification.
For the next run: Maintain XSD, code lists, mapping and business rules as separate, versioned validation references.
Context: The technical documentation distinguishes XSD, Service Definition, Business Rules, Enumerations and Data Dictionaries. Source: Technical documentation: XSD, services, rules · Transmission methods and XML validation.
25 Service · Existing registration
An update is sent as a new registration
How to recognise the issue: The submission does not match the existing record or triggers a duplicate notice.
Check first
Compare the target identifier, existing record and intended change. Establish which service and change process were actually triggered.
Control the correction
Choose the designated update process and respect field editability. Do not bypass every conflict by using a new identifier or creating another registration.
For the next run: Explicitly distinguish new registrations and changes in the submission workflow.
Context: For the relevant device changes, EUDAMED provides for creating and submitting a new version. Source: New version and market status.
26 Processing · Result per object
The upload succeeded, but individual objects contain errors
How to recognise the issue: The file was accepted or processed, but not all individual results are successful.
Check first
Open the response and link each result to its object. Separate successful objects, failed objects and statuses that remain unclear.
Control the correction
Correct the flagged objects and resubmit only those. Do not blindly repeat successfully processed objects in the same new-registration run.
For the next run: Keep a submission log with object identifiers and results, not just a single status for the file.
Context: EUDAMED processes objects in a bulk payload independently; a response can contain both SUCCESS and ERROR. The help requires resubmission of failed objects only. Source: Bulk upload: processing and feedback.
27 Update · Data version
The version does not match the intended change
How to recognise the issue: An existing record cannot be updated with the supplied version.
Check first
Compare the authority’s data version, local data version, last successful change and the version requirement of the actual service used.
Control the correction
First establish the correct starting version and generate the change according to the current service specification. Do not alter version values by trial and error or blanket resets.
For the next run: Coordinate parallel changes and bring confirmed results back into the local process.
Context: The Business Rules contain service-specific version conditions; no universal version number can be inferred for every update case. Source: UDI/Devices Business Rules.
Approval & evidence
Identify internal process risks without presenting them as official rejection reasons.
28 Internal process · Not an official error code
Data was changed without traceable approval
How to recognise the issue: The submitted version cannot be clearly traced back to a reviewed data version.
Check first
Compare the export, approved source and changes made after review. Clarify who must approve a substantive correction.
Control the correction
Establish a controlled data version. If data has already been submitted, check the actual authority records before triggering another change.
For the next run: Define data ownership, review, approval and submission responsibilities in the internal procedure.
Context: This recommendation concerns internal process quality. Missing internal approval does not automatically constitute a technical EUDAMED rejection.
29 Internal process · Traceability
The submission was completed, but evidence of the result is missing
How to recognise the issue: It is not possible to demonstrate later which data version was submitted and how it was processed.
Check first
Find the source data version, submitted file or transaction and corresponding authority response. Check whether only dispatch evidence was archived rather than a processing result.
Control the correction
Organise existing evidence by submission run and object. Do not replace missing evidence with an unnecessary repeat submission.
For the next run: Define storage, naming convention and the responsible role. Link results and correction runs.
Context: Editorial documentation recommendation; no EUDAMED rejection reason is claimed.
A controlled correction run—from feedback to result
- Preserve the feedback: Record the original text, object identifier, service, environment and time. Include an error code only if it actually appears in the message.
- Narrow down the cause: Source, mapping, permissions, schema or business rule? Assign the review question to the responsible person.
- Correct and check the source: Do not fix only the export file. Otherwise the next run may generate the same error again.
- Approve and submit selectively: Handle successful objects, failed objects and changes separately; use the appropriate service.
- Reconcile the result: Review the new authority response and link it to the source data version and correction run.
For the internal error list: Object · Original message · Entry in this library · Cause · Responsible person · Correction status · Result. Further guidance: Compile submission evidence systematically.
Address errors where your UDI data originates
A single rejection often prompts a clearer organisation of the entire data flow. Europe IT supports UDI data preparation, validation and submission. The source, solution and technical transmission method remain distinct.
Excel → GSP → EUDAMED
In the Global Submission Portal, the customer uploads the completed template. The data is validated automatically. If there are no validation errors, the customer triggers submission using “Submit”. For EUDAMED, GSP uses M2M; status and authority feedback support subsequent processing.
SAP / GUDI → EUDAMED
With GUDI, the customer maintains and checks UDI data in the SAP-based process and submits it directly from GUDI to authorities via M2M. GUDI can retrieve and display transmission status and authority feedback. No additional manual upload to the GSP portal is required.
Validated data → XML → manual upload
At the customer’s request, Europe IT checks the completed Excel data, generates XML files after successful validation and manually uploads them to EUDAMED within the agreed project. XML generation and manual upload must be distinguished from M2M transmission.
Clear responsibility: In GSP and GUDI processes, the customer resolves substantive data errors and initiates resubmission. Pre-validation replaces neither substantive responsibility for the data nor the authority’s final processing result.
Short answers on handling errors
How should RA/QA interpret technical feedback?
Start with the affected object and field. For technical messages, request a clear link to the source information and violated rule. You can then distinguish whether a specialist decision, data correction or technical adjustment is needed.
Is every issue in this library an official EUDAMED error?
No. The library separates field and process conditions from the EUDAMED documentation from internal data quality and evidence issues. The headings are editorial descriptions, not invented original messages or official error codes.
Must I resend everything after a partially successful XML upload?
No. Use the response to identify which objects were processed successfully and which contain errors. The official bulk-upload help provides for resubmitting failed objects only. Do not resend successful objects as new registrations without checking. Source: Bulk upload: processing and feedback.
How do I prevent the same error from recurring?
Correct the cause at the data source or in the mapping and add an appropriate check before the next run. Assess effectiveness using comparable submission results. A blanket guarantee that an error will never recur would not be supportable.
General registration questions: EUDAMED FAQ · Introduction: EUDAMED and UDI for manufacturers · Further topics: UDI guide.
