A recall is a query, and you find out in an hour whether you can run it

The email arrives at twenty to ten on a Tuesday. A distributor has forwarded a photograph of the back of a pack, a printed code and a date, and one line about a smell that should not be there. Somebody in quality reads it, walks across to the production office, and asks the question the rest of the day turns on. Which batch is this, and what went into it.

That question runs in two directions, and they are not equally hard. Backwards is: for this finished batch, which raw material lots were consumed, from which suppliers, against which goods receipts. Forwards is worse, because those same lots went into other batches, and those batches left on other invoices, to other distributors, in other cities. Backwards tells you whether you have a problem. Forwards tells you how large it is, and forwards is the one the regulator and the customer both want.

Whether either direction can be answered in an hour was settled long before the email, on an ordinary afternoon when somebody decided how consumption would be recorded. Not in the recall SOP, not in the audit binder, not in the quality manual. In the recording decision, which nobody present treated as a decision about recalls at all.

Traceability is a filing habit until the day it is a query

Most plants have traceability in the sense that the paper exists. Indent slips, weighing records, the batch manufacturing record in a lever arch file, goods receipt notes with supplier lot numbers copied across by hand. That is enough for an auditor who samples one batch a year and follows it patiently with a colleague sitting next to them. It is not enough for a recall, because a recall is a join across four or five record types, performed under time pressure, usually by people who did not write the records and cannot ask the person who did.

The legal shape of the obligation has been stable for a long time. European food law has required one step back and one step forward since the early 2000s, and Indian and American regimes ask for the same relationship in their own language: for anything you received, you can say where it came from, and for anything you shipped, you can say where it went. Read literally, that is a modest ask. Read as a query you must actually run on a Tuesday morning, it is a demand that every material movement carry a lot identity at the moment it moves.

What month-end consumption destroys

Plenty of ERP installations post material consumption at period close. The system takes the output quantity, explodes the bill of materials, writes off the implied inputs, and values them at weighted average. For the ledger this is respectable. It will tell you, accurately, that four thousand two hundred kilos of a resin were consumed in November. It cannot tell you which drums, because no record was ever made of a drum. The information existed on the shop floor for the whole month. It was never absent from reality, only from the database, because the transaction was created by an accounting job rather than by a person standing at a weighing scale.

Some systems paper over this by inferring lots, usually by assuming materials were issued in the order they were received. That inference is a guess wearing the clothes of a fact, and in a recall you will be asked to defend it in front of somebody who is not inclined to be generous. If two lots of the same material sat open on the floor in the same week, and operators drew from whichever drum was nearer the line, first in first out is a story you are telling about yourself.

A batch code is either a key into your records or it is a string printed on a pack. Nothing you do after the complaint changes which one you built.

The pattern, stated plainly

What has to be captured at the moment it happens

• Issue against the batch material, lot, quantity, the batch or work order it went to, who issued it and when. Not the month. The batch.
• Receipt with supplier identity the supplier's own lot or batch number, kept as they wrote it, along with the analysis certificate reference. Renumbering to your own scheme without keeping theirs breaks the step backwards.
• Output, including the awkward output good quantity, rejects, samples pulled for QC, and anything held. A batch that produced less than it should have is where investigations start.
• Packing and coding the link between the finished lot and the physical units, shippers, cartons, pallets, whatever carries a code a customer can read back to you.
• Despatch which of those units left on which document, to which customer, on which date. This is the join that turns a quality question into a commercial boundary.

The hour, in order

The statutory paperwork is the same data, keyed a second time

There is a second cost hiding here. The despatch that the forward trace needs is the same movement that the tax paperwork needs. Delivery challans, invoices, e-way bills and the returns built from them all describe goods leaving a gate, and in most plants that description is entered twice, once for the finance team and once for the batch record. Two entries of the same event drift, and when they drift the recall boundary becomes arguable at precisely the moment you need it to be flat. Keeping one set of records under both duties is not a tidiness argument, it is what makes the forward trace defensible to somebody hostile. That is the shape we built Uloborus around, after meeting the double entry often enough to stop treating it as a local quirk.

Where a system is the wrong answer

If you run a continuous process with no meaningful lot identity, one product out of one silo, the trace is short and an application will cost you more than it returns. A whiteboard and a numbering discipline will do. The same is true if your batch count is small enough that one person genuinely holds the history, though that person is also your single point of failure and everyone in the room knows it.

There is a sharper failure mode, and we have caused it before. A system that asks operators for more capture than the shop floor can sustain will be fed fiction. Scans that get done at the end of the shift from memory, weights entered as the standard because the real one was not written down, a lot field defaulted because the drum was already empty. A narrower capture that is true beats a complete capture that is invented, so if the floor can only sustain lot at issue and lot at despatch, take those two and leave the rest alone. Fiction in a traceability record is worse than a gap, because a gap is visible.

And if your existing ERP already records issues against the work order with lot detail, you do not need new software. You need a report written once, and a rehearsal.

The rehearsal

Pick a finished batch at random from six months ago, one nobody has been thinking about. Give the quality and production teams the printed code and nothing else, and ask for the input lots, the sibling batches and the customer list. Start a clock. Do not help.

What you are measuring is not the hour. It is the number of times somebody has to leave the room, ring a supplier, or open a physical file to answer a question the system should have answered. Each of those is a place where the record was made after the event instead of during it. The complaint, when it comes, will arrive with a code on it and a customer already waiting.