How to track lot numbers and expiration dates on catch-weight inventory

A frozen seafood distributor runs three coolers behind the dock — one for whole fish, one for fillets, one for shellfish — feeding a counter trade and six vans. Every case is caught at receiving: expected weight against the scale, tare netted out, variance logged per vendor. The distributor has good habits here. What it doesn't have, for the first two years, is a real answer to a much simpler question: which lot is this case actually from, and how old is it?

Lot numbers get written on the case in marker. Expiration dates live on a sticker the vendor applies, if the vendor applies one at all. The inventory system tracks weight and quantity by SKU, not by lot, so a pick ticket says "pull 40 lb of tilapia fillets" and whoever's picking grabs whichever case is closest to the door. Most of the time that's fine. Then a supplier issues a recall on one specific lot of scallops, and the distributor discovers it has no way to answer "how much of that lot did we receive, how much did we ship, and to which customers" without physically pulling every case in the shellfish cooler and reading stickers by hand.

Why catch weight makes lot tracking harder, not easier

Ordinary lot tracking is a matching problem: this unit belongs to that lot, full stop. Catch weight breaks the clean match. A single lot received from one vendor on one day doesn't arrive as one weight — it arrives as forty cases, each one a different actual weight, all sharing the same lot number and the same expiration date. When that lot gets picked, sold, and shipped, a system that tracks weight but not lot has no way to say which of those forty cases — and therefore which weight — went to which customer. It knows 412 lb of tilapia shipped this week. It doesn't know that 90 lb of it came from the lot that's now under recall.

This is exactly the point where two things a distributor is required to get right — accurate weight-based billing and product traceability — start pulling against each other if the system only handles one. Bolt lot tracking onto a system built around SKU-and-quantity, and it usually only tracks the lot at the case level, losing the actual weight. Bolt weight tracking onto a system built around lot numbers, and the lot data often lives in a separate spreadsheet nobody updates after receiving. Either way, the distributor ends up with two records of the truth that don't talk to each other, and finds out only when a recall notice forces the question.

The recall that took four hours instead of four minutes

The scallop recall is what forced the change. The vendor's notice came in at 9 a.m. naming one lot number and a date range. By early afternoon, someone had gone case by case through the shellfish cooler, cross-referenced marker-written lot numbers against a receiving log, and pieced together which customers had already been invoiced for cases from that lot. Four hours, a printed customer list, and a round of apologetic phone calls — for a lot that, in the end, represented nine cases and about 61 lb of product. The recall itself wasn't the expensive part. Not being able to answer the question in minutes instead of hours was.

That's the moment the owner stopped treating lot and expiration data as paperwork attached to receiving and started treating it as a property of the inventory itself — carried alongside weight, not separate from it.

What actually fixes it

Capture lot number and expiration date at the same scan that captures weight. If the scale ticket and the lot label are two separate steps, one of them gets skipped under pressure. A single receiving scan that records measured weight, tare, lot number, and expiration date together means there's no version of "we weighed it but didn't log the lot" — the two facts exist as one record from the moment the case crosses the dock.

Keep weight and lot as attributes of the same unit, not two systems that reference each other by SKU. Every case, tote, or pallet needs its actual measured weight and its lot number sitting on the same inventory record, so a pick, a sale, or a transfer moves both together automatically. That's what lets the system answer "how many pounds of Lot 4471 did we ship, and to whom" without anyone reconstructing it from receiving logs.

Pick by FEFO, not FIFO, when expiration dates vary within a SKU. First-in-first-out assumes the oldest received case is the one closest to expiring, which is usually true but not always — a later delivery can carry an earlier expiration date if a vendor is clearing older stock. First-expired-first-out picks off the actual date on the case, not the date it arrived, which matters more the closer a product runs to its shelf life.

Make lot-level traceability a report, not a manual reconstruction. The test isn't whether the data exists somewhere — it's whether "show me every customer who received Lot 4471" comes back as a query, not a project. A recall notice with a lot number and a date range should be answerable in the time it takes to run a report, because that's the time a customer or a regulator is actually willing to wait.

The takeaway

If lot and expiration tracking on catch-weight inventory currently means marker on a case and a sticker from the vendor, close the gap before a recall forces it:

• Capture lot number and expiration date in the same scan as the weight, not as a separate paperwork step.
• Attach lot and expiration data directly to the weighed unit — case, tote, or pallet — not to the SKU as a whole.
• Pick by FEFO using the actual date on the case, not receiving order, whenever expiration dates vary within a lot.
• Confirm you can answer "who received this lot, and how much" as a report, not a warehouse search.
• Test the recall workflow before you need it — run a mock trace on a real lot number and time how long it takes.

This is why iotoms carries lot number and expiration date as fields on the same catch-weight record as the measured weight and vendor variance — because a recall, a shelf-life question, or a customer complaint about a specific delivery shouldn't depend on whether someone can still read the marker on a case from three weeks ago.