Why recorded stock is not actual stock

The gap always exists; the question is its size

There is no warehouse where recorded and actual stock agree at every moment. A gap is normal. The problem starts when nobody knows how big it is, so every decision is taken on the quiet assumption that the program might be lying.

• Goods arrived on Tuesday; the receipt was entered on Thursday.
• Issued from the warehouse immediately, written off in the system at the end of the week.
• Something was returned, broken, taken as a sample or consumed internally, and none of it was recorded.
• Picking swapped two similar codes.
• Bought in boxes, stored in pieces, sold by the metre.

The cost of that gap is rarely calculated and easy to see: one lost order because you said there was none when there was, or one unnecessary purchase of something you already had. Usually both together cost more than the system that would have prevented them. It gets more expensive again once the production schedule starts depending on those numbers.

The cause is the moment of entry, not the program

This is the one sentence from the whole guide worth remembering: the record has to be created where the physical event happens, at the moment it happens.

If the forklift driver writes it on paper and somebody types it up in the evening, your stock is wrong all day and nobody knows by how much. If it is typed up the next morning for yesterday, it is wrong until then. No program can repair data that arrives late, because lateness is not a processing error but a process one.

The practical consequence surprises many people: a cheap phone or barcode scanner in the hands of someone in the warehouse is worth more than a better program in the office. Only once entry happens at the point of the event does the rest of the system mean anything.

The item master is the foundation, and it is usually a mess

Before any system, one rule has to hold: one item, one code. In practice the opposite is almost always what you find.

• The same item is held under three codes, because it arrived from three suppliers.
• The code carries meaning, so when the meaning changes, the code lies.
• The unit of measure differs between purchase, storage and sale, and the relationship between them is written down nowhere.
• An item is not distinguished from its packaging, so a box and a piece are treated as the same thing.

ITEM
  internal code    (never changes)
  name
  base unit        (what stock is held in)

UNITS
  purchase → ratio to base    (box = 24 pcs)
  sales    → ratio to base    (pack = 6 pcs)

LINKS
  supplier codes → same internal code
  barcode per packaging level

Until this exists, every stock report is guesswork with decimal places. Cleaning up the item master is dull work nobody wants to pay for, and without it everything else is built on sand.

Locations: when they help and when they are a burden

Tracking locations inside the warehouse is not always useful. In a small warehouse where everyone knows where things are, locations are pure extra work that people will stop doing within a month.

They earn their keep when finding goods takes time, when several people pick so the knowledge cannot live in one head, when there are many similar items, or when the order of issue matters.

If you are introducing them, start with zones rather than exact shelves. Precision you cannot maintain is worse than a rough split everyone respects, because a wrong location creates distrust in the whole system.

Batches and expiry dates cannot be added later

If you handle food, chemicals, pharmaceuticals or anything with an expiry date or a traceability obligation, batch tracking is not an extra feature but part of the data model.

The reason is technical, the consequence commercial: a system that records only quantity per item cannot afterwards answer which batch went to which customer. That fact is not missing because the program does not display it, but because it was never recorded.

So this is one of the few questions to answer before the first line of code is written. If there is even a modest chance traceability will be needed, it is cheaper to build it in now.

An annual count is too late

The annual stocktake is a legal obligation and will happen anyway, but as a management tool it is close to worthless. You discover the gap once a year, when it is at its largest, and by then nobody can explain where it came from.

Continuous counting in small amounts is far more useful. Instead of stopping the whole warehouse once, a small set of items is counted every week. The discrepancy then shows up while the cause is still fresh and somebody can still remember what happened.

A workable schedule: count the fastest-moving items monthly and the rest less often. A few months of that usually shows that most of the gap comes from two or three processes rather than from the whole warehouse.

When you need a system, and when a spreadsheet still does

A spreadsheet is a perfectly correct tool if you have a small number of items, one person running the warehouse, and a volume that is easy to follow. In that case introducing a system brings cost and resistance, and does not bring accuracy.

A system starts to pay when several people touch stock at once, when sales cannot answer a customer without walking to the warehouse, when you order what you already have, or when the discrepancy at the annual count passes an amount nobody wants to explain any more.

And once more, because this is where the biggest mistake is made: do not start by choosing a program. Start by making the record happen in the warehouse, at the moment of the event. Often it then turns out you need a much smaller system than you thought.