Most of what is written about production quality is about preventing defects. This page is about the more ordinary situation: something has already been rejected, the job is still live, and somebody has to decide what happens next without losing track of either half.
A stage rarely fails completely. It finishes with most of the quantity fine and a portion that is not, and the practical problem is that those two halves need different treatment while staying attached to the same job. Handle that badly and the shortfall reappears weeks later as an unexplained gap nobody can source.
Rejection is a quantity, not just a verdict
The instinct is to treat rejection as a judgement: this batch passed, that one did not. Useful production records treat it as arithmetic instead.
Take an illustrative case, with round numbers chosen to show the shape, not to describe any particular system. A hundred units reach an operation. Ninety-five come through acceptably. Five do not. What the record needs to hold is not "there was a problem at this stage" but both figures, kept apart, against the operation where it happened and the work order they belong to.
That separation does more work than it looks like. It lets the accepted quantity carry on through the remaining stages while the rejected quantity becomes its own question rather than a footnote. It gives the eventual shortfall a location and a size. And it means nobody has to reconstruct at month end what everybody knew on the day.
There is also a moment before the split, which is worth naming: something has to be checked. An inspection or QC result can be recorded before output is accepted or rejected, so the record carries the judgement and not only its outcome. Where no such step exists, the accepted and rejected figures are still useful, but they arrive without the reasoning behind them.
Why the reason matters more than the number
A rejected quantity on its own is a problem statement with nothing attached. Five units failed. You know the cost is somewhere, you know the schedule is affected, and you know nothing that helps you stop it happening again.
The same five units with a reason recorded against them are a different object entirely. Now the record says what went wrong, and once that is captured consistently across jobs it stops being a series of incidents and starts being a pattern. Three separate rejections that each looked like bad luck turn out to share a reason, and the reason turns out to point somewhere specific.
This is the part most likely to be skipped on the floor, because entering a reason feels like paperwork in the moment and only pays back later. It is worth deciding early who records it and how consistently, because inconsistent reason recording can produce analysis that looks more reliable than it really is.
Reworkable, or not
Once a quantity is rejected, there is a fork, and it is worth being precise about the three words that get used interchangeably and mean different things.
| Term | What it means | What it implies next |
|---|---|---|
| Rejection | Output is not accepted at the point where it is checked | A decision is required; nothing is resolved yet |
| Rework | Rejected output receives additional work intended to make it acceptable | Additional work is required before the output can be accepted |
| Scrap | Output that will not return to usable production | The quantity leaves the job for good; its downstream treatment is a separate subject |
Rejection is the event. Rework and scrap are the two outcomes it can lead to, and the choice between them is a judgement about whether the units can be brought back. That judgement belongs to people who can look at the material, not to a system.
What follows the scrap branch is a subject of its own, with questions about valuation, recovery and yield that this page deliberately leaves alone. The rest of this one follows the rework branch.
Keeping rework attached to the job it came from
Rework is correction, and correction has a habit of disappearing into normal production if nothing holds it in place.
The mechanism that prevents it is connection. Where rework is handled as its own work order, that order stays linked to the original job the rejected quantity came from. Both facts matter. Giving rework its own order makes it countable, so correction effort is visible as correction rather than absorbed into the general run of things. Keeping it linked means the visibility does not come at the price of losing the relationship: you can still see which job the rework belongs to and why it exists.
Take the link away and rework becomes ordinary production in the record. The original job looks like it went as planned, the rework order looks like a small job that appeared from nowhere, and the connection between the two lives only in somebody's memory. That is the failure worth designing against.
A rework order is initiated once somebody has decided the quantity is worth recovering. That decision is a production judgement, and the system's job is to record it and hold the relationship.
Reading rejection across production
Everything so far concerns a single job. The more valuable view is the one across all of them.
One rejection is an incident. The same rejection reason appearing at the same stage across a dozen jobs over two months is a finding, and the second only becomes visible if the first was recorded consistently. Rejection seen by stage tells you where in the process quality is being lost. Seen by product, it tells you whether the problem follows a particular item or a particular operation. Seen over a period, it tells you whether last month's fix worked.
Those are three different questions, and they are the reason to record rejection at the stage rather than at the end of the job. Once it is aggregated to a single figure per work order, the location is gone and the pattern with it.
Where the consequences go
A rejection reaches beyond quality, and the neighbouring subjects are worth naming instead of absorbing.
What it does to the job's progress belongs to execution: a stage that finishes with less acceptable output than it started with changes what completion means there, which is covered in work-order execution and shop-floor tracking. Once rework begins to change actual material, labour, machine or overhead cost, the question becomes one of costing and how that cost should be attributed, which is covered properly in work-order costing and variance. And what happens to output that will not be recovered, together with yield, is covered in scrap, by-product and yield tracking.
What to make an ERP vendor demonstrate
Rejection demonstrates badly for the same reason execution does: a prepared job never fails. The wider evaluation method is set out in the ERP selection and evaluation guide; the sequence below is the one specific to quality exceptions.
- Take a job through a real rejection, not a clean run. Record an inspection or QC result and reject part of the quantity.
- Show the accepted and rejected figures held separately, and show both tied to the stage and to the work order.
- Record a reason against the rejection, and ask how consistently that is enforced in practice.
- Initiate the rework and show the link back to the original job.
- Ask for rejection across jobs: by stage, by product, and over a period, without anyone compiling it.
- Follow the cost consequence far enough to see where it lands.
Then ask what the system does not do, because that is where assumptions hide. What prevents rejected output from moving forward? Is there any hold or quarantine mechanism? Are inspection specifications or sampling plans supported? These are good questions precisely because the answers vary, and a vendor who treats them as reasonable is more useful than one who treats every answer as yes.
How exactllyERP handles rejection and rework
In exactllyERP, an inspection or QC result can be recorded before output is accepted or rejected, and accepted quantity and rejected quantity are then retained separately at the production stage.
Rejection is recorded at the specific production stage or routing step and against the work order, with the rejected quantity and a reason, including a reason code. A separate rework work order can be initiated and remains linked to the original work order.
Across jobs, rejection can be reviewed by stage, by product and by period, with the trend over time available for quality review. The broader manufacturing workflow this sits inside is described on the manufacturing ERP page, and the functional scope across procurement, inventory, production and finance on the features page.
This page describes capability, not configuration. Which stages warrant a recorded check, how reasons should be structured for the way your plant actually fails, and who decides whether a quantity is worth recovering are implementation choices that depend on the operation. They are worth settling deliberately, because together they decide whether the resulting record is analysable or merely complete.
Common questions
What does it mean to record rejection at a production stage?
It means the rejection is attached to the place it happened and to the job it happened on, instead of surfacing later as an unexplained gap between what was issued and what was produced. Recording it at the stage keeps three things together: which operation the quantity failed at, which work order it belonged to, and how much was involved. Without that, the same shortfall still exists but has to be reconstructed from memory at month end, by which point the useful detail has gone.
Can accepted and rejected quantities be kept separate at a stage?
Yes. In exactllyERP, accepted quantity and rejected quantity are retained separately at the production stage. That distinction is what makes the rest of it work. A single completed figure tells you the stage finished; two figures tell you the stage finished with an exception, how large it was, and what still needs a decision. It also means the accepted quantity can carry on through the process while the rejected quantity is dealt with as its own question.
Can the reason for rejection be recorded?
Yes. A reason can be recorded against the rejection, including a reason code. This matters more than it first appears. A rejected quantity on its own tells you something went wrong and gives you nothing to act on; the same quantity with a reason attached tells you what to look at. Recorded consistently across jobs, reasons are what turn scattered incidents into a pattern somebody can investigate rather than a number somebody defends at a review meeting.
How does rework stay connected to the original work order?
In exactllyERP, rework is handled through a separate rework work order that remains linked to the original work order. The linkage is the part that matters. Rework raised as a standalone job with no connection back becomes ordinary production in the record, which quietly flatters the original job and hides what correction actually took. Keeping the link means the effort spent putting something right stays attached to the work that produced the problem.
What should a manufacturer ask an ERP vendor to demonstrate about rejection and rework?
Ask for one job taken through a real rejection, not a clean run. Record an inspection or QC result and reject part of the quantity. Look for the accepted and rejected figures held separately, both tied to the stage and the work order, with a reason against the rejection. Then initiate the rework and check that it stays linked to the original job. Finish by asking what the system does not do: what stops rejected output moving forward, whether any hold exists, and where the cost consequence ends up.
Where to start
Pick the rejection your plant argues about. Not the routine scrap everybody has accepted, but the one that comes up at the monthly review and never quite gets resolved because nobody can say where it happened or why.
Ask what would need to have been recorded, at the moment it happened, for that argument to be unnecessary. If exactllyERP is on your shortlist, bring that rejection to the demonstration and ask to see it recorded.