Rejected Inventory Bucket

A rejected inventory bucket is a controlled status and virtual location in an MES/WMS that sequesters material or product once it is determined to be nonconforming. It enforces a system-level block on availability for consumption, movement to production, or release to commerce, and it ensures traceable routing to an approved QA disposition. In ISA‑95 terms, the rejected state is a material attribute at Level 3 that must also be respected by Level 4 (ERP) and Level 2 (automation) through interlocks and interfaces.

Unlike quarantine or hold, which indicate pending evaluation, a rejected bucket reflects a completed material review that the item does not meet requirements for intended use. Any subsequent use requires a documented, approved plan (e.g., rework/reprocess under change control) with complete electronic records, audit trails, and eSignatures consistent with 21 CFR Part 11 and EU Annex 11 expectations for computerized systems.

• Scope: components, intermediates, bulk, finished goods, labels/packaging, and serialized units
• Triggers: failed in-process checks, OOS/OOT lab results, damage, mix-up risk, data-integrity concerns, supplier nonconformance
• Outcomes: scrap/destroy, rework/reprocess, downgrade/alternate use, return-to-vendor (RTV)

Pharmaceutical manufacturers must ensure rejected components and products are identified and controlled to prevent use (21 CFR 211.89). Medical device firms must have documented procedures for control of nonconforming product, including segregation, review, and disposition (21 CFR 820.90). Both regimes expect clear records tying the nonconformance, evaluation, disposition decision, and any rework to batch/lot history, with review by the quality unit.

Computerized systems used to implement rejected buckets must meet 21 CFR Part 11 and EU GMP Annex 11 data integrity principles (audit trails, eSignatures, security, and validated workflows). EU GMP Volume 4 similarly requires segregation and status control of materials across the lifecycle, while maintaining data integrity over status changes and approvals. These expectations apply to intermediates and in-process materials, not only finished goods.

ISA‑95 provides a common language for material definition (class, lot, property) and status management at Level 3, and integration handshakes to Level 4. A rejected bucket is a defined status value and virtual location that must be mapped to ERP item/lot status codes and WMS bin/location types. Transitions into and out of the rejected state require controlled events, reason codes, and approvals to maintain material traceability and to align with quality processes (NCR/CAPA).

The rejected bucket is a sink state for fitness-for-use; any transition out requires a formally approved disposition. Interfaces should propagate state changes to ERP and WMS within seconds, and equipment control (Level 2) should be interlocked (e.g., MES disallows weigh/dispense of rejected lots).

Regulations require identification and segregation of rejected materials to prevent mix-ups and unintended use. Physical segregation (dedicated cages, bins with red visual management, locked areas) must be mirrored by system segregation: a rejected bucket that prevents pick, dispense, backflush, or ship transactions. In devices (21 CFR 820.90), procedures must ensure identification, documentation, evaluation, segregation, and disposition; in pharma (21 CFR 211.89), rejected components must be controlled to prevent their use in manufacturing.

• WMS bin type: Reject-Only; putaway restricted by rule
• MES lot status: Rejected; consumption transaction blocked
• ERP lot/item status: Rejected; MRP excludes availability
• Labeling: Distinct color/wording; scan validation to enforce status

Barcoded or serialized control should enforce status at scan time: any attempt to move or consume a rejected lot/unit should fail with an audit-trailed exception. Where automated material handling exists, the warehouse control system must also honor the rejected location type and route materials away from production lines.

Because a rejected bucket directly affects release and use decisions, all state changes must be attributable, time-stamped, and protected by audit trails and appropriate eSignatures (21 CFR Part 11; EU Annex 11; MHRA data integrity guidance). The system must enforce access control so only authorized roles (e.g., QA) can set or clear the rejected status, and the rationale (reason code, link to NCR/deviation/OOS) must be recorded contemporaneously.

• Role-based authorization to set/clear rejected status
• Mandatory reason codes tied to controlled vocabularies
• Linkage to investigation records (NCR/OOS/CAPA) and batch/lot genealogy
• Immutable audit trail entries with before/after status, user, timestamp
• Two-person e-signature for high-risk reversals where justified by SOP

Validation should demonstrate that status changes are correctly recorded, enforced, and reported, including negative testing (attempted bypass), time sync accuracy, and interface data integrity. Annex 11 and Part 11 require documented procedures for system operation, security, backup/restore, and periodic review of audit trails associated with critical decisions.

A rejected bucket is only effective if all connected systems agree on status and availability. ISA‑95 recommends clear master data and event exchanges so Level 3 (MES) is the system of record for material execution status, synchronized to ERP (planning/finance), WMS (physical movement), and LIMS (test results). QMS must be the system of record for investigations and CAPA, with keys exchanged bidirectionally.

Event-driven integration should minimize latency and race conditions (e.g., LIMS posts OOS; MES immediately sets rejected; WMS denies movement). Where GS1 identification is used (lots, serials, SSCC), ensure barcodes and master data align so status is consistently enforced at scan points across systems.

Once in the rejected bucket, materials follow a documented disposition pathway governed by QA and, where required, an MRB. For pharmaceuticals, reprocessing or rework requires a written procedure and QC unit approval (see 21 CFR Part 211 framework, including expectations for reprocessing control and documentation). For devices, 21 CFR 820.90 requires evaluation, disposition, and, if rework is performed, subsequent verification and, where appropriate, validation to ensure product conforms to current approved specifications.

• Scrap/Destroy: Irreversible physical destruction or chemical denaturing; documented and reconciled.
• Return-to-Vendor (RTV): Controlled return with supplier notification and containment; update supplier scorecard.
• Rework/Reprocess: Approved plan with defined acceptance criteria; additional sampling/testing; full documentation.
• Downgrade/Alternate Use: Only if specifications for alternate use exist and regulatory impact is assessed.
• Release under Deviation: Exceptional; risk-assessed, justified, and approved; typically not allowed for critical defects.

1. Confirm nonconformance with verified data (e.g., OOS verified per SOP).
2. Open NCR/deviation and route to MRB/QA.
3. Move lot/unit to rejected bucket with reason code and links to records.
4. Approve disposition; document plan and controls.
5. Execute disposition with system interlocks; capture evidence.
6. Close records; update genealogy/availability; trend metrics.

Rejected inventory is a signal of process capability, supplier quality, and operational control. Governance should include KPI definitions, thresholds, and trending to support continual improvement and management review. Aged rejected inventory represents risk and cost exposure; cycle time to disposition should be actively managed.

• Reject Rate by stage (receiving, in‑process, final) and by material/supplier
• Mean/median days in rejected bucket (aging) and 95th percentile
• Disposition mix (scrap vs. rework vs. RTV) and first-pass success of rework
• Escaped defect rate (post‑release discoveries) – should trend to zero
• Top reason codes by frequency/severity; CAPA linkages and effectiveness
• Inventory value on hand in rejected status and write‑off impact

Audit trail review should include periodic sampling of status change records for correctness of authorization, reason coding, contemporaneous entry, and linkage to source investigations, consistent with Part 11/Annex 11 expectations for periodic review of critical audit trails.

The rejected bucket function is high‑risk from a patient/customer and compliance perspective because it prevents release and controls re‑entry. Apply a risk‑based, computerized system lifecycle (GAMP 5) to specify, build/configure, verify, and maintain the function. Requirements should explicitly cover state model, role permissions, reason codes, interlocks, interface behavior, exception handling, and reporting. Test negative paths (e.g., attempt to pick a rejected lot; attempt to clear status without required eSignature).

• Requirements traceability to tests for each state transition and interlock
• Interface testing with simulated race conditions and failure recovery
• Audit trail verification: completeness, accuracy, time sync, tamper evidence
• Security model: RBAC, least privilege, periodic access review
• Procedural controls: SOPs for rejection, rework, and reversal approvals
• Periodic review: metrics, audit trail, configuration drift

Maintain validated control over master data that drives the bucket (e.g., reason code dictionaries, status enumerations, and routing rules). Changes require impact assessment and documented approval per change control, with regression testing of critical interlocks.

• Split-brain status: MES shows rejected; ERP/WMS shows available due to integration lag or mapping errors.
• Improper reversals: Clearing rejected without QA approval/eSignature or without linking to disposition rationale.
• Bypass routes: Users moving stock physically from reject to production bins using uncontrolled transactions.
• Poor reason coding: Free-text reasons that hinder trending and CAPA analysis.
• Inadequate audit trails: Missing before/after values, user identity, or timestamps.
• No genealogy impact analysis: Downstream lots not flagged when a consumed lot is later rejected.
• Aged rejects: Inventory lingering for months without timely MRB disposition.

To be effective, the rejected bucket must behave as a single source of truth enforced across execution, lab, warehouse, and planning. The operational design centers on fast, reliable status propagation, unambiguous master data, and embedded quality workflows so that once a nonconformance is confirmed, availability is blocked and only an approved disposition can change it.

• One record links nonconformance, OOS, and disposition to the affected lots/serials.
• Reason-code dictionaries are centrally governed and reportable across plants.
• Interlocks prevent weigh/dispense, pick, or ship on rejected lots/units.
• Interfaces update ERP availability and WMS bin rules in near real time.
• Disposition execution (scrap/RTV/rework) is guided and fully e-signed.