Common FSMA 204 Implementation Problems and How to Address Them

Common failure: a code exists but does not connect records

A frequent implementation error is to focus on whether a lot code is printed rather than whether the code is assigned, captured, communicated and linked to the required records. Another is to treat a software capability as proof of compliance without testing user behaviour, exports and exception handling. A third is to classify a food or exemption once and never revisit the decision after a formulation or process change.

Common failure: a procedure describes an ideal workflow

Use a failure analysis that distinguishes the immediate defect from its cause. A missing KDE might result from an unclear supplier agreement, a poorly configured field, an employee who cannot identify the correct document, or a report that excludes data stored in a linked system. Fixing the visible blank without correcting the process can allow the same defect to recur on the next shipment.

Corrective action should prevent recurrence

For a split shipment, test whether each child transaction preserves the relevant lot relationship and whether the source and destination records can be reconciled. For transformation, test whether inputs and outputs can be reconstructed. For supplier data, test the actual file received—not just the form your purchasing team sends. For a return or correction, verify that the history remains understandable.

A corrective-action record should identify the affected process and records, risk assessment, root cause, immediate containment, permanent correction, responsible owner, due date and effectiveness test. Close the action only after a representative retest passes. Keep the original discrepancy and correction evidence; do not make an audit trail disappear by replacing the record without history.

A corrective-action example

Suppose a mock trace finds that a customer shipment contains the warehouse’s internal pallet ID but not a usable reference to the relevant traceability lot. The immediate correction may be to reconstruct the link from the source transaction, but the root cause could be a mapping rule that drops the TLC during order consolidation. A durable corrective action changes the interface or procedure, tests future split shipments and checks whether other records were affected.

Document containment, scope of affected transactions, root cause, correction, owner, due date and effectiveness evidence. If the issue may affect the accuracy of other records, sample the population rather than assuming the single failed transaction is isolated.

Close the action only after the revised process passes a defined retest. “Staff reminded” is not enough where the root cause is a system design problem, unclear field definition or missing data exchange agreement.

Prioritise defects by traceability impact

Not all defects have the same consequence. A typographical error in a nonessential note may be less significant than a missing identifier that prevents a lot from being linked to the source or downstream shipment. Classify findings by their effect on identification, linkage, retrieval and regulatory interpretation, then set proportionate correction priorities.

When the same defect appears across many records, investigate the common cause before correcting records one by one. A bad data dictionary, interface mapping or unclear ownership can reproduce the defect indefinitely. Record the affected population and determine whether historical records also need correction or annotation.

Close a finding only after the fix has been tested on a new representative transaction and the evidence is retained.