Choose EUDAMED manual entry, bulk XML, or M2M by operating reality
Use manual entry for small, stable workloads; bulk XML for structured, reviewable batches; and M2M when high or frequent exchange justifies automatic transport and durable operations. Device count is a useful prompt, not the decision by itself. Source quality, approvals, exceptions, infrastructure, support, and reconciliation determine whether automation is proportionate.
Choose the least complex EUDAMED route you can operate reliably
Yarify can assess your actual record volume, change frequency, source quality, approval process, infrastructure, and support capacity—then turn the selected route into a bounded implementation plan.
What the engagement produces
- A transparent UI-versus-bulk-versus-M2M workload comparison
- A documented recommendation with assumptions, risks, and prerequisites
- A practical first implementation scope tied to your current systems
Start with the least complex method that meets the measured need
The Commission describes UI input as manual, XML upload/download as semi-automated because file generation can be automated while transfer remains manual, and M2M as automatic external-backend exchange. See the official method definitions.
Manual is not inherently immature, and M2M is not inherently optimal. The best method is the one the organisation can operate reliably while meeting its volume, frequency, traceability, correction, and timeliness needs.
If source facts are incomplete or relationships are unclear, pause the transport choice. All three methods need approved data; bulk and M2M merely increase how consistently and quickly it can be moved.
Minimise setup
Accept higher per-record human work when the portfolio and change load remain small.
Automate preparation
Generate consistent batches while retaining a human upload and review boundary.
Automate exchange
Invest in onboarding and operations when manual transport is a sustained constraint.
Manual UI vs bulk XML vs M2M: complete comparison
Read every row. A method that wins on recurring effort may lose on setup, support, source readiness, or failure-handling capacity.
| Decision factor | Manual UI | Bulk XML upload | M2M data exchange |
|---|---|---|---|
| How data enters EUDAMED | A user enters and confirms records in the EUDAMED interface. | Software prepares XML; an authorised user uploads the file through the interface. | An external backend exchanges XML automatically with EUDAMED backend services. |
| Official indicative volume tip | Up to 100 devices | 100–1,000 devices | More than 1,000 devices |
| Legal threshold? | No. The count is guidance, not a mandatory cut-off. | No. Frequency and source structure can justify it below or above the band. | No. High volume alone does not prove operational readiness. |
| Initial technical setup | Lowest: access, trained users, governed preparation, and review controls. | Medium: source mapping, XML generation, current XSD/rule validation, and upload operations. | Highest: data backend, DTX services, Access Point/AS4, security, onboarding, monitoring, and support. |
| Recurring human work | Highest per record: entry, checking, correction, and status tracking. | Review and authenticated file upload remain manual; preparation and error handling can be automated. | People govern approvals and exceptions instead of each transmission, but operations still require ownership. |
| Source-data requirement | Approved facts must be available, but a formal integration model may be unnecessary for a small portfolio. | Structured, repeatable source data and stable record relationships are needed for reliable generation. | A capable backend, canonical desired state, change detection, and reconciliation are foundational. |
| Change frequency | Best when records are few and changes are infrequent. | Good for periodic, reviewable batches. | Strongest case when updates are frequent enough to justify automatic transport and operations. |
| Failure handling | User resolves interface feedback record by record and must preserve evidence separately. | Team correlates batch and record outcomes to source keys and builds controlled correction files. | Connector correlates messages, acknowledgements, reports, entity outcomes, retries, and accepted state. |
| Primary dependency | Available trained users and consistent process discipline. | Current technical artefacts, a deterministic generator, validator, permitted uploader, and response workflow. | All bulk-data foundations plus Actor/LAA, eDelivery AP, Party ID, module keys, Playground/Production, and support. |
| Typical advantage | Fastest way to begin when automation effort would exceed recurring work. | Reduces repetitive entry without the complete M2M infrastructure commitment. | Removes manual file transmission and supports frequent backend-to-backend exchange. |
| Typical disadvantage | Effort, consistency risk, and status tracking grow with volume and change. | The operator boundary and batch-response lifecycle remain. | Architecture, onboarding, security, testing, release management, and 24/7-style failure ownership may be disproportionate. |
| Best-fit operating model | Small, stable portfolio with clear facts and modest recurring workload. | Structured periodic batches with review gates and an accountable upload operator. | High-volume or high-frequency service with mature product data and durable integration operations. |
The volume bands come from the official modes-of-input tip. The table labels them indicative because the Commission presents them as guidance, not statutory cut-offs.
A decision tree that starts with data readiness
Move down the tree only when the preceding condition is true. A large portfolio with weak identity and ownership needs data work before more transport automation.
- Question 1
Is the approved source dataset complete and consistently owned?
YES · Continue to volume and frequency.
NO · Fix ownership, mapping, relationships, and validation first. Transport choice will not repair the data.
- Question 2
Is the portfolio small, stable, and updated infrequently?
YES · Use the UI unless measured recurring work or risk justifies a controlled generator.
NO · Evaluate structured bulk preparation.
- Question 3
Can records be assembled into reproducible, reviewable batches?
YES · Bulk XML is a practical baseline; measure upload and exception workload.
NO · Build a canonical dataset and change-control process before automating transport.
- Question 4
Does manual file transmission materially constrain frequency, latency, or operations?
YES · Assess M2M business value and readiness.
NO · Bulk XML may remain more proportionate than M2M.
- Question 5
Can the organisation operate AP connectivity, security, message state, retries, releases, and reconciliation?
YES · Pilot one bounded M2M service in Playground and prove failure handling before Production.
NO · Keep bulk XML or address the missing operational capability first.
Model workload with your measurements, not invented averages
A transparent model can compare 100, 500, and 1,000+ devices without claiming a universal time per registration. Record every input and test a plausible range.
Initial records
Separates one-time portfolio preparation from the recurring operating model.
Measure · Devices, Basic UDI-DI groups, package records, references, and expected operations—not only spreadsheet rows.
Recurring change rate
A large stable portfolio can create less work than a smaller fast-changing portfolio.
Measure · Creates, updates, corrections, withdrawals, and dependent-record changes per period.
Touch time
Manual entry, review, upload, result triage, and correction consume different effort by method.
Measure · Use timed samples from your process; do not substitute unsupported industry averages.
Exception rate
Poor source quality can erase transport savings and create expensive rework.
Measure · Profile missing facts, invalid controlled values, relationship failures, and rejected outcomes.
Implementation and run cost
M2M includes durable infrastructure, security, onboarding, monitoring, releases, and support.
Measure · Estimate one-time build plus annual platform, provider, people, incident, and change costs.
Risk and control value
Traceability, consistency, faster correction, and reduced re-entry can matter beyond labour savings.
Measure · Define measurable acceptance and operational outcomes rather than a generic automation benefit.
Simple comparison formula
annual operating effort = preparation + entry / upload / message operations + review + exception resolution + reconciliation + release/support overhead
Add one-time implementation and migration cost separately. Run low/base/high scenarios and identify which assumption changes the preferred method.
Five situations—and the proportionate starting point
These are decision examples, not mandatory prescriptions. Validate the assumed data quality, frequency, approvals, and support model.
| Situation | Decision signal | Proportionate start | Review trigger |
|---|---|---|---|
| 75 devices, approved data, a few changes each quarter | Low recurring volume and no complex source integration need | Manual UI with a preparation checklist and peer review | Material portfolio growth or measured repetitive work |
| 350 devices in governed Excel, two planned registration waves | Structured periodic batches and repeatable mappings | Excel normalization, validation, and bulk XML | Upload frequency or response handling becomes a sustained bottleneck |
| 900 devices across ERP/PIM, monthly approved changes | Internal integration is valuable; transport need is still moderate | Canonical ERP integration feeding controlled bulk XML | Manual transmission, latency, or batch operations limit the service |
| 4,000 devices, frequent updates, mature backend and operations | High volume/frequency and organisational capacity support automatic exchange | M2M assessment and bounded Playground pilot | Pilot proves services, failures, reconciliation, support, and total cost |
| 2,000 records with duplicate IDs and unclear regulatory ownership | High volume but low source readiness | Data discovery, cleansing, ownership, and migration controls | Canonical records pass approval and validation gates |
Evidence to collect before approving the method
A one-page decision record makes the assumptions reviewable and creates a trigger for changing methods later.
- 01
Portfolio counts by entity and intended operation, not only product SKU total
- 02
Initial-load volume separated from expected recurring changes
- 03
Measured entry, review, upload, response-triage, and correction time
- 04
Source-system map, data owners, stable keys, and relationship quality
- 05
Exception types and rate from a representative sample
- 06
Required frequency, processing window, latency, and human coverage
- 07
Bulk generator/validator capability and authorised upload operating model
- 08
M2M AP, security, onboarding, support, release, retry, and reconciliation capability
- 09
One-time and recurring cost assumptions with sensitivity ranges
- 10
Decision owner, review date, and trigger for moving to another method
What Yarify can assess and implement
We can profile source data and workload, build a transparent option model, implement governed preparation for manual entry, generate and validate bulk XML, or build M2M data, messaging, monitoring, retry, and reconciliation layers.
Regulatory boundary
The manufacturer and qualified regulatory advisers decide applicability, classification, identifier assignment, and whether submitted facts are correct. Method selection and technical validation do not guarantee MDR or IVDR compliance.
Continue with the method or preparation problem you selected
This page owns the choice. The related guides own implementation detail.
Bulk XML upload
Implement the complete semi-automated generation, approval, upload, and response lifecycle.
Open guide →M2M integration
Plan DTX services, eDelivery/AS4, Access Point onboarding, security, and automated operations.
Open guide →Excel to XML
Transform governed spreadsheet records and one-to-many structures into validated XML.
Open guide →ERP integration
Build canonical desired state and source synchronization upstream of either transport method.
Open guide →XML validator
Separate syntax, XSD, enumeration, rule, reference, and processing-response failures.
Open guide →Data migration
Repair and convert a legacy portfolio before selecting its long-term operating model.
Open guide →Return to the EUDAMED automation hub for the complete cluster map.
Method-selection questions
What are the three EUDAMED data-input methods?
The Commission lists manual entry through the EUDAMED user interface, semi-automated XML bulk upload/download, and automatic M2M data exchange between an external backend and EUDAMED. Both XML routes still require governed source data and current technical contracts.
Is M2M mandatory above 1,000 devices?
No. The Commission presents up to 100 for UI, 100–1,000 for bulk, and more than 1,000 for M2M as tips, not legal cut-offs. Update frequency, source quality, required latency, internal readiness, exception handling, infrastructure, security, support, and total cost should shape the decision.
When is manual EUDAMED entry the right choice?
Manual entry can be proportionate for a small, stable portfolio with infrequent changes and readily available approved facts. It still benefits from a governed preparation checklist, peer review, source evidence, and status tracking. Automation should solve measured recurring work or control problems, not exist for its own sake.
What is the difference between bulk XML and M2M?
Bulk XML automates file preparation but keeps the authenticated upload/download action manual. M2M automates backend exchange and adds eDelivery-compatible Access Point infrastructure, Party ID, module keys, Playground and Production onboarding, message correlation, retries, monitoring, and reconciliation.
Should poor source data be fixed by choosing M2M?
No. Automatic transport sends data faster; it does not resolve ambiguous identifiers, missing regulatory facts, broken relationships, or unapproved controlled-value mappings. Establish a canonical dataset, accountable owners, validation, and approval before increasing transport automation.
Can Yarify recommend a regulatory submission method?
Yarify can assess the technical and operational fit of UI preparation, bulk XML, or M2M using your volume, frequency, systems, data quality, controls, and support capability. The manufacturer and qualified regulatory advisers remain responsible for regulatory interpretation, applicability, and approval of submitted facts.
Primary sources
Reviewed 9 September 2026. Method guidance, technical releases, M2M prerequisites, source-system capability, volumes, and operating costs can change. Re-run the decision when a material assumption changes.
EUDAMED Information Centre — Modes of data input
Official list of the UI, XML bulk upload/download, and M2M modes, plus indicative device-volume tips
EUDAMED Information Centre — Guidelines on Data Exchange
Official distinction between manual UI entry, semi-automated XML upload, and automatic M2M exchange, including cost and readiness considerations
EUDAMED Information Centre — M2M prerequisites
Official requirements for eDelivery-compatible infrastructure, Actor/LAA setup, Party ID, module security keys, and Playground onboarding
EUDAMED Information Centre — Current technical documentation
Official catalogue of data dictionaries, rules, enumerations, service definitions, XSDs, XML samples, and onboarding templates
European Commission — UDI/Device registration
Official UDI/Device module status, current device datasets, EMDN information, and registration guidance