A customer sends back 50 units. The cartons are crushed, but the product inside is sealed and perfectly good — it needs new packaging and nothing else. You raise a Work Order to repack them, and ERPNext insists on consuming a full set of raw materials from the BOM, as if you were making the product from scratch. You set the required quantities to zero, save, and they come back. This is not a configuration mistake: ERPNext has no rework Work Order, and this guide covers the three ways round it that do not wreck your valuation.
Working out what the rework should have cost?
The valuation half of this problem is the same one covered in how ERPNext calculates finished-goods cost — worth reading alongside, because a rework posted through the wrong BOM lands directly in that calculation.
ERPNext models making things and unmaking things. It does not model fixing things. I am Manoj, ERPNext and Frappe implementation lead at Mith Tech in Bengaluru, and this comes up on nearly every discrete-manufacturing implementation that accepts customer returns.
Why ERPNext fights you here
A Work Order in ERPNext is a request to produce a quantity of a finished good against a BOM. The required_items table is not free-form input — it is derived from the BOM's component ratio multiplied by the quantity to manufacture. That derivation is the whole point of the document: it is what makes material planning, reservation and shortage reporting work.
Rework breaks the assumption underneath it. When you repack a returned unit, the finished good already exists. The raw material is physically sitting inside the thing you are holding. What you need is a Work Order whose input is the product itself, with the BOM's component list suppressed — and that is precisely what ERPNext will not let you express, because a suppressed component list contradicts the BOM the Work Order is built from.
The feature request in #54663 asks for three things: a Rework purpose on the Work Order, the ability to freeze an individual required_items quantity so BOM recalculation leaves it alone, and a re-delivery linked to the original Sales Order. As of v16.12.0 with Frappe v16.13.0, none of them exist, and the issue carries no linked pull request or maintainer-assigned fix date. Treat it as a gap to design around rather than something to wait for.
Check your returned-goods warehouse before anything else
Every approach below assumes returned units are physically and logically separate from sellable stock. If returns land back in your finished-goods warehouse, the quantity is available to sell before it has been reworked, and no amount of BOM design fixes that. Set up a Returns warehouse first.
Which situation are you actually in
"Rework" covers four quite different physical operations, and ERPNext supports two of them cleanly today. Establish which one you have before designing anything.
Select the return scenario you are dealing with to see what ERPNext does today, which issue tracks the gap, and the recommended approach.
Pick the return scenario you are actually dealing with.
A full teardown back to components is a disassembly, and a Stock Entry handles it — you issue the finished good and receive the components, which is a manufacture entry in reverse. Unusable returns are a write-off, closer in shape to the scrap handling covered in our scrap, wastage and by-product guide. Neither of those needs a Work Order.
The two that hurt are the partial ones: packaging replaced with contents intact, and a handful of components swapped while the rest stay put. Both want a Work Order whose BOM lies about what goes in.
What the wrong model actually costs
The reason this matters beyond tidiness is that a Work Order run against the production BOM issues real stock. Those components leave your stores, hit the manufacture entry, and land in the finished good's valuation. Nothing errors. The quantity is simply wrong, and it is wrong in a direction that inflates both your material consumption and your finished-goods value.
Enter your own rework volume and component costs to see how much material consumption the production-BOM approach overstates.
Running the rework through the production BOM overstates material consumption by 21.0× — about ₹4,80,000 a year of raw material issued against jobs that never used it. That lands in your finished-goods valuation and your production variance, not in a line anyone reviews.
Illustrative arithmetic using your own inputs — it is not a benchmark. Confirm the real component costs against your BOM before quoting a figure internally.
The figure it produces is not a benchmark — it is your own arithmetic. But the shape is consistent across the implementations I have seen: because the replaced component is usually a fraction of the product's value, running rework through the production BOM overstates consumption by a large multiple, and that multiple compounds every month it goes unnoticed. If you run standard costing, it surfaces as a persistent unfavourable material variance nobody can explain.
The three approaches
Copy-paste steps for the rework BOM, the Repack Stock Entry, the traceability fields, and the three approaches to avoid.
The only approach that keeps costing honest. A separate BOM whose inputs are the returned unit plus whatever is genuinely replaced.
1. Create a new Item, e.g. "FG-001-RETURNED", or reuse
the finished good with a distinct warehouse for
returned stock. Keep returned units out of sellable
stock either way.
2. New BOM → Item = FG-001 (the sellable good)
Items table:
• FG-001-RETURNED qty 1 ← the returned unit
• CARTON-A qty 1 ← new packaging only
Do NOT copy the production BOM's raw materials.
3. Work Order against THIS BOM. ERPNext now recalculates
from a BOM that is already correct, so there is
nothing to override.
4. Manufacture Stock Entry consumes the returned unit +
packaging, and receives a sellable FG-001.
Why this works: you are not fighting the BOM ratio
recalculation described in #54663 — you removed the
reason for it.Segregate returned stock
Create a Returns warehouse and receive every customer return into it, or use a distinct item code for returned units. Whichever you pick, the requirement is the same: a returned unit must not be sellable until it has been reworked. This is the step people skip, and it is the one that causes the "we sold a damaged unit" incident three months later.
Choose the model
If reworks are occasional and amount to a packaging swap, use a Repack Stock Entry — no Work Order, no BOM, done in a minute. If reworks are routine, or you need operation-level costing, Job Cards, or a routing, build a rework BOM. The dividing line is whether anyone needs to know how long the rework took.
Build the rework BOM
Create a BOM producing the sellable finished good, whose items are the returned unit (quantity 1) plus only the components genuinely replaced. Do not duplicate the production BOM and edit it down — start empty, so nothing is inherited by accident. This BOM is a permanent, versioned artefact, which is exactly what you want when an auditor asks how rework was costed.
Raise the Work Order against it
Because the rework BOM is already correct, ERPNext's recalculation produces the right required_items with no overrides. The behaviour in #54663 stops being a problem, because you have removed the reason for it rather than fighting it.
Verify the incoming valuation
Before submitting the manufacture Stock Entry, check the finished good's incoming rate. It should equal the returned unit's carrying value plus the replaced component — not a fresh material set. If it looks like a normal production cost, the Work Order picked up the wrong BOM. This check takes ten seconds and catches the whole class of error, in the same way the incoming-rate check does for multi-level BOMs.
When the rework crosses a role boundary
On most shop floors the person who receives the return is not the person who decides whether it can be reworked, and neither of them owns the BOM. That split is where the design leaks: production creates a Work Order against whatever BOM is to hand, because the correct one either does not exist yet or nobody told them about it.
The pattern that holds is a saved report rather than a permission rule. Build a Report Builder view on Work Order filtered to your rework BOMs, with columns for the original Sales Order custom field, quantity, status and creation date, and have whoever owns costing review it weekly. You are not trying to prevent the wrong Work Order — you are trying to catch it inside the period, while the entry can still be cancelled cleanly rather than corrected with a second entry that hides the first.
Give the BOM naming a convention that makes the mistake visible: prefix every rework BOM with RW-. A production Work Order carrying an RW- BOM, or a rework carrying a production BOM, is then obvious in a list view instead of requiring someone to open the document.
Draft policy for your production and finance leads to ratify. Returned finished goods are received into a Returns warehouse within one working day and are not sellable from that warehouse. Rework is processed against a BOM prefixed
RW-; using a production BOM for rework is a costing error, not a shortcut. Any rework batch above 25 units, or whose replaced-component value exceeds 15% of the finished good's standard cost, is reviewed by the costing owner before the Work Order is submitted. These thresholds are a starting point — set them against your own volumes and materiality, and have your auditor confirm them before they go into an SOP.
Fix it now, or park it
FAQ
+Does ERPNext have a rework work order?
No. There is no Rework purpose on the Work Order in v15 or v16. It is an open feature request, #54663, raised against v16.12.0 with no linked fix. The workable approach today is a separate rework BOM whose input is the returned finished good.
+Why does ERPNext keep resetting the raw material quantities I set to zero?
Because required_items on a Work Order is derived from the BOM's component ratio, not entered by hand. When the BOM or the quantity to manufacture changes, ERPNext recalculates the table from the BOM, and your manual zeroes are replaced. The fix is a BOM that is already correct rather than an override.
+How do I rework a returned product in ERPNext without consuming raw materials again?
Build a BOM for the finished good whose items are the returned unit plus only the components actually replaced, and raise the Work Order against that BOM. For a simple packaging swap you can skip the Work Order entirely and use a Repack Stock Entry, issuing the returned unit and the new packaging and receiving the sellable good.
+Can I just set the returned item's valuation rate to zero?
Don't. It makes a single Work Order balance and then corrupts every FIFO layer for that item afterwards, because the zero-valued quantity sits in stock and gets consumed by later transactions at that rate. You end up with understated COGS on unrelated sales, which is far harder to unpick than the original problem.
+Which ERPNext version does this apply to?
The gap exists in v15 and v16. Issue #54663 was raised against ERPNext v16.12.0 with Frappe v16.13.0 and remains open. The BOM-ratio recalculation that causes it is long-standing behaviour, not a recent regression, so older v14 instances behave the same way.
+Will a rework Work Order link back to the original Sales Order?
Not on its own. ERPNext does not connect a rework or its replacement Delivery Note to the sale it replaces — that is the third part of the #54663 request. If you need the trail for warranty or claims, add a Link custom field on Work Order and Delivery Note and populate it at creation.
+What happens if we keep running reworks through the production BOM?
Material consumption is overstated by roughly the ratio of full material cost to replaced-component cost, every time. It inflates finished-goods valuation, produces a persistent unfavourable material variance if you run standard costing, and leaves your stores balance lower than the physical count — which then surfaces as a reconciliation problem nobody connects back to rework.
+Is a Repack Stock Entry safe for valuation?
It is, provided you check the target line's rate before submitting. Repack distributes the combined source valuation across the target items, so with multiple targets an unintended split silently changes your finished-goods value. With a single target — the reworked unit — the arithmetic is straightforward and the entry is safe.
Related issues you may also hit
- Work Order cancellation failing when a draft Job Card is referenced by a Stock Entry (#56046) — relevant if you cancel a wrongly-created rework Work Order.
- The same missing-override problem in subcontracting, tracked separately in #51012.
- Scrap, wastage and by-products in ERPNext BOM — for returns that cannot be reworked at all.
- How ERPNext calculates finished-goods cost — where a mis-modelled rework ends up.
Closing
The absence of a rework Work Order is a modelling gap, not a bug, and it will not be configured away. Decide deliberately whether rework deserves its own BOM or a Repack entry, keep returned stock out of the sellable warehouse, and check the incoming rate on every rework manufacture entry. Do that and the missing feature costs you a naming convention rather than a year of quietly wrong finished-goods valuation.
Returns piling up and no one trusts the finished-goods valuation?
We map your return and rework flows, design the BOM structure that costs them correctly, and set the review queue that catches the wrong Work Order inside the period.