EU FMD compliance after go‑live: What good should look like in 2026

Executive summary

You went live on EU FMD . The serialization data is flowing. Now what?

“Good” looks like low alert volumes, fast resolution times, clean repository data and evidence your team can produce the moment someone asks for it. That’s the bar today, and most organizations still have gaps between go-live and getting there.

This guide picks up where go-live left off. It covers the Day 2 operating model: who owns what, how exceptions should move through your organization, which KPIs to track and how to stay audit-ready without bolting on extra work. We wrote it for compliance leaders, packaging operations and serialization program owners, supply chain and traceability leads and IT teams managing partner data exchange.

You’ll walk away with a working operating model, a KPI framework, resolution playbooks, a self-assessment checklist, an FAQ section and a glossary of key terms.

Key takeaways

• Separate scanner and configuration noise from genuine data failures so your team consistently responds to the right alerts.
• Assign clear ownership for every alert type across Ops, QA, IT and Supply Chain.
• Run repository hygiene as a daily operational control, not something you catch up on before an audit.
• Track exception rate, time-to-resolve, reopen rate and root-cause mix.
• Bake audit readiness into everyday work through current logs, SOPs, training records and documented evidence.
• Treat status changes, reversals and returns as controlled activities with full traceability.
• Align your verification and decommissioning workflows now so DSCSA and EU FMD compliance programs reinforce each other.
• Staff your exception-handling process for volume, not just coverage.

What “good” EU FMD compliance should look like

Good EU FMD compliance comes down to three things: stable operations, low disruption and controls you can prove on demand. Going live was the milestone. Running clean afterward is the actual job, and it’s where most organizations still have room to tighten up.

Four measurable outcomes that define “good”

You can measure where you stand against four benchmarks:

1. Low exception rate: Mature sites generate fewer alerts per batch because they fix root causes, not just individual tickets.
2. Fast, consistent triage and closure: Exceptions follow a repeatable path from detection to documented resolution, every time.
3. Clean data: Few verification rejects, few duplicates and master data that matches what’s physically on the line.
4. Audit-ready evidence from normal workflows: Your team can pull logs, SOPs and closure records on demand without scrambling to reconstruct what happened three months ago.

A quick refresher in simple terms

EU FMD requires two safety features on most prescription packs: a unique identifier (a 2D barcode with serialized data) and an anti-tampering device. Pharmacies and hospitals verify these features at the point of dispense and decommission the serial number so it can’t be reused.

The whole system also runs on a repository architecture. Product data flows from manufacturers up through the EU Hub and down into national verification systems. Every scan, status change and decommission gets recorded there.

This guide provides operational guidance and is not legal advice. Requirements can vary by country and by your role in the supply chain. Confirm obligations with your legal and regulatory team and with your local NMVO or NCA guidance.

EU FMD operating model (Day 2 compliance)

Hitting all four of those benchmarks doesn’t happen by accident. Day 2 EU FMD compliance depends on clear governance, documented procedures and a monitoring cadence that catches problems early, all working together. Most organizations have pieces of this in place, but few have connected them into a single operating model. Here’s how to close that gap.

Governance and ownership (RACI)

Every recurring activity needs a named owner and a clear escalation path. Build a RACI matrix that maps your six core EU FMD compliance activities against the teams responsible for them. Below is a starting point:

R = Responsible, A = Accountable, C = Consulted, I = Informed

Adapt this to your org structure, but don’t skip the exercise. When an alert fires at 6 a.m., everyone should already know who picks it up, who gets consulted and who approves the resolution.

SOP stack you need documented

Your governance model also needs documented procedures behind it. At a minimum, maintain SOPs or controlled work instructions for:

• Verification and decommissioning workflows at each of your role’s touchpoints.
• Alert investigation decision trees that give triage staff a repeatable path, even a minimum viable one.
• Returns and rework handling with country and site variants clearly flagged.
• Data corrections and reprocessing rules that define who can change what and what approvals are required.
• Access control, credentialing and segregation of duties across your serialization systems.

These documents don’t need to be long. They need to be current, accessible and specific enough that someone covering a shift can follow them without guessing.

A training model that sticks

Good SOPs serve no purpose if the people running your exception queue haven’t read them. Build a role-based training matrix tied to your SOP stack so every person knows which procedures apply to their work. Pair that with a trigger list that spells out which changes require retraining and who needs to go through it.

Keep proof of completion for every training event and schedule periodic refreshes too. Auditors will ask for both. The more common problem, though, is practical: someone trained at go-live two years ago rotates into a new role, and nobody retrains them on the current decision tree.

That’s how you end up with a fully documented process that nobody follows.

Monitoring cadence: daily, weekly, monthly

Set a rhythm that matches how problems develop:

• Daily: Check queue health, top alert types, aged alerts and scanner status. Catch issues before they compound.
• Weekly: Review root-cause trends, flag repeat offenders and confirm process fixes from the prior week landed.
• Monthly: Publish a KPI pack, run audit trail spot checks and evaluate SOP effectiveness against your exception data.

The daily check keeps the queue moving. The weekly review finds patterns. The monthly review tells you whether your operating model is working or just busy.

Repository hygiene and data quality

Your operating model only works if the data underneath it stays clean. Repository hygiene means your serial data and master data stay consistent, complete and usable across the repositories system.

What repository hygiene means in simple terms

Repository hygiene is the discipline of keeping the data you upload and the transactions you perform accurate, timely and reconcilable. Every serial number your line generates, pack hierarchy you upload and decommission event your supply chain triggers lands in the repositories system.

If any of that data arrives late, wrong or duplicated, it creates alerts that someone must investigate.

Where data problems usually come from

Most data quality issues trace back to a handful of recurring sources:

• Master data mismatches: Product codes, GTIN configurations or pack hierarchy assumptions that don’t align between your internal systems and the repository.
• Upload timing gaps: Late uploads or partial batches that leave serial numbers unrecognized at the point of dispense.
• Duplicate or overlapping serials: Vendor errors or process gaps that generate the same serial number twice.
• Line and site configuration drift: Scanner settings, routing rules or location IDs that fall out of sync after maintenance or changeovers.
• Repack and parallel distribution linkages: Aggregation or repackaging relationships that break when packs move through multiple markets or contract partners.

Controls that prevent dirty data

Prevention always beats investigation. So, build these controls into your standard workflows:

• Prerelease validation gates: Verify serial data completeness and master data alignment before you release product to distribution.
• Interface monitoring and retry rules: Track upload success rates in near real time and automate retries for transient failures so data gaps don’t accumulate.
• Duplicate detection controls: Flag overlapping serial ranges at the point of generation, not after packs reach the field.
• Clear “stop the line” criteria: Define which data failures require a line stop and which ones your team can correct downstream. Document the decision logic so operators don’t have to make judgment calls under pressure.

KPIs worth tracking

Be sure to also pair your controls with metrics that show whether they’re working. These are six KPIs to focus on that will give you a clear picture of EU FMD compliance health:

For directional benchmarking, EMVO best practice references an aspirational steady-state alert rate around 0.05% of total scans or lower, though national differences apply. Use that as a reference point, not an absolute standard.

Exception handling in practice

Alerts will fire. Packs will fail verification. Someone on the second shift will do something creative with a return. None of that is the problem. The problem is when nobody knows who picks it up, how to investigate it or where to document the fix. Most EU FMD compliance pain comes from the same handful of exception types showing up repeatedly without a defined response behind them.

The five-step exception workflow

Every exception, regardless of type, should follow the same basic path:

1. Identify and classify: Determine whether the alert is technical (scanner, interface, configuration), data-related (master data mismatch, duplicate serial) or procedural (wrong transaction type, user error).
2. Quarantine decision: Decide whether affected product needs to be held and escalate according to your RACI matrix. Not every alert requires quarantine, but your SOP should spell out which ones do.
3. Investigate: Identify the root cause and determine the full scope of impact. One alert often points to a broader batch or configuration issue.
4. Resolve: Fix the immediate transaction and fix the underlying process. A resolution that only addresses the single alert without correcting the source will generate the same alert tomorrow.
5. Capture evidence and close: Document what happened, what you did and who approved it. Close the record with enough detail that an auditor can reconstruct the story without calling anyone.

Returns

The hard part with returns is that the pack’s status has usually already changed. The serial may be decommissioned. The transaction history may be incomplete. Two tracks help here:

Saleable returns need a status evaluation and potentially a controlled restoration. Non-saleable returns follow your standard destruction path. Both tracks require the same evidence: who authorized the decision, what status changes were made and when.

Why the extra rigor? Decommissioning happens at the end of the supply chain. Returned packs carry higher risk because their history may be ambiguous. Stronger controls here protect you, not slow you down.

Rework

Rework exceptions come from packaging defects, relabeling or aggregation errors on product that’s already serialized. The regulation allows reverting a decommissioned status under strict conditions to prevent waste. Your job is to turn that flexibility into a controlled, repeatable workflow instead of an ad hoc fix.

What makes rework defensible is the following:

• QA approval at defined checkpoints.
• Segregation of duties between the person doing the work and the person approving it.
• A complete trail tying batch records, line records and approvals back to the specific serial numbers affected.

If an auditor pulls a reworked pack six months from now, the trail should be complete without anyone having to explain it from memory.

Decommissioning and status management

Decommissioning prevents a unique identifier from being reused. The specifics vary by market, so keep your local NMVO guidance close. Three principles hold everywhere:

1. Audit trails must reflect reality. Record who performed each status change and when.
2. Controlled reversals require documented justification and approval. No exceptions.
3. When technical issues delay decommissioning, complete it as soon as the issue clears and document the gap.

Verify your workflows against your national system’s requirements. The principles are consistent across EU FMD, but implementation details differ.

Root-cause categories

Over time, your exception data should cluster into a predictable set of root causes. Track these eight categories and build a short response procedure for each:

1. Scanner or configuration issue: Hardware failure, firmware mismatch or incorrect setup after maintenance.
2. Wrong location or user setup: Operator credentials, site IDs or location codes that don’t match the repository configuration.
3. Duplicate serial: Overlapping serial ranges from vendor errors or process gaps.
4. Late upload or missing serial: Data that didn’t reach the repository before the pack was scanned downstream.
5. Master data mismatch : Product code, GTIN or pack hierarchy discrepancies between internal systems and the repository.
6. Procedural misuse: Operator selected the wrong transaction type for the scenario.
7. Repack or linkage issue: Aggregation relationships that failed during repackaging or multi-market distribution.
8. Training gap: The operator followed an outdated procedure or hadn’t been trained on the current one.

Tracking root-cause mix over time is one of the most useful things your monthly KPI review can do. A declining “unknown root cause” rate means your team is learning. A rising share of any single category tells you where to focus your next CAPA.

Exception resolution reference table

Use the table below as a starting framework. Expand it to cover your site’s most common exception patterns and adapt the owners to match your RACI assignments.

Audit readiness and what auditors typically want

An audit is a story problem. The auditor asks: “Show me this control works.” You either hand them the evidence or you spend a weekend reconstructing it.

Everything in this guide, the governance model, the SOPs, the exception workflows, the KPIs, produces that evidence as a byproduct. Audit readiness is whether you can find it right away and whether it holds together when someone pulls the thread.

This section provides operational guidance and is not legal advice. Confirm specific audit expectations with your NCA, NMVO and quality system requirements.

Evidence categories you should have ready

Auditors generally want to see proof across six areas. If you can pull each of these within a business day, you’re in good shape:

1. SOPs with effective dates and change control: Current versions, revision history and evidence that changes went through your approval process.
2. Training records with role mapping: Who was trained on what, when they completed it and how training ties back to your SOP stack and RACI matrix.
3. System access controls: Least-privilege access, unique user IDs and a joiner/mover/leaver process that removes credentials when people change roles or leave. Shared logins are a red flag.
4. Alert investigation records: The full lifecycle: triage, root-cause analysis, resolution, closure and approval signatures.
5. Data integrity evidence: Interface monitoring logs, reconciliation reports and any automated checks that confirm data moved correctly between systems.
6. Audit trail extracts: Who did what, when. These should come straight from your systems, not from someone reconstructing events after the fact.
7. Record retention policy: Document how long you keep records of operations around unique identifiers and map that policy to your regulatory expectations.

Prove the control works: three concrete examples

Documentation alone won’t satisfy most auditors. They want to watch the controls work on real examples. Have three demonstrations ready to go before anyone asks.

Walk through three closed alerts end-to-end

Pick one technical, one data-related and one procedural. Show timestamps at every stage and approvals at closure. Pick boring ones too. The cleanest examples show a mature process better than your most dramatic investigation.

Show a controlled rework case

Batch record connects to line record connects to affected serial numbers connects to QA disposition. The auditor should be able to follow the thread without asking a single clarifying question. If they have to, something in your documentation chain broke down.

Demonstrate that user IDs are unique and current

Show your joiner/mover/leaver process. Show that credentials get removed when someone changes roles. An auditor who finds a shared login will pull that thread until something unravels, because “who performed this action” is the foundation of every other piece of evidence you’ve presented.

EU FMD audit readiness checklist

The previous section covers what auditors want to see and how to show it. The checklist below turns that into a self-assessment you can run quarterly. Don’t cheat yourself; score yourself honestly. Anything unchecked in the baseline block is a gap worth closing before someone else finds it.

Baseline must-haves

• Ownership matrix (RACI) exists, covers all six core activities and reflects current org structure.
• SOPs exist for alert handling, returns and rework with effective dates and change control.
• Verification and decommissioning workflows are documented at each touchpoint.
• Data correction and reprocessing rules define who can change what and what approvals are required.
• Role-based training is complete for all users who touch serialization systems.
• Training trigger list defines which changes require retraining and for whom.
• Alert queue has defined SLAs for triage and closure.
• Escalation rules are documented and mapped to the RACI matrix.
• Evidence pack template exists for investigations (timestamps, root cause, resolution, approvals).
• Access reviews happen on a defined cadence with documented outcomes.
• User IDs are unique and the joiner/mover/leaver process is active.
• Interface monitoring runs daily and results are documented.
• Duplicate detection controls are in place at the point of serial generation.
• Prerelease validation gates confirm data completeness before product ships.
• Record retention policy exists and maps to regulatory expectations for unique identifier data.
• At least three end-to-end alert walkthroughs are ready to present on request.

Best-in-class differentiators

• Monthly trend reporting by root-cause category with CAPA linkage.
• Leading indicators track scanner and configuration drift before they generate alerts.
• Aged alert automation flags overdue items and sends proactive notifications.
• Quarterly mock-audit exercises test evidence retrieval speed and completeness.
• Site scorecard tracks KPI targets: exception rate, time-to-resolve and reopen rate.
• Root-cause mix analysis feeds back into SOP and training updates.
• Cross-site benchmarking compares performance across locations and markets.
• Exception data informs packaging line and process improvement priorities.

FAQs

What does EU FMD require on pack, in simple terms?

Two things: a unique identifier (a 2D barcode containing serialized data) and an anti-tampering device on most prescription packs. Pharmacies and hospitals scan the barcode at dispense to verify the pack is legitimate and decommission the serial number so it can’t be reused. The European Medicines Agency (EMA) publishes detailed requirements on safety features .

What is the EU Hub vs. a national system?

The EU Hub is the central routing layer that connects manufacturers to national verification systems across Europe. When you upload serial data, it flows through the EU Hub and down to the relevant national system (managed by each country’s NMVO). Verification and decommissioning events happen at the national level, not at the Hub.

What is decommissioning, and why does it matter?

Decommissioning is the action that marks a unique identifier as “used” so it can’t be verified again. It’s the core mechanism that prevents falsified packs from re-entering the supply chain. Without timely, accurate decommissioning, the entire verification system loses its value.

Can we undo a decommissioned status for rework?

The regulation recognizes that reverting a decommissioned status can be possible under strict conditions to avoid unnecessary waste. Your organization needs to treat this as a controlled workflow with QA approval, segregation of duties and a complete audit trail. Verify the specific conditions and process with your local NMVO, because requirements vary by market.

What is repository hygiene?

Repository hygiene is the discipline of keeping your serial data and master data accurate, timely and reconcilable across the repositories system. Clean data means fewer alerts, faster resolution and audit evidence that holds together. Treat it as a daily operational control, not something you clean up before an inspection.

What KPIs should we track after go-live?

Focus on six: exception rate (alerts per scans), median time to triage, median and 90th-percentile time to close, reopen rate, upload/transaction reject rate and unknown root-cause rate. Together, these tell you whether your data is clean, your team is responsive and your fixes are holding.

What causes most alerts: technical, data or procedural?

Most mature sites see the majority of alerts come from technical and configuration issues (scanner problems, interface failures, location ID mismatches). Data issues like late uploads and master data mismatches are the second most common. Procedural errors tend to drop over time as training matures, but they spike after staff turnover or process changes.

What evidence do we need for audits?

Auditors generally want SOPs with change control, training records tied to roles, alert investigation records showing the full lifecycle, access control documentation, interface monitoring logs and audit trail extracts showing who did what and when. The real test is whether you can pull all of it within a business day and whether it tells a consistent story.

How do responsibilities differ for MAHs/OBPs vs. end users?

Marketing Authorization Holders (MAHs) and On-Board Partners (OBPs) own the data: they upload serial numbers, maintain master data and manage the relationship with the EU Hub and national systems. End users (pharmacies, hospitals) verify and decommission at the point of dispense. Both sides generate exceptions, but the root causes and resolution paths look different.

How does EU FMD differ from DSCSA at a high level?

Both regulations require serialization, but they work differently. EU FMD uses a point-of-dispense verification model where pharmacies check each pack against a central repository. DSCSA focuses on transaction-level traceability across the U.S. supply chain. Organizations operating in both markets should align their workflows where possible to avoid duplicating effort.

What about Northern Ireland and other market-specific nuances?

Northern Ireland follows EU FMD requirements under the Windsor Framework, which means packs moving into Northern Ireland need EU-compliant safety features. Other markets have their own nuances around timelines, national system configurations and specific NMVO expectations. GOV.UK publishes current guidance for Northern Ireland. For other markets, check directly with your local NMVO.

How do we prevent repeat alerts from the same root cause?

Track root-cause categories monthly and look for patterns. When the same category keeps showing up (late uploads, scanner misconfiguration, master data mismatches), open a CAPA that targets the process, not just the individual alert. A declining repeat rate is one of the strongest signals that your operating model is maturing.

Glossary

• Unique identifier (UI): The 2D barcode on a prescription pack that contains four data elements: product code, serial number, batch number and expiry date. Every pack gets a unique combination.
• Anti-tampering device: A physical feature on the pack (such as a seal or break-tab) that shows whether someone has opened it. Required alongside the unique identifier under EU FMD.
• Verification: The act of scanning a pack’s unique identifier against the repositories system to confirm it’s legitimate. Happens at the point of dispense.
• Decommissioning: The action that marks a unique identifier as “used” so it can’t be verified again. Prevents the same serial number from being accepted twice.
• Alert: A notification generated when a verification or transaction doesn’t match expected data in the repository. Could be technical, data-related or procedural in origin.
• Exception: A broader term for any event that falls outside normal processing and requires investigation. Alerts are one type. Returns and rework scenarios are others.
• Investigation: The structured process of identifying the root cause, scope and resolution for an exception. Should follow a documented workflow with evidence captured at each step.
• CAPA (corrective and preventive action): A formal process for fixing the root cause of a problem (corrective) and preventing it from recurring (preventive). Tied to your quality management system.
• Repository hygiene: The discipline of keeping serial data and master data accurate, timely and reconcilable across the repositories system. Treated as a daily operational control.

How we help

You’ve read the operating model, the KPIs, the exception workflows and the audit checklist. Putting all of that into practice across multiple sites and markets is where the work gets real.

Systech helps teams run Day 2 EU FMD compliance with less noise and more control. We built our platform around the problems covered in this guide: data integrity across the repositories system, exception workflows that route to the right owner and audit evidence that’s ready when someone asks for it.

Global teams get particular value here. We help you align EU FMD and DSCSA operations into one coherent compliance program instead of maintaining two parallel tracks that duplicate effort and drift apart over time.

Start here:

• Explore our EU FMD guide
• Read our DSCSA compliance guide

Of course, feel free to contact us directly if you have any questions.