Scrap and Reject Coding

This topic is part of the SG Systems Global scrap, yield, defect analysis & cost-of-quality control glossary.

Updated December 2025 • Defect & Cause Codes, COPQ, Molding Defect SPC, SPC, Cost of Poor Quality (COPQ), NC, CAPA, MES, WMS, QMS • Discrete Manufacturing, Plastics, Medical Devices, Food & CPG, Automotive

Scrap and reject coding is the structured way a plant labels every scrap and reject event with meaningful, standardised codes for what went wrong and, where possible, why. It turns piles of “bad parts” into analysable signals: defect types, suspected causes, locations, equipment, shifts and materials. When scrap and reject coding is strong, COPQ, SPC and continuous improvement have real data to work with. When it is weak, you have quantity but no insight—just a big scrap number and a lot of opinions.

“If half your scrap is coded as ‘other’, the only thing you know for sure is that you don’t know much.”

1) What Is Scrap and Reject Coding?

Scrap and reject coding is the process of classifying nonconforming product, material and work into defined categories using codes that are:

• Standardised: The same code means the same thing across lines, shifts and sites.
• Structured: Codes have a clear hierarchy (e.g. category → subcategory) and often separate “defect” from “cause”.
• Contextual: Codes are captured with additional context (lot, machine, tool, shift, operator, material, order).

In practice, this looks like operators, inspectors or automated systems applying a small set of codes whenever parts are scrapped or rejected—on MES terminals, scanners, inspection stations or WMS screens—rather than writing “scrap” in a comments box or doing nothing at all until month-end.

2) Why Scrap and Reject Coding Matters

Without meaningful scrap coding, an organisation knows only:

• How many units or kilos were scrapped.
• Roughly where (by department, line or site) and when.

That is not enough to:

• Identify top defect modes and root causes.
• Quantify the real cost of poor quality (COPQ) by defect type.
• Assess the impact of tooling, material or process changes on actual scrap patterns.
• Target CAPA and improvement projects where they will pay back fastest.

Scrap and reject coding turns “scrap is high” into “short shots from tool 17 on press 4 increased on the night shift after resin changeovers”. That is the difference between generic exhortations to “be more careful” and focussed, data-backed changes that actually move the needle.

3) Relationship to Defects, NCs, CAPA & SPC

Scrap and reject coding underpins multiple quality mechanisms:

• Defect tracking: Code sets often align with defect libraries used in molding defect SPC and visual inspection standards.
• Nonconformance (NC) & CAPA: Frequently recurring scrap codes feed into formal NC and CAPA workflows; NCs refer back to coded scrap to quantify impact.
• SPC: Scrap rates by code, tool, cavity or line feed directly into SPC charts and capability analyses.
• Risk management & FMEA: High-frequency or high-severity codes inform risk rankings and mitigation priorities.

In short: if scrap and reject coding is vague or inconsistent, all downstream analyses (SPC, CAPA, FMEA, risk reviews) are built on sand. If it is robust, those same processes become far more credible and targeted.

4) Designing a Scrap & Reject Code Set

A good code set is:

• Short enough to be used consistently (usually 20–50 primary codes, not hundreds).
• Rich enough to differentiate meaningful failure modes and causes.
• Hierarchical, with top-level categories (e.g. material, process, equipment, documentation, handling) and detailed subcodes.
• Aligned with existing defect libraries and customer/industry standards where applicable.

A common pattern is to separate defect codes (what is wrong with the part) from cause codes (why it happened). For example: defect “short shot”, cause “low pack pressure” or defect “wrong label”, cause “component pick error”. This two-dimensional structure avoids forcing cause guesses into defect fields and makes it easier to pivot data by either dimension later.

5) Where & When Scrap Codes Are Captured

Scrap and reject coding should occur as close as possible to the point where parts are deemed nonconforming, for example:

• At the press or line, as operators scrap start-up or in-process parts.
• At automated inspection or vision systems recording rejects by reason.
• At QC labs or final inspection when lots are partially or fully rejected.
• In the warehouse or shipping if damage or mislabelling is discovered post-production.

Each capture point may use a subset of codes relevant to its role, but all should feed a common code set and data model in MES/WMS/ERP. Capturing codes only at the end of the month, or only for “major” rejections, misses the early warning signs visible in day-to-day scrap behaviour and deprives SPC and COPQ analyses of granularity.

6) Data Model – Defect vs Cause vs Disposition

Scrap and reject coding is more than a single “reason” field. A robust model usually captures:

• Defect code: The observable issue with the part or material.
• Cause code (if known): The suspected or confirmed underlying cause.
• Disposition: Scrap, rework, downgrade, return-to-supplier, use-as-is with concession.
• Context: Lot, order, machine, tool, cavity, material lot, shift, operator, customer.

This multi-field structure allows you to separate “what we see” from “what we think caused it” and “what we did with it”. That in turn makes it easier to tell the difference between well-understood issues and noisy, poorly understood ones that need deeper investigation via NC and CAPA workflows in the QMS.

7) Integration with MES, WMS, ERP & Finance

Scrap and reject codes deliver the most value when integrated across systems:

• MES: Captures defect and cause codes at the line, linked to work orders and lots.
• WMS: Applies codes when inventory is scrapped, downgraded or reworked, keeping physical and digital stock aligned.
• ERP / finance: Uses coded scrap quantities and values to calculate COPQ by product, customer, process or failure mode.

When systems are disconnected, scrap coding lives in local spreadsheets or on paper and never reaches finance or planning. That hides margin erosion and makes it almost impossible to demonstrate the ROI of tooling, automation or training projects aimed at specific scrap drivers. Integration lets you say “this project eliminated X kg / Y hours / Z dollars of scrap coded as [specific reason]”, not just “scrap feels better”.

8) Using Scrap Codes in SPC, OEE & CI

Scrap and reject coding feeds multiple analyses:

• Pareto charts: Top 10 scrap reasons by volume, value or frequency.
• SPC & trends: Scrap rates by code over time, correlated with process changes, tools, resins or shifts.
• OEE: Quality component of Overall Equipment Effectiveness (OEE) broken down by scrap code.
• CI pipelines: Candidate projects ranked by their scrap/COPQ impact.

Without scrap coding, CI programmes often chase visible problems or the loudest complaints. With it, they can systematically attack the top three or five coded scrap drivers and prove whether interventions changed the mix. Scrap coding thus becomes a backbone for prioritisation and verification of improvement claims—not just a reporting burden.

9) Typical Failure Modes & Red Flags

Signs that scrap and reject coding is weak include:

• Overuse of “other”, “miscellaneous” or “unknown” codes.
• Large differences in coding patterns between shifts or similar lines without obvious technical reasons.
• Codes that mix defect and cause in one label (“warpage – low pack”).
• Operators choosing the first code in an alphabetic list to save time.
• No training or reference materials showing examples of each code.

These red flags show up quickly when comparing code distributions or asking operators how they choose codes. The underlying issue is usually that coding adds effort but is seen as low value. Making it easier (short lists, good UI) and visibly useful (showing results in daily/weekly meetings) is key to shifting behaviour from “click anything” to genuine classification.

10) Implementation Roadmap & Practice Tips

For plants formalising scrap and reject coding, a pragmatic roadmap looks like this:

• Define the code set: Start with existing defect libraries, FMEA failure modes and the most common scrap reasons; keep it short but meaningful.
• Design the UI: Make it easy to choose the right code on MES/WMS screens—group by category, use clear names, avoid long scrolling lists.
• Pilot on selected lines: Start with a few representative lines/products and refine codes based on real use and feedback.
• Train with examples: Use photos or sample parts showing which code applies to which defect; clarify when “cause unknown” is acceptable.
• Review & adjust: Run early Pareto charts; eliminate unused codes, split overused ones and tighten “other”.
• Link to QMS & CI: Feed recurring codes into NC, CAPA and CI project selection; show teams how coding influences where money and engineering time go.
• Scale and standardise: Extend to more lines and sites once the pattern works; maintain one master code set under QMS control.

The objective is not to create a perfect taxonomy on day one. It is to get to a “good enough” code set that people actually use, then improve it based on the patterns and blind spots revealed by real factory data.

11) Audit, Regulatory & Customer Expectations

Auditors and OEMs are increasingly interested in how organisations understand and control their scrap. Typical questions include:

• “What are your top sources of internal scrap and how do you know?”
• “How do you ensure that recurring issues identified in scrap data are addressed through CAPA?”
• “Show us scrap trends by defect category over the last 12–24 months.”
• “How is scrap data integrated into risk assessments and management reviews?”

Plants with robust scrap and reject coding can answer with clear Pareto charts, trend plots and linked NC/CAPA histories. Plants without it often provide total scrap percentages and anecdotal explanations. The difference in perceived maturity is obvious, even if no regulation explicitly says “thou shalt code scrap”.

12) Digitalisation & Industry 4.0 – Real-Time Scrap Intelligence

In an Industry 4.0 setting, scrap and reject coding can be amplified by:

• Automatic defect classification from vision systems and test equipment feeding codes directly into MES.
• Real-time dashboards highlighting scrap spikes by code, line and shift.
• Analytics that correlate scrap codes with process parameters, resin lots, tools and changeovers.
• Predictive models that flag increased risk of specific defect codes based on process signatures.

But these advanced tools are only as good as the coding discipline and data model behind them. If codes are inconsistent, over-generic or rarely used, no amount of analytics will generate trustworthy insight. The groundwork—clear codes, easy capture, visible use—must be in place before Industry 4.0 can turn scrap data into real competitive advantage.

13) What This Means for V5

For manufacturers running the V5 platform, scrap and reject coding can be implemented as an integrated, enforced behaviour across MES, WMS, QMS and analytics—rather than as a separate spreadsheet or paper form that no one fully trusts. Each V5 product contributes a piece of the loop:

• V5 Solution Overview – Frames scrap, yield and COPQ as first-class metrics in the V5 data model. Scrap events, coded by defect and cause, live alongside SPC signals, genealogy and OEE—not in isolated reports—so leadership can see where value is gained or lost at a glance.
• V5 MES – Manufacturing Execution System – Is the primary capture layer for scrap and reject coding:
  • Press-side and line-side terminals present short, role-specific code lists to operators and inspectors.
  • Scrap and reject events are tied directly to work orders, tools, cavities, shifts and material lots.
  • Coded scrap feeds molding defect SPC, batch records and live defect Pareto charts used in daily stand-ups.
• V5 WMS – Warehouse Management System – Connects scrap coding to physical stock and flows:
  • Scrapped or downgraded inventory in V5 WMS carries the same defect/disposition codes used in V5 MES, ensuring stock and COPQ reports align.
  • Purge, regrind and off-grade material from changeovers and start-ups can be coded and routed correctly via regrind usage control and resin changeover control.
• V5 QMS – Quality Management System – Uses scrap and reject coding as a trigger and evidence source:
  • High-frequency or high-severity scrap codes can automatically open NC records or CAPA candidates.
  • NC and CAPA workflows pull in coded scrap histories from V5 MES/WMS to quantify impact and verify effectiveness.
  • Management review dashboards draw on scrap-coded COPQ data to focus risk and investment decisions.
• V5 Connect API – Extends V5 scrap intelligence to and from external systems:
  • Vision systems and test stands can inject automatic reject codes into V5 MES via the API.
  • Corporate BI platforms can consume V5’s coded scrap data for multi-plant benchmarking and budgeting.
  • Customer portals and OEM dashboards can be supplied with aggregated, code-level defect metrics without manual data wrangling.

In practice, this means that in V5 you can go from “scrap is high” to “here are the top five coded scrap drivers by value, the lines and tools associated with them, the CAPA actions in flight, and the trend since those actions started.” The glossary concept of scrap and reject coding becomes a visible set of V5 screens, workflows and reports that make quality losses measurable, actionable and provably shrinking over time.

FAQ

Q1. How many scrap and reject codes do we really need?
Enough to distinguish meaningful patterns, but not so many that operators are overwhelmed. Many plants find that 20–50 primary defect codes plus a smaller set of cause codes and a tightly controlled “other” category provides good balance. The right number depends on product diversity and risk, but over-long lists usually hurt data quality more than they help analysis.

Q2. Should operators be forced to choose a cause code even if they are unsure?
Forcing a guess can corrupt data. A better approach is to make defect coding mandatory and cause coding encouraged with an explicit “cause unknown” or “to be determined” option. Root-cause information can then be added later via NC/CAPA workflows once investigations are complete, rather than captured as speculation at the line.

Q3. How do we prevent people from overusing “other”?
Make “other” a conscious choice: require a short text note for context, monitor “other” share in Pareto charts, and periodically review entries to decide whether a new code is warranted or training on existing codes is needed. If “other” consistently appears in the top reasons for scrap, the code set or training needs attention, not the operators alone.

Q4. Should scrap and reject coding be the same across all plants?
A common core code set across sites is highly beneficial for corporate reporting, benchmarking and shared learning. Local extensions can be allowed where processes differ, but should be managed under central QMS governance to avoid divergence. The core set should cover at least 80 % of typical failure modes across the network.

Q5. What is the first practical step if scrap and reject reasons are currently free-text or not recorded?
Start small. Define a basic, high-impact defect code list covering the 10–20 most common and costly scrap reasons you already know about. Implement it on a few key lines via MES or simple forms, train operators with examples, and start using the resulting Pareto charts in daily/weekly meetings. Once people see the value, expand the code set and coverage gradually, and move from free-text to structured codes as the default.

Related Reading
• Defects, SPC & COPQ: Molding Defect SPC | Statistical Process Control (SPC) | Cost of Poor Quality (COPQ)
• Genealogy & NC/CAPA: Deviation / Nonconformance (NC) | CAPA | Traceability & End-to-End Lot Genealogy | Batch Manufacturing Record (BMR) | Device History Record (DHR)
• Systems & V5 Platform: V5 Solution Overview | V5 MES – Manufacturing Execution System | V5 WMS – Warehouse Management System | V5 QMS – Quality Management System | V5 Connect API | Data Integrity | Change Control