V5 Ultimate
Manufacturing · The complete guide

Scrap Reason Coding

TL;DR

Scrap reason coding standardizes why material is rejected, tying quantities to batch, step, and equipment so yield and genealogy reconcile cleanly. ISA-95 places this at Level 3 (MES) with integration to Level 4 (ERP) for valuation and to QMS for NCR/CAPA. Under GMP/QSR and Part 11/Annex 11, codes must be governed, enforced, and audit-trailed. V5 Ultimate captures reasons in eBMR/eDHR context, drives automated dispositions and ERP/WMS adjustments, and feeds CAPA/CPV analytics from a single execution record.

Reviewed · By V5 Ultimate compliance team· 3,500 words · ~16 min read

01What It Is

Scrap reason coding is the controlled, standardized set of codes that explains why units, lots, or sublots are rejected and scrapped at any point in the manufacturing lifecycle. In MES terms, it is a governed master data list and a capture workflow: operators or automated stations select an enforced reason at the moment of nonconformance, associating it with batch/lot, material, equipment, operation/step, quantity, and disposition. Codes can reflect defect type (what), cause (why), and detection point (where/when), and are used to reconcile yield, support genealogy, and feed NCR/CAPA.

In regulated environments, accurate and contemporaneous reason coding underpins compliant batch/eDHR records and investigations: 21 CFR 211.188/211.192 require complete production records and review of discrepancies, and 21 CFR 820.90 demands control of nonconforming product. Reason codes transform raw rejects into actionable, auditable data, enabling both immediate control decisions and long-term process improvement.

02Regulatory Context and Why It Matters

For pharmaceuticals, coded scrap ties directly into production record completeness and discrepancy review per 21 CFR 211.188 and 211.192. For medical devices, it supports nonconforming product control under 21 CFR 820.90 and traceability in the eDHR. For food and dietary supplements, corrective actions under 21 CFR 117.150 hinge on understanding rejection causes. Across all, audit-trailed electronic capture must meet Part 11 and EU GMP Annex 11 expectations for integrity, security, and attributable actions in computerized systems.

Operationally, a mature reason code system closes the loop between execution, quality, and finance. It reconciles theoretical vs. actual yield, informs SPC and CPV programs, drives supplier performance management, and quantifies Cost of Poor Quality (COPQ). Under ISA-95, this is a Level 3 (MES) responsibility with integrations up to Level 4 (ERP/QMS) and down to Levels 2/1 (testers, vision, scales) for automated reject signals.

  • Demonstrate complete and contemporaneous records of rejects and dispositions (211.188/211.192).
  • Prove control of nonconforming product and linkage to NCR/CAPA (820.90).
  • Enable risk-based trending and verification (e.g., HACCP/PC corrective actions in 117.150).
  • Maintain data integrity with audit trails, e-signatures, and access control (Part 11, Annex 11).

03Taxonomy and Code Design

The most effective scrap reason taxonomies are hierarchical and unambiguous. At minimum, separate the defect descriptor (what failed) from the suspected root cause (why it failed) and from the detection point (where it was found). Keep codes atomic and mutually exclusive; use parent–child groupings for roll-up analytics (e.g., Equipment > Filler > Starwheel Jam; Material > Incoming > Out-of-Spec Viscosity). Avoid free-text proliferation by providing a governed Other (with mandatory, attributed comment) and an expedited path to propose new codes via change control.

Design principles

  • Governed master data: change-controlled, versioned code lists with effective dates and impact assessment.
  • Clean separation of dimensions: defect, cause, detection point, disposition, and responsibility (internal vs. supplier).
  • Granularity tuned to decisions: enough detail to drive corrective action and costing, not so much that selection accuracy drops.
  • Consistent semantics: clear definitions and examples for each code; include acceptable use notes in operator instructions.
  • Mappability: maintain crosswalks to ERP reason codes and QMS NCR categories.

In batch operations (ISA-88), align reason codes to unit procedures/operations so genealogy and step-level yields reconcile. Include options that reflect batch-specific realities—e.g., charge error, blend non-uniformity, tablet defects by pharmacopeial category, filter integrity failure, aseptic intervention failure—versus discrete assembly or molding defects in devices (short shot, flash, missing component).

04Where It Lives in ISA-95 and How It Integrates

Scrap reason coding sits natively at ISA-95 Level 3 (MES): it governs code lists, enforces capture at operations, binds context (lot/batch, equipment, step), and initiates quality and inventory actions. It integrates upward to ERP (valuation, GL posting, supplier chargeback), laterally to QMS (NCR/CAPA), and downward to Level 2/1 automation (reject signals, checkweighers, vision systems) for semi-automated attribution. When machine signals raise rejects, the MES should prompt for human-verified cause coding or apply deterministic rules if validated.

ISA-95 LevelScrap Reason Handling
Level 4 (ERP/Finance)Receives summarized scrap with standardized codes for inventory adjustment, cost roll-up, variance analysis, and supplier claims.
Level 3 (MES/QMS)Owns master code lists, enforces capture, associates context and dispositions, triggers NCR/CAPA, and updates genealogy and yield.
Levels 2–1 (SCADA/PLC/testers)Generate reject events (e.g., metal detector, vision fail, torque fail); optionally pass defect types; MES requests or maps to reason code.
Level 0 (Process/Physical)Physical defects, sensor thresholds, and operator observations at the line.

Use standard interfaces and message schemas for interoperability. While details vary, best practice is event-driven integration with minimal double-entry: ERP receives only the financial and inventory effects with harmonized codes; QMS receives a reference to the MES event with attachments and audit trails preserved in one system of record.

05Data Model, Capture, and Controls

Capturing a scrap event should be a forced, atomic action: no WIP decrement without a reason code and quantity/UoM, and no reason without context. Enforce operator identification (badge scan), timestamp, equipment and step, lot/batch/material identifiers (barcode/RFID), and optional attachments (photo, test result). Require QA authorization for critical dispositions and for any change to quantity or code post-save; such changes must be audit-trail visible with reason-for-change and e-signature per Part 11/Annex 11.

FieldPurpose
Reason Code (defect/primary)Standardized descriptor of what is nonconforming (e.g., crimp seal leak, metal inclusion, underweight).
Suspected Cause (optional)Attributed cause (e.g., worn die, incorrect torque setting); may be refined post-investigation.
Detection PointOperation/station/inspection step where detected; supports containment and Paretos.
DispositionScrap, rework, return to supplier, quarantine; controlled by QA.
Quantity/UoMCount, mass, volume; aligns to lot and ERP item UoM for valuation.
Batch/Lot & MaterialGenealogy and traceability to affected WIP/FG.
Equipment/ToolingLinks to asset history and maintenance correlation.
Operator/VerifierAccountability; supports training/skills trending.
Attachments/TestsPhotos, instrument output, analytical results supporting the decision.
  • Hard-stops for missing code/quantity/context.
  • Role-based selections (e.g., only QA may select Destructive Disposal).
  • Conditional logic (e.g., supplier-caused scrap triggers RTV workflow).
  • Real-time checks (e.g., cannot scrap more than current WIP at operation).
  • Batch-aware reconciliation (e.g., updates theoretical vs. actual yield).

06Operational Workflows Across Industries

Scrap reason capture varies with modality, but the principles are consistent. In a pharma batch, inline checks (weight, hardness, appearance) and end-of-line inspections generate rejects; each reject must carry a reason tied to the batch/step so OOS/OOT assessments and 211.192 reviews are substantiated. In a medical device cell, in-station poka-yoke and torque/vision failures flow to reject bins with scanned serialization; operators code the defect and suspected cause, while QMS NCR determines final disposition. In food, CCP/PC deviations prompt bulk rejections with cause and corrective actions per 117.150.

  • Pharma: Tablet capping/lamination, content uniformity failure, seal integrity failure, bioburden excursion during aseptic operations.
  • Devices: Short shot, voids, misassembly, torque out-of-spec, cosmetic defects beyond AQL.
  • Supplements/Food: Allergen cross-contact risk, metal detector reject, fill-weight below target, label mismatch.
  • Cosmetics: Viscosity out-of-spec, color variance, particulates, fill-volume under-target.

Embed the capture where work happens: barcode scans at reject chutes; operator tablets at inspection stations; eBR steps with enforced checklists and two-person e-signature for scrapping controlled materials. For automated stations, map machine codes to the approved vocabulary, and require operator confirmation for ambiguous categories. Attach photos or test records to strengthen investigations and CAPA evidence.

07Analytics, KPIs, and Continuous Verification

Reason-coded scrap is the feedstock for actionable analytics. At the line level, Pareto analysis highlights the few codes causing most losses. In batch operations, step-level yield deltas tied to codes reveal which operations drive loss. SPC on defect proportions, FPY, and quality rate trends support CPV and process capability re-assessments. At the enterprise level, a harmonized taxonomy enables benchmarking across sites, raw materials, and suppliers; coded supplier-caused scrap drives scorecards and commercial remedies.

Useful measures

  • Scrap rate by code, step, and equipment (trend and control charts).
  • FPY and OEE quality component (reject ratio as a loss bucket).
  • Yield reconciliation gap (theoretical vs. actual) with code attribution.
  • Supplier-caused scrap as % of receipts (by item/supplier).
  • Cost of Poor Quality by code family (material, labor, overhead).

Apply statistical rules responsibly: stable code definitions and sampling plans are prerequisites for meaningful SPC. Use reason codes to trigger variance investigations and 5-Whys; escalate persistent top codes to CAPA. For closed-loop control, integrate code-triggered actions—e.g., three consecutive seal-leak codes at a filler auto-escalate to maintenance and QA hold on the lot until verified fixed.

08Validation, Data Integrity, and Governance

Under GAMP 5’s risk-based approach, reason coding spans configured functions (code lists, workflows) and possibly custom integrations. Validate intended use: requirements must specify code governance, mandatory fields, role-based selections, e-signatures, and audit trail behaviors; test both positive and negative paths (e.g., prevent scrap without code, prevent code deactivation when in use). For computerized systems, Part 11 and Annex 11 require attributable, contemporaneous, legible, original, and accurate (ALCOA+) records and audit trails for create/modify/delete on codes and events.

  • Documented governance: ownership, change control, periodic review, and effective dating of codes.
  • Access control and segregation of duties (operators record; QA approves sensitive dispositions).
  • Audit trail verification in qualification (who/what/when/why for event edits).
  • Training and SOP alignment—operator instructions must list valid codes and usage examples.
  • Record retention aligned to product lifecycle and regulatory expectations.

Risk-based testing should focus on high-impact scenarios: mapping from automation to codes, ERP/QMS interfaces (no orphaned or mismatched codes), and security (only authorized users can alter quantities post-capture, with reason-for-change and re-signature). Verify that code changes do not retroactively rewrite historical analytics; use versioned catalogs with effective dates.

09QMS, ERP, and Inventory Integration

Scrap reason events often instantiate or link to QMS records: an NCR for nonconforming product, a deviation when a process step fails to meet requirements, and potentially CAPA for systemic recurrence. The MES should create these records with references and attachments rather than duplicating data, preserving one source of audit truth. Inventory and costing effects are propagated to ERP: item/lot decrement, valuation at standard or actual cost, and GL postings to scrap/variance accounts by reason family.

  • NCR creation when disposition is scrap or rework; map MES reason families to QMS categories.
  • CAPA triggers based on thresholds (e.g., monthly top-three codes by cost).
  • Supplier chargebacks/SCARs when reason is supplier-caused; auto-link to receiving lots.
  • ERP/WMS decrement and quarantine movements from the same event, preventing double counting.
  • Maintenance notifications for equipment-related codes, tying to failure modes in CMMS.

Keep the interfaces lean: pass identifiers and harmonized codes, not free text. Establish governance to maintain crosswalks as codes evolve. Validate that ERP/WMS cannot process inventory movements inconsistent with the MES disposition (e.g., prevent shipping of scrapped lots).

10Common Pitfalls and Anti-Patterns

The most common failures stem from poor taxonomy and weak governance. If operators face an unwieldy list, they default to Other or misclassify, destroying signal quality. Free-text fields without constraints proliferate variants of the same meaning, undermining Pareto analysis. Another failure mode is over-automation: blindly mapping machine reject codes to business reasons without human verification yields false attribution. Finally, orphaned integrations and unsynchronized crosswalks cause ERP/QMS mismatches that are hard to reconcile in audits.

  • Too many or too few codes; ambiguous definitions; overlapping categories.
  • Allowing edits to quantities/codes without reason-for-change and re-signature.
  • Not tying scrap to step/equipment, which blocks actionable investigation.
  • No linkage to NCR/CAPA; reasons never escalate into systemic fixes.
  • Unvalidated mappings from line automation; misattributed costs and wrong maintenance signals.

Mitigations include role-based shortlists, structured Other, periodic code hygiene (merge/retire review), and analytics feedback loops to ensure the taxonomy reflects real failure modes. Governance should require QA review of high-cost or high-risk reason families and periodic effectiveness checks of resulting CAPA.

11How V5 Ultimate Handles Scrap Reason Coding

V5 Ultimate centralizes reason-code governance as a master set shared by MES, QMS, WMS, and ERP integrations. At execution, codes are enforced in eBMR/eDHR steps with operator badge capture, barcode-based lot/equipment context, optional photo upload, and rules for QA authorization of sensitive dispositions. The same event decrements WIP/FG inventory, initiates NCR with attachments, and pushes harmonized codes to ERP/finance for valuation and to Maintenance when equipment-related. Part 11/Annex 11-compliant audit trails record every create/change with reason-for-change and e-signatures.

  • One source of truth: single master code set with versioning and effective dating.
  • Inline enforcement and conditional logic (e.g., supplier-caused auto-RTV hold).
  • Out-of-the-box mappings to NCR/CAPA and ERP inventory/GL posting by family.
  • Analytics: Pareto, FPY/OEE quality loss, supplier scorecards, and yield reconciliation dashboards.

Frequently asked questions

Q.What level of granularity should our scrap reason codes have?+

Target the smallest unit that drives different actions or costs. If two causes lead to different containment, maintenance, or supplier actions, separate them. Use hierarchical codes so operators choose specific leaf codes while analytics can roll up to meaningful families.

Q.How do we prevent free-text from diluting analytics while still capturing nuance?+

Provide a governed Other with mandatory, attributed comments and a workflow to propose new codes via change control. Periodically review Other usage; if a pattern repeats, formalize it as a code and update operator instructions.

Q.Can machine reject signals automatically assign scrap reasons?+

Yes, but validate mappings. Allow deterministic mappings only where specificity is high (e.g., metal detector reject to Foreign Material: Metal). For ambiguous cases, prompt the operator to confirm or refine the reason. All automated assignments must be visible in the audit trail.

Q.How does scrap reason coding support regulatory compliance?+

It ensures complete batch/eDHR records and supports discrepancy review (21 CFR 211.188/211.192) and control of nonconforming product (21 CFR 820.90). With Part 11/Annex 11 controls—attributable entries, audit trails, and e-signatures—records are reliable for investigations and inspections.

Q.What governance is needed for the code list?+

Assign ownership (typically QA/MES governance), manage through formal change control with impact assessment, maintain versioning and effective dates, review usage metrics quarterly to retire/merge low-value codes, and synchronize crosswalks with ERP/QMS to prevent mismatches.

Primary sources

Further reading

See Scrap Reason Coding working on a real shop floor

V5 Ultimate ships with the Scrap Reason Coding controls already wired in — audit trail, e-signatures, validation evidence. Free trial, no credit card, onboard in days, not months.