Most plant heads in Gujarat have experienced this: the system shows adequate raw material, production is scheduled, and then the stores team reports a shortfall. Or the opposite — a physical count turns up stock that the ledger says does not exist. The frustration is real, but blaming the software is the wrong diagnosis. The gap between physical stock and system stock almost always traces back to a handful of process failures that repeat themselves across industries, whether the plant makes textiles, chemicals, engineering components, pharmaceuticals or agri-products.
Understanding these causes precisely is the only way to fix them.
The unit-of-measure trap
This is the single most common source of silent, accumulating error. A purchase is received in kilograms, but the BOM consumes in grams. A fabric is bought in metres, but issued in pieces that have been cut to variable lengths. A chemical is stored in drums, but consumed by weight drawn from part-drums.
When the conversion factor between purchase UOM and consumption UOM is even slightly wrong — or when staff bypass it and post quantities in whichever unit is convenient — the ledger drifts from reality with every transaction. After a few weeks, the error can be substantial enough to cause either phantom shortages or phantom surpluses.
What to enforce
- Define one primary stocking UOM per item and make it non-negotiable.
- Set conversion factors carefully at item setup, not at the time of a transaction.
- Lock out manual UOM overrides at the goods receipt and goods issue screens.
- Train stores staff to query rather than guess when they face an unfamiliar unit.
This sounds administrative, but it is foundational. No cycle count will save you if the underlying transaction units are inconsistent.
Unposted issues and informal returns
In many plants, material moves before the paperwork catches up. A machine operator draws components from the store and starts the job. The stores keeper plans to post the issue later. Shift changes, urgent work, and routine distraction mean that later sometimes never arrives.
Returns are worse. Excess material brought back from the shop floor is placed on a shelf, but the system return posting is skipped because it seems like a minor thing. Over weeks, this creates a class of stock that physically exists but is invisible to the system — and it accumulates.
The fix is procedural, not technical
- Gate the production order: no confirmation, no next step. The system should not allow a production order to be marked in progress unless the material issue is posted.
- Make return posting as simple as possible — a short form, a barcode scan, or a supervisor-level mobile approval.
- Conduct a weekly review of unposted issue slips and treat it as a stores KPI, not an afterthought.
Good inventory management software can enforce posting rules automatically, but the cultural habit of posting in real time has to be built alongside the system, not assumed.
WIP that lives in no-man's-land
Work-in-progress is the most ambiguous category in any manufacturing ledger. When raw material is issued to production, it leaves raw material stock. When a finished or semi-finished product is received into the warehouse, it enters finished goods stock. But everything in between — material sitting on the shop floor, partially processed batches, assemblies awaiting the next operation — often exists in a grey zone where neither stores nor production claims ownership.
In process industries common in Gujarat, such as dyeing units, chemical blending, and casting shops, the problem is compounded by yield variability. You issue 100 kg and expect 92 kg of output, but the actual yield on any given batch fluctuates. If these variances are not posted as they occur, the WIP account becomes a dumping ground that distorts every stock report.
Practical discipline
- Define explicit WIP locations or production orders in the system so that issued material is traceable to a specific job, not just to a generic shop-floor bin.
- Post sub-operation completions, not just final completions.
- Record scrap and yield loss at the operation where it occurs, not at the end of the order.
A manufacturing ERP with integrated production order management makes this tractable, because the system itself carries the WIP balance and prompts for variance posting at order close.
Scrap and rejection handling
Scrap is generated every day in most plants, but it is posted infrequently — often only at month-end, when someone reconciles the scrap yard weight against the ledger. Between postings, the system believes that material is still in usable stock. Reports are inflated, production gets scheduled against stock that is actually waste, and the gap widens.
Rejections from quality inspection present a similar pattern. A batch is set aside as rejected, but the system still counts it as available inventory until someone raises a formal rejection posting. In the meantime, planning tools may allocate that batch to another order.
- Assign a daily or per-shift scrap posting responsibility to a named person, not a team.
- Use a blocked or quarantine location in the system for rejected goods so they are excluded from available stock immediately on inspection failure, even before the formal write-off is processed.
- Review uncleared quarantine locations weekly.
Cycle counting versus the annual shutdown count
Many Gujarat plants still rely on a single full physical count conducted during a factory shutdown — typically at year-end or during a festive break. The problem is that a once-a-year count tells you the size of the accumulated error but gives you almost no information about where it came from or how to prevent it. You correct the ledger, breathe a sigh of relief, and the drift begins again immediately.
Cycle counting — counting a subset of SKUs continuously throughout the year — is a more effective approach for two reasons. First, it catches errors before they compound. Second, it creates a feedback loop: when you count a location and find a discrepancy, you investigate it while the transactions that caused it are still recent enough to trace.
Organising a cycle count programme
- Classify items by value and movement frequency (high-value or high-movement items should be counted more often).
- Rotate responsibility so that the person who normally manages a location is not always the one counting it.
- Record not just the quantity discrepancy but the probable cause. Over time, this data points directly at which processes need tightening.
- Do not immediately correct the ledger after every count. Investigate first. Unexplained corrections that go directly to the ledger without a root cause are a red flag.
For plants running on Odoo ERP, the cycle count module can be configured to trigger automatic count requests based on movement frequency, making the scheduling largely self-managing.
Locking the ledger and controlling backdated postings
One of the quieter contributors to inaccurate stock is the ability to post transactions with a past date. A goods receipt posted three weeks ago with today's date, or a material issue that is backdated to make a production order close cleanly — these practices make the transaction history unreliable and the period-end balance meaningless.
The discipline here is straightforward but requires management backing:
- Set a posting cutoff at the end of each period (weekly or monthly, depending on your reporting cycle).
- After the cutoff, only authorised corrections should be allowed, and each should require a written reason.
- Run a regular report of backdated postings and review it with stores and production supervisors.
This is not about penalising staff. It is about making the ledger a reliable source of truth rather than a document that gets tidied up retrospectively.
When the system configuration itself is the problem
Process discipline will take you far, but if the underlying system is configured to allow exceptions that should not exist, you will always be fighting against it. Common configuration problems include:
- Multiple locations not distinguished in the system — if all floor stock is posted to a single warehouse location, you lose the ability to trace where material actually is.
- Default quantities that staff accept without checking — systems that pre-fill issue quantities based on the BOM often have staff clicking through without verifying actual quantities drawn.
- Missing links between purchase orders and goods receipts — when receipts can be posted without referencing a PO, quantity and UOM errors slip through unchallenged.
- No alerts on negative stock — if the system allows stock to go negative silently, it is masking posting errors rather than surfacing them.
Reviewing your system configuration against these points is a productive exercise before any physical count or process retraining effort. The manufacturing industry context in Gujarat — with its mix of job work, own production, and subcontracting flows — makes correct configuration particularly important because the transaction types are more varied than in simple trading businesses.
Where to start if your figures are currently unreliable
If your stock figures are unreliable today, trying to fix everything simultaneously is a reliable way to fix nothing. A more workable sequence:
- Freeze UOM definitions and conversion factors first. This stops new errors from accumulating.
- Implement a posting cutoff, even informally, so the ledger stops being adjusted retrospectively.
- Set up a quarantine location for rejected stock so inspection failures are excluded from available stock immediately.
- Start cycle counting your top twenty SKUs by value. Investigate every discrepancy before correcting it.
- Once these habits are established, review WIP treatment and scrap posting processes.
The sequence matters because each step creates a cleaner foundation for the next one.
Talk to us about your specific situation
Stock accuracy problems in manufacturing plants are solvable, but the solution is usually a combination of system configuration and process change, not one or the other. If you would like to discuss what is causing the gap in your plant, speak with the team at KoderClub. We are based in Surat and work with manufacturers across Gujarat on precisely these problems.