Manufacturing · Scrap and Waste Report

Scrap and Waste Reporting: Reducing Cost and Improving Yield on the Production Floor

20 May 202610 min readPerth, Western Australia

Short answer

Scrap and waste reporting measures the units, weight or value of product lost on the production floor and classifies it by cause - startup, process, rework, and material - so manufacturers can prioritise the fixes that will improve yield and protect margin. Most plants are surprised by the total when scrap is reported properly for the first time, because the data was previously scattered across log sheets, quality systems and ERP write-offs. SolveBI builds scrap dashboards on Microsoft Power BI and Fabric that unify these sources and link every unit of scrap to its likely root cause.

A pile of rejected metal components in a factory - the kind of scrap that, once measured and classified, becomes a recoverable margin.

Why scrap is the most under-managed cost in most plants

Scrap is unusually expensive because every scrapped unit consumed the same material, labour, energy and machine time as a good one - and then required additional handling, storage or disposal on top. Despite that, it tends to be the least-managed cost line in the plant, because the data lives in three or four places and no single owner sees the full picture.

Good scrap reporting fixes that by pulling every source of loss into one view, classifying each unit by likely cause, and putting a dollar value on it. The point is not to shame the line - it is to make the loss visible enough that someone can fix it.

3-8%
Typical scrap rate across Australian discrete manufacturing
1-3%
Achievable scrap rate with disciplined reporting and process control
5-15x
True cost of a scrapped unit vs. its raw material cost, once labour, machine time and overhead are included

The main types of scrap, and why classification matters

Lumping all scrap into a single number is a tempting simplification that destroys the report's usefulness. The same total can come from very different causes, each requiring a different fix:

  • Startup scrap - generated while the line warms up, settles a recipe or stabilises after a changeover. Reduced by changeover and recipe-management improvements, not by quality programs.
  • Process scrap - generated during steady-state running due to drift, tool wear or process variation. Reduced by process control, condition monitoring and SPC.
  • Rework scrap - units that were reworked but ultimately failed. Often the most expensive category because the loss includes the rework labour.
  • Material scrap - raw material lost to handling, contamination or expiry before it ever reaches the line. Reduced by inventory and material-handling improvements.

Turning a scrap number into a root cause

Engineers reviewing production data on a screen in a factory - a typical root-cause analysis session driven by good scrap reporting.
A Pareto of scrap reasons usually shows that two or three causes drive the majority of the loss - that is where the next improvement project goes.

The most useful scrap dashboard is not the one with the most charts - it is the one that lets the team move from a number to a cause in two or three clicks. The standard pattern we use on Power BI:

  • Headline scrap rate with current vs. target and a trend line
  • Pareto of scrap reasons for the selected period - the 80/20 view
  • Scrap by line, shift and product so the team can isolate where the loss concentrates
  • Trend by reason code so improvements (or regressions) are visible within a week
  • Drill-through to event-level data for the engineer who needs the specific batch, time and operator context

Putting a dollar value on scrap (and why it changes the conversation)

Scrap measured only in units or kilograms quietly gets ignored. Scrap measured in dollars - especially margin dollars - tends to get a project. The translation is not difficult: every scrap event is associated with a product, the product has a standard cost or a margin, and the math from there is a single multiplication. The hard part is making sure the data sources line up so the dollar number is trusted.

Why dollar-denominated scrap reporting changes outcomes

AspectUnits / kilograms onlyUnits, kilograms and dollars
Audience that engagesProduction supervisorsProduction, finance, executive team
Typical reactionFiled and forgottenBudget assigned, project initiated
Trade-off discussionsHard - no common languageEasy - scrap vs. fix cost is comparable
Build effortTrivialOne extra join in the semantic model

Linking scrap reports to maintenance, training and process control

A scrap report that lives in isolation is mostly an accounting record. The reports we build are designed to plug straight into the levers that actually move scrap down:

  • Maintenance - if scrap spikes on a specific machine after a certain run time, that is a maintenance trigger, not a quality problem.
  • Training - if scrap concentrates on a particular shift or operator, the answer is usually training and process documentation, not discipline.
  • Process control - if scrap drifts as conditions change, the answer is tighter set-points, SPC and condition monitoring.
  • Procurement - if scrap rises with a specific raw material lot or supplier, the report should expose that link.

Where the data lives - and how Power BI ties it together

A useful scrap dashboard joins data the business already produces. On a typical SolveBI deployment we land production-counter feeds, quality and non-conformance data from the QMS, ERP write-offs and material-master cost data into Microsoft Fabric, then serve a single semantic model through Power BI. The dollar value of every scrap event lives on the same dataset that powers operator dashboards, plant-manager exception views and the executive yield-loss report.

Common mistakes in scrap and waste reporting

  1. Counting scrap inconsistently across shifts. If night shift records scrap differently from day shift, the report is comparing apples to oranges. Standard reason codes, applied consistently, are foundational.
  2. Ignoring rework as part of total loss. Rework labour and machine time often cost more than the eventual scrap itself.
  3. No dollar denomination. Without it, scrap competes for attention with every other metric and usually loses.
  4. Reporting only at line level. The pattern by product or by shift is almost always more revealing than the pattern by line.
  5. Treating scrap reduction as a quality-only initiative. Most scrap reduction wins come from maintenance, training and material handling, not from quality inspection.

Scrap reporting in different manufacturing sectors

Plastics and packaging

Startup and grade-transition scrap usually dominate. Reporting that exposes the cumulative cost of transitions often justifies recipe-tuning or scheduling-optimisation projects with a clear payback.

Metal fabrication and machining

Tool wear is the most common scrap driver. Reporting that ties scrap to tool life and changeover patterns is what makes predictive tool-change schedules possible.

Electronics assembly

Component defects, placement errors and inspection rejects each have very different root causes. Classification and drill-through are the difference between a useful report and a number nobody trusts.

From scattered scrap logs to a single recoverable margin number.

Book a free 30-minute consultation with a Microsoft-certified SolveBI consultant. We'll map your current scrap data sources, agree the right reason-code structure, and quote a phased Power BI deployment you can budget against.

Frequently Asked

Common Questions

We already track scrap in our ERP. Why do we need a separate report?
ERP captures scrap for accounting purposes - usually at the end of the shift or day, classified at a fairly high level. A proper scrap report adds reason codes, real-time visibility, drill-through to the underlying events and the dollar denomination needed to support improvement projects. The ERP record remains the source of truth for finance; the report is the source of truth for operations.
How do we decide which scrap reason codes to use?
Start with the minimum set that distinguishes startup, process, rework and material categories. Then add codes only when there is a specific improvement action they would unlock. Reason-code proliferation kills adoption faster than any other failure mode in scrap reporting.
Can scrap data come from operators, or does it have to be automated?
Operator-keyed scrap data is fine, especially in the early stages. What matters is that the codes are consistent, the entry is fast, and the result is visible to the team within the same shift. Automation - via vision systems, gauging or QMS integration - is a phase two enhancement, not a prerequisite.
Will scrap reporting create finger-pointing on the floor?
Only if the dashboard is set up that way. The teams we work with frame scrap reporting as 'where is the plant losing money', not 'who made the most scrap'. The data is then used to fund fixes, not to assign blame - and adoption follows quickly.
How quickly can a scrap dashboard go live?
Once reason codes are agreed and the data sources identified, a first useful scrap dashboard is typically live within three to six weeks. Linking it to dollar-denominated COPQ and to ERP write-offs adds another phase, depending on system complexity.