You send a job worker 20 kg of raw material for a job the BOM says needs 10, because that's how the drum ships. The finished goods come back, and ERPNext records that the job consumed 20 kg — not the 10 the BOM specifies. The extra 10 kg is now baked into your finished-goods cost, even though the product never used it and the surplus is really still sitting with the supplier. The behaviour is governed by one setting, and this guide shows how to confirm you're hitting it, how to make consumption follow the BOM, and how to correct the receipts that already over-consumed.
Different subcontracting problem?
If your issue is the receipt button disappearing when you've issued within tolerance, that's a separate defect — see ERPNext subcontracting tolerance: receipt button disappears. This post is specifically about how much raw material gets consumed.
Over-consumption in subcontracting is invisible on the shop floor and loud in the costing report — by which point three months of finished goods carry a cost they never incurred. I am Manoj, ERPNext and Frappe implementation lead at Mith Tech in Bengaluru, and this is one of the more expensive subcontracting misconfigurations because nothing errors.
What actually happens
When a subcontractor finishes a job, ERPNext records the raw material consumed against the finished goods produced. How much it records depends on the backflush method — the "Backflush Raw Materials based on" setting. Set to BOM, it consumes the BOM quantity for the finished quantity produced. Set to Material Transferred for Manufacture, it consumes whatever you actually transferred to the supplier.
The behaviour reported in #45075 is the second mode surprising people: with the finished quantity at 10 and a BOM need of 10, transferring 20 leads to a consumption ratio of 20 ÷ 10 = 2 — the system consumes 2 units of raw material per finished unit instead of the 1 the BOM specifies. The extra is loaded into the finished good's cost. The expected behaviour, and what most manufacturers want, is that consumption adheres to the BOM regardless of what was transferred, with any surplus remaining as stock at the supplier.
The issue is closed without a linked fix, which is why this post treats it as a behaviour to verify and configure rather than a bug to wait out. The reader action — set backflush to BOM, keep transfers aligned to the BOM — is correct on any version, so the exact patch status doesn't change what you do.
Enter your finished quantity, BOM rate and transferred quantity, and toggle the backflush method to see exactly what consumption ERPNext posts under each.
With backflush on Material Transferred, consumption follows what you sent the job worker, not the BOM. Transferring 20 against a BOM need of 10 posts a consumption ratio of 2.00× — your finished-goods valuation absorbs raw material the product never actually used.
Models the behaviour described in frappe/erpnext #45075 (closed, no linked fix; reported on v15.47.3). Verify against your own instance and version before relying on it.
Verify on your own instance and version first
Because #45075 is closed without a documented fix, confirm the behaviour on your instance before acting on it: take one completed receipt where you transferred more than the BOM needed, and check whether consumed equals the transferred quantity or the BOM quantity. That single check tells you which mode you're in and whether this post applies to you at all.
Which backflush behaviour do you actually want
For most manufacturers the answer is BOM — but it's worth being deliberate, because there are genuine cases for the other mode.
Choose how consumption should behave for your process to see the exact setting and its trade-offs.
Pick how consumption should behave for your process.
Consuming by BOM keeps finished-goods costing honest: the product carries the material the BOM says it uses, and an over-transfer stays as your stock at the supplier, reconciled separately. Consuming by transferred quantity is only correct when the transferred amount genuinely is consumed — for instance where setup scrap or process loss legitimately lives at the supplier — and even then it raises the unit cost, so it should be a conscious choice rather than a default nobody set. The costing consequences flow straight into the numbers covered in our finished-goods costing guide.
Fix it
Copy-paste the diagnosis, the backflush setting change, the correction steps for over-consumed history, and the habits that keep transfers aligned to the BOM.
Confirm consumption is following transferred quantity rather than the BOM before you change any setting.
1. Open a completed Subcontracting Receipt where you
transferred MORE (or less) raw material than the BOM
needs for the finished quantity.
2. Check the "Supplied Items" / consumed quantities on
the receipt against:
BOM qty per FG unit × finished qty received
3. If consumed = transferred (not the BOM figure), your
backflush is set to "Material Transferred for
Manufacture" and you are seeing #45075.
4. Confirm the setting:
Manufacturing Settings → Backflush Raw Materials
based on
(and/or the Subcontracting BOM / order level, which
overrides for that order).Confirm the behaviour
Open a completed Subcontracting Receipt where you transferred more raw material than the BOM needs, and compare the consumed quantity against BOM-qty-per-unit × finished-qty-received. If consumed equals the transferred quantity rather than the BOM figure, your backflush is set to Material Transferred for Manufacture and you are seeing #45075.
Set backflush to BOM
In Manufacturing Settings, set "Backflush Raw Materials based on" to BOM. Consumption will then post the BOM quantity for the finished quantity received, and any excess transferred remains your stock in the supplier warehouse. Note any per-order override on the Subcontracting BOM, which takes precedence for that order.
Test one full cycle
Before trusting it across the register, run one subcontracting order end to end: transfer more than the BOM needs, receive the finished goods, and confirm two things — consumed equals the BOM quantity, and the excess shows as stock at the supplier warehouse. Same discipline as verifying the incoming rate on a multi-level BOM.
Correct over-consumed history
Changing the setting fixes new receipts only. For past receipts that over-consumed, quantify the excess (transferred minus BOM × finished qty), establish whether that stock is genuinely used or still at the supplier, and decide with your accountant whether to amend the affected receipts or post a stock adjustment moving the excess back. Don't just flip the setting and leave the historical over-consumption sitting in valuation.
Reconcile the supplier warehouse
Finish by reconciling the supplier warehouse to a physical count. The "Subcontracted Raw Materials To Be Transferred" report can lag component returns (#53547), so a count is the reliable truth, not the report.
When purchasing sets the transfer and costing owns the number
The person deciding how much to transfer is in purchasing or stores, and they transfer what's practical — a full drum, a minimum pack, a round number. The person who lives with the consequence is in costing, months later, staring at a finished-goods cost that's higher than the BOM implies and unable to explain why.
Neither is wrong in isolation. Transferring a full drum is reasonable; expecting the product to carry only its BOM cost is reasonable. The setting is what reconciles them, and it's usually left at whatever the implementation defaulted to, which nobody revisits. Make the backflush method a documented decision with a named owner, and give purchasing a rule: transfer to the BOM requirement for the order, and where a full pack must go, flag the excess so it's tracked as supplier stock rather than silently consumed.
Draft policy for your production and finance leads to ratify. "Backflush Raw Materials based on" is set to BOM as standard, so finished-goods consumption reflects the BOM regardless of transfer quantity. Any item requiring transferred-based consumption is documented with the reason and controlled at the order level, not by changing the global default. Raw material is transferred to the BOM requirement for the order; where a minimum pack forces an over-transfer, the excess is recorded and reconciled as stock at the supplier warehouse, never left to be consumed. The supplier warehouse is reconciled to a physical count monthly. Confirm the costing treatment of any historical over-consumption with your auditor before restating.
Consume by BOM, or by transfer
FAQ
+Why does ERPNext consume more raw material than the BOM in subcontracting?
Because "Backflush Raw Materials based on" is set to Material Transferred for Manufacture, so consumption follows what you sent the subcontractor rather than the BOM. Transfer 20 against a BOM need of 10 and it consumes 20. Setting backflush to BOM makes consumption follow the BOM regardless of transfer, which is what #45075 is about.
+How do I make subcontracting consume the BOM quantity?
In Manufacturing Settings, set "Backflush Raw Materials based on" to BOM. Consumption then posts the BOM quantity for the finished quantity received, and any excess transferred stays as your stock at the supplier warehouse rather than being consumed into the finished good. Test one full cycle before rolling it out.
+Which ERPNext version does this apply to?
It was raised on ERPNext v15.47.3 in #45075, which is closed without a linked fix — so rather than relying on a version, verify the behaviour on your own instance by comparing consumed quantity to the BOM on a receipt where you over-transferred. The backflush setting that controls it exists across v14, v15 and v16.
+What happens to my costs if I leave it consuming the transferred quantity?
Every over-transfer loads raw material into finished-goods valuation that the product never used, so your unit costs and margins are overstated and, if you run standard costing, you get a persistent unfavourable material variance. Over months it also leaves your supplier warehouse understated, because material that should be sitting there as stock was booked as consumed.
+If I change the setting, does it fix the receipts I've already posted?
No. The setting governs new receipts only. Receipts that already over-consumed keep the excess in valuation until you correct them — quantify the over-consumption, decide with your accountant whether to amend the receipts or post a stock adjustment moving the excess back to the supplier warehouse, and reconcile against a count.
+Should I ever consume by transferred quantity?
Only when the transferred material genuinely is consumed — for example where setup scrap or process loss legitimately occurs at the supplier and you want it in the unit cost. Even then it raises finished-goods cost, so it should be a deliberate, documented choice for specific items, controlled at the order level rather than as a global default.
Related issues you may also hit
- The subcontracting excess tolerance blocking receipts (our guide, tracking #45824).
- The "to-be-transferred" report not updating after component returns (#53547).
- How to set up subcontracting and job work in ERPNext — the base configuration.
- How ERPNext calculates finished-goods cost — where over-consumption lands in the unit cost.
Closing
This is a configuration decision masquerading as a bug: consumption follows whichever backflush mode is set, and the mode is usually left untouched from implementation. Set it to BOM so your products carry the cost the BOM specifies, keep transfers aligned to the order, and correct the history rather than only the setting. Then reconcile the supplier warehouse to a count, because the surplus you stop consuming has to live somewhere real.
Finished-goods costs higher than the BOM says and subcontracting is the suspect?
We check your backflush configuration, quantify what over-consumption has loaded into valuation, correct the history with your accountant, and set the transfer discipline that keeps costs honest.