Deducting components after the fact
Backflushing means the system removes components from stock when a batch is
reported complete, working backwards from the recipe and the quantity produced.
Make 100 units, and it deducts whatever 100 units should have taken.
The alternative is recording consumption as it happens: each component issued to
the floor is booked when it is issued.
Both are legitimate. They answer different questions and they fail differently.
Why backflushing is popular
It is far less data entry. Nobody scans anything at the point of issue; one
completion entry settles the whole batch. For a short run with stable yields and
few components, the accuracy cost is small and the time saved is real.
What it hides
Backflushing assumes the recipe was followed. Whatever actually happened on the
floor, stock is deducted as if the standard quantity was used.
So the things you would want to know disappear into the assumption:
- Yield loss. If the batch consumed more than standard, the extra is not
recorded. Stock levels drift from reality until a count finds the gap, and by
then the cause is months old.
- Substitution. If an operator used a different lot because the planned one
ran short, backflushing deducts the planned lot. The genealogy is now wrong,
and it is wrong in a way that looks correct.
- Scrap. Material scrapped mid-run is invisible unless it is booked
separately.
None of these matter much when yields are stable. All of them matter when you are
trying to find out why margin moved.
Which to use
Backflush when the recipe is reliable, the run is short, and the component cost is
low enough that a percentage of drift is not worth the data entry.
Record consumption when the material is expensive, the yield varies, the batch is
long enough that substitutions happen, or you work under traceability obligations
where "which lot actually went in" has to be a fact rather than an inference.
Most operations end up doing both, backflushing packaging and consumables while
recording actives and anything lot-controlled.
In IEMSuite
Production batches consume specific component lots and record the actual
quantities used against the planned ones, so the difference between theoretical
and actual yield is visible per batch rather than at a stock count. Wastage is
booked as its own movement type instead of disappearing into the variance.
FAQ
Is backflushing bad practice?
No. It is a trade of accuracy for speed, and for the right materials it is the
correct trade. It becomes bad practice when it is used for lot-controlled
material and the resulting genealogy is treated as reliable.
Can I backflush and still have traceability?
Only if the system deducts from specific lots and you accept that it chose them by
rule rather than observation. If the planned lot was not the lot actually used,
the record will say otherwise and nothing will flag it.
Why does my stock drift even though every batch was reported?
This is the usual symptom of backflushing with unstable yields. The system removed
the standard quantity each time while the floor used more, and the difference
accumulates silently until a physical count.