Lot tracking and batch traceability: what a recall actually asks for

What is the difference between a lot, a batch, and a serial number?

A lot number groups units that were made or received together, and a batch is the same thing under a different word. A serial number identifies one single unit. An expiry date belongs to the lot, not to the product.

The distinction decides how many records you carry and how precisely you can answer a question a year from now. A pallet of 24 x 330ml cases received as one lot is a single record with a quantity against it, and every case in it is treated as interchangeable with every other. A serialised item is one record per unit, so a stockroom of two hundred units is two hundred records, each with its own location and its own history. Serialise something that did not need it and you bury the receiving team in scanning. Lot something that needed serials and you cannot answer the only question anyone will ever ask you, which is where that specific unit is now.

A lot record that is worth anything carries six things: the lot code exactly as the supplier printed it, the quantity received, the expiry or best-before date, the supplier and their delivery document number, the site it landed at, and every movement since. The last one is the part that gets skipped. A lot number stored as a text field on the product is a label. A lot number that every receipt, transfer, pick, return and write-off posts against is a record, and only the second one answers a question after the stock has left the building.

What does a recall actually require you to produce?

A recall requires two lists, drawn from one record, on the day you are asked. The forward list gives every customer and delivery note a named batch reached. The backward list gives the batch a returned unit came from, and everywhere else that batch went.

Pharmacy and medical supply run on lot plus expiry, and the reason is recall. A recall has to run in both directions off the same record. Forwards, a manufacturer names a batch, and you need every customer, order and delivery note that batch reached, including whatever is still on a shelf at Battambang · Depot and whatever left on a transfer to Kampot · Cross-dock. Backwards, a customer arrives holding a strip of tablets and a complaint, and you need the batch it came from and everywhere else that batch went. Neither direction can be assembled afterwards from delivery notes in a folder, because the folder does not know which of the lots sitting in the rack that week went into that particular order. Expiry then adds a second job that runs quietly all year: what is short-dated, and where is it sitting. That is a question about dates already recorded, and it decides whether short-dated stock goes back to the supplier in time or gets written off. An item can show plenty of cover in total and still have a quarter of that cover expiring inside a month.

The second thing a buyer or an auditor asks for is the arithmetic. Take the quantity received into a lot, subtract what shipped, what is still on hand, what was consumed in production and what was written off, and the remainder should be zero. It rarely is on the first attempt. The size of that remainder, and how long it took you to produce it, is what a mock recall is really measuring. A system that holds lots properly returns both answers from one query. A system that holds the lot number as a note on the delivery makes somebody read the folder, and the answer arrives long after the question stopped being useful.

FEFO or FIFO: which rule is your warehouse running?

You are running both, because they govern different things. FEFO is a picking rule on the floor. FIFO is a cost-flow rule in the books. They are independent of one another, so picking FEFO every day while valuing stock on weighted average is normal and defensible.

FIFO is first in, first out: the unit that arrived earliest leaves earliest. FEFO is first expired, first out: the unit with the nearest expiry date leaves earliest, whenever it arrived. Most weeks the two agree, because deliveries tend to arrive in roughly the order they were produced. They stop agreeing the moment a delivery turns up with a shorter remaining life than the pallet already in the rack, which happens when a supplier clears older stock, when a transfer comes back from a depot, and when a customer return is put away. On those days FIFO picking ships the older carton and leaves the short-dated one behind, and nobody sees the difference until it is written off.

The independence is worth stating plainly, because it is where vendors confuse buyers. The picking rule governs which physical carton the picker takes off the rack. The cost-flow rule governs which cost the accounts release when that carton is sold. They often agree, but nothing requires them to, and a finance manager who is told the two must be made to match is being sold a constraint that does not exist.

FEFO also has a prerequisite that gets glossed over: the expiry date has to be on the stock record, not only printed on the carton. If it lives on the carton alone, FEFO is one storekeeper's memory, and it holds only until that person is away. The second prerequisite is the override. A picker will sometimes have a good reason to take the later-dated pallet, so the system should permit it and record who did it, against which lot, on which order. An override with a name on it is a manageable exception. An override with no record is FEFO not running.

What changes by industry: pharmacy, food and beverage, electronics, garment?

The mechanism does not change by industry, but the key you track by does. Pharmacy and food track a lot and a date, electronics track a serial per unit, and garment tracks a roll and its dye lot. It is the same record in each case, carrying a different key and answering a different question.

Food and beverage adds a join that pharmacy distribution does not have, which is production. A run consumes several input lots and produces an output lot, and the output lot has to carry its parents. Without that link a trace stops at the factory door, and the answer to which supplier's ingredient went into the batch a customer is complaining about becomes an educated guess made from the production date. Where a line runs continuously, the practical unit is the run, with a start time, an end time, and the input lots consumed between them.

Electronics and equipment need serial numbers, because every question is about an individual unit: where it is, who bought it, whether it is inside warranty, whether it has already been repaired once. Is the unit on the RMA bench one we sold. Where does it go next: repair, replacement, return to the supplier, or scrap. A serialised return sitting in the stockroom is not sellable stock, and where the system cannot hold that distinction somebody eventually sells it to a walk-in customer. Serial capture costs more effort at receipt and at the point of sale than lot capture does, and it is the only thing that turns a warranty claim into a lookup instead of an argument between your counter staff and someone holding a broken machine. The state matters as much as the number, so a serial has to be able to sit in received, sellable, allocated, shipped, returned, under repair or written off, and picking should only ever see the sellable ones.

Garment and manufacturing inputs track the roll and the dye lot. Two rolls of the same fabric in the same colour code, dyed in different lots, are not interchangeable. Cut panels from both into one garment and the difference shows in daylight, on a finished order, after the cutting is done and the fabric cannot be recovered. The stock unit is the roll, carrying its dye lot and its remaining length, rather than a total number of metres held under one colour code, and that is the detail most systems get wrong. Cutting reserves named rolls, not a quantity. The same logic covers coil, resin batch, yarn lot and anything else where two units of identical specification behave differently in production. A system that holds only a quantity per SKU cannot express any of this, and the shortfall shows up as a rejected shipment rather than as a stock problem. The longer version of that argument is in inventory for a Cambodian garment factory.

Why does everything depend on the moment of goods receipt?

Goods receipt is the only moment when the lot number, the expiry date and the physical carton are in the same place at the same time. Everything after that is transcription, and transcription has nothing to check itself against.

All four rules depend on that one moment: the number being recorded as stock enters the building, by whoever is standing there with the delivery. Fitting a lot number to stock already in the rack is guesswork, and a serial copied off a box weeks later is a transcription with nothing to check it against. The discipline that follows is unglamorous and it is the whole job. One receipt line per lot, not one per product: if a delivery contains three lots of the same item, that is three lines with three quantities and three dates. A receiving screen that quietly lets somebody collapse them into one line is where traceability dies, months before anyone needs it.

That is also where the honesty is owed. Receiving at speed wants a scanner, and an aisle at Sihanoukville · Port wants one that keeps working when the connection drops. There is no inventory handheld we can put in your hands today. Offline scanning at goods receipt is the architecture the build is written against rather than a shipped demo, and we would rather write that sentence than show you a video. What a barcode can and cannot carry at the receiving door is set out in barcode inventory systems in Cambodia. The other half of the discipline is counting, because a count that agrees on the total quantity and disagrees on which lots are in the rack is still a failed count, which is why lot-level counting belongs in a cycle counting routine rather than in an annual shutdown.

What should you ask a vendor about traceability?

Ask for one demonstration rather than a feature list: name a lot in their system, and have them produce every customer it reached while you watch. If that needs an export to a spreadsheet, the product has a lot number field, not traceability.

• Can the system hold two lots of the same item in the same bin, with separate quantities, expiry dates and receipt dates?
• Does picking enforce FEFO by default, can it be overridden, and does the override leave a record with a name on it?
• Is the expiry date held on the stock record itself, or only printed on the carton in the rack?
• Can a production run record which input lots it consumed, so the output lot carries its parents?
• Does a serialised return come back into a non-sellable state rather than straight into on-hand stock?
• Can a stock count be entered lot by lot, rather than as one total per item?
• Can the trace report still run for a lot that has been fully shipped and now has zero on hand?

None of this is exotic. It is one record, kept honestly at the door, and referenced by every movement afterwards, which is the same discipline that makes any stock figure trustworthy in the first place. How we build that, and where lot and serial handling sits inside it, is set out on our inventory and stock control page. If the stock in your rack belongs to somebody else, the traceability obligation is contractual as well as operational, and warehouse software for a Cambodian 3PL covers what changes when the lots you are holding are your client's.

Frequently asked questions

Is a lot the same thing as a batch?

Yes, in practice. Both words mean a group of units made or received together and treated as interchangeable with each other. Manufacturing tends to say batch, distribution tends to say lot, and buyers use both in the same sentence. What matters is that one code covers one group, and that the code you store is the code the supplier actually printed on the carton.

Can we pick FEFO and still value stock on FIFO or weighted average?

Yes. FEFO is a picking rule about which physical unit leaves the rack. FIFO and weighted average are cost-flow rules about which cost the accounts release when a sale posts. They are independent by design, so picking the nearest-expiry carton every day while the books run on weighted average is a normal arrangement and does not need reconciling.

Can KHQR be used to track lots or batches?

No. KHQR is Bakong's payment standard, and the code identifies a merchant account so that a customer can pay it. It carries no SKU, no lot number, no expiry date and no quantity. Identifying a product and its lot at the receiving door is a separate job, done by the barcode the manufacturer prints on the carton, and the two have nothing to do with each other.

Do we need serial numbers, or are lot numbers enough?

Lot numbers are enough when every unit in the group is interchangeable and the question you will be asked is about the group: which customers received this batch. Serial numbers are needed when the question is about one unit: where is this machine, is it in warranty, has this one already been repaired. Serialising everything slows the receiving door down for no return, so serialise only the categories where the question is genuinely about the individual unit.

What if our supplier does not print a lot number?

Then you assign one at receipt and record what it was assigned against: the supplier, their delivery document number, the date and the quantity received. An internally assigned lot is weaker than the manufacturer's own, because it cannot be matched against a manufacturer's recall notice, but it is far stronger than nothing, since it still gives you the forward trace to your own customers. Ask the supplier for their code in writing at the same time, and put the requirement into the purchase agreement.

How far back does a trace have to reach?

Far enough to cover the shelf life of what you sell, plus whatever your buyer's contract asks of you, which is usually longer. We do not quote a period, because the number that governs you is the one written into your customer's supply agreement or the audit standard they hold you to, not a general rule. Build the record so that it does not quietly age out on its own, and the question stops being urgent.