How to Trace a Recall Back to the Supplier

The call comes on a Tuesday afternoon. A supplier tells you one of their batches of an ingredient you buy has a problem, gives you their batch number, and asks what you did with it.

Everything that happens next was decided by records you either wrote months ago or did not. There is no clever procedure that recovers the answer afterwards. So this is two things at once: the trace itself, step by step, and the records that have to already exist for those steps to work.

Two traces, not one

The backward trace starts from a suspect finished product and asks what went into it. You use it when a customer complains or your own testing flags a batch.

The forward trace starts from a suspect delivery and asks where it ended up. That is the Tuesday phone call.

Most recalls need both. You run the forward trace from the supplier's batch number to find your affected finished lots, then trace each of those backward to check whether any other suspect input is involved. Both read the same underlying record, which is why a system that can only do one usually cannot really do either. Tracing a batch in both directions covers how that record is queried once it exists.

The worked example

A small sauce producer. The supplier says batch TP-4471 of tomato paste, delivered in June, is affected.

Step 1: find the receipt

Search your receiving records for the supplier's batch number. In the example it resolves to one delivery: 400 kg received on 12 June against invoice 88213, booked into the dry store as your own lot RM-0612-A.

This is the join most operations get wrong. The supplier speaks in their batch numbers, you speak in yours, and if the receipt did not record both, you cannot get from the phone call to your own stock without guessing. Whatever else you do, capture the supplier batch on the way in. The receiving walkthrough shows which fields those are.

Step 2: find what consumed it

List every production batch that drew from RM-0612-A. In the example there are three: two runs of a pasta sauce on 14 and 19 June, and one chilli sauce run on 21 June.

It is not enough that production recorded using 120 kg of tomato paste. It has to have recorded 120 kg from lot RM-0612-A. A system that deducts from a pooled quantity on hand loses the link here, and no amount of care later puts it back.

Step 3: follow the transformation

The 19 June run is where it gets interesting. That batch was not sold. It was an intermediate, and a second operation on 24 June consumed it into a finished jarred product under a different lot number.

If your records treat the 24 June batch as starting from scratch, the trace stops one step short and you never learn the jarred product is implicated. The finished lot has to carry the intermediate's ancestry forward. This is the most common place a trace breaks in real food and cosmetics production, because a semi-finished batch is both an output and an input and has to be recorded as both.

Step 4: find who received it

You now have four implicated finished lots. The last step turns them into a customer list: every order allocated from those specific lots, with date shipped and quantity. If an order was fulfilled against a product rather than a lot, you know the customer bought that sauce but not which batch they got, and the recall widens back out to everyone who bought it that period.

Where the four records come from

Each step above depends on something written earlier, by ordinary daily work rather than a separate traceability exercise. Receiving captures the supplier, invoice number, date, lot number and expiry, which makes step 1 a search instead of an archaeology project. Production batches consume named lots, so step 2 is a lookup. Every quantity change is written to a movement log as its own timestamped entry with the lot, location and user attached, which is what you hand an auditor when they ask you to prove the trace rather than describe it; stock movements lists the types that log is written in, and lot tracking is the wider picture of how the chain gets built.

Why scope is the whole game

There is always a defensible boundary available without traceability: everything made in the window when the suspect material could have been used. June through August, say. It is defensible because it is certainly wide enough. It is also the expensive answer.

A time-based boundary covers every batch that could have been affected; a record-based one covers the batches that were. In the example that is the difference between a quarter of production and four lots. Withdrawing product that was never affected costs the same per unit as withdrawing product that was, and buys no additional safety. That is the actual return on keeping the consumption record: not the recall itself, but how much of your production you keep selling during it.

Test it before you need it

Pick a finished lot you shipped last month and trace it back to the supplier deliveries that fed it. Time yourself. Then pick a delivery and trace it forward to customers. Retailer and certification audits often ask for this to be demonstrated within a fixed window, and the useful part is not passing it. It is finding out where your chain breaks on a quiet afternoon rather than on the Tuesday the supplier calls. In most operations the break is step 3.

For the wider picture of what this category asks of a system, and how to test a vendor claim before you buy, manufacturing traceability software sets out the four records every trace runs on.

Questions people ask