Running a Lot Recall After Shipment: What a 3PL or Shipper Has to Trace First
written by Cooter:Labs
published on October 2, 2026
Introduction
A recall almost never starts in the warehouse. It starts with a phone call, a quality hold at a customer's dock, or a notice from a regulator or a supplier — and by the time it does, the lot has already left the building on three, five, or a dozen separate loads. Running a lot recall after shipment is a different problem than catching a bad lot while it still sits on your racks: the lot numbers that mattered at receiving now have to be reconciled against bills of lading, pick tickets, and consignee addresses that were never built to answer one question fast — where did lot 48217 actually go. For a 3PL, freight broker, or fleet operator moving lot-tracked freight — food and beverage, pharma inputs, auto parts, chemicals — that reconciliation is the whole job once the call comes in, and it has to happen in hours, not days.
Inside the four walls, lot tracking is usually fine: a scan at receiving, a location in the WMS, a pick confirmation at the case or pallet level. The problem starts at the dock door. Most outbound processes capture weight, piece count, and a PO or order number on the bill of lading — not the lot number that was actually picked. Once that load is on a trailer, the only system that still knows which lot went on which truck is the WMS's pick history, and nobody looks at pick history until something has already gone wrong.
Everything downstream depends on what happens at receiving and putaway. If the lot or batch number is keyed in by hand from a packing slip, or captured at the pallet level when the pallet actually holds three different lots, the trace breaks before a single unit ships. A clean setup scans the lot barcode at receipt, associates it with a specific location (not just a zone), and carries that association through every move — putaway, replenishment, and pick — so the pick confirmation records which lot, not just which SKU, left which slot. This is the same discipline behind most warehouse management automation work: the automation isn't the interesting part, the data model underneath it is.
The trigger is rarely internal. It's a customer complaint, a QA hold at a plant, or a notice from a supplier or a regulator that a specific lot or date range is affected. The first task isn't notifying anyone — it's answering a narrow question as fast as possible: which outbound shipments, on which dates, to which consignees, contained that lot. If the WMS can run that query directly, the answer takes minutes. If it can't — if the lot-to-shipment link lives in a spreadsheet someone reconciles once a quarter — the answer takes a day or more, and every hour spent finding the shipments is an hour the affected lot keeps moving further downstream, possibly into a second shipment from a consignee who re-ships.
A clean one-lot-per-pallet trace is the easy case, and it's not the common one. Mixed pallets, split cases, and cross-docked loads mean a single outbound shipment can carry several lots, and a single lot can be spread across several shipments picked on different days. The trace has to be built at the case or unit level, not the pallet level, which means the pick confirmation step has to record lot at the same granularity the recall will eventually need. Cross-docking adds another layer: freight that never gets put away still has to pick up a lot reference at the dock, or the trail ends the moment it touches the floor.
Most TMS platforms and most BOL templates have no native field for lot number — they were built around weight, pieces, and freight class, not traceability. A freight broker arranging the move usually never sees a lot number at all; it stops at the shipper's own paperwork. Closing that gap means either adding a lot or batch reference to the BOL and ASN, or keeping a reliable cross-reference between the TMS load number and the WMS pick record so the two systems can be joined on demand instead of manually, under pressure, during an actual recall. The same gap shows up on the ERP side — see how lot governance inside the ERP itself is catching lot drift before a shipment goes out rather than after.
Once the affected shipments are identified, the next job is notifying every consignee on that list, documenting that each one was reached, and finding out whether any of them already consumed, resold, or re-shipped the product — which turns a one-tier recall into a two-tier one. A 3PL running this for a client needs a record that will hold up if the client, the client's customer, or a regulator asks for it later: who was notified, when, how, and what each consignee reported back. Skipping that documentation step is usually what turns a contained recall into a drawn-out one.
Looking Ahead: Challenges and Innovations
WMS and TMS That Don't Share a Lot Field
Most 3PLs and fleet operators run their warehouse management and transportation management as two separate systems bought from two separate vendors, years apart, with no shared data model. Lot number lives in the WMS; load number and consignee live in the TMS. Joining them during a recall usually means exporting both to a spreadsheet and matching on order number or ship date by hand — a process that's slow even when it's accurate, and error-prone exactly when accuracy matters most.
One-Up-One-Back Traceability Across Multiple Clients
A 3PL running lot-tracked freight for several clients in the same building has to keep each client's one-up-one-back trace — one step back to the supplier, one step forward to the consignee — cleanly isolated, even when racking, labor, and dock schedules are shared across clients. That's a harder operational problem than it sounds: two clients can use overlapping lot numbering conventions, and a trace that accidentally crosses client lines during a real recall is a liability problem for the 3PL, not just a data-quality one. Getting this right usually means the WMS enforces client-level segmentation at the data layer, not just at the reporting layer — one of the reasons a logistics-specific ERP setup built for how a 3PL actually operates tends to hold up better here than a generic warehouse add-on.
The Clock Starts Before the Trace Is Ready
Brand owners and regulators generally expect an answer within a defined window once a recall is confirmed — often measured in hours, not business days. That clock starts the moment the issue is confirmed, not once the warehouse has finished reconciling spreadsheets. A 3PL that needs a full day to produce a shipment list isn't just slow; it's extending the window during which an unflagged shipment can keep moving, get resold, or reach an end consumer. The operational fix and the liability fix are the same fix: shrink the time between "which lot" and "which shipments."
The metaverse
The direction this is moving in is fairly concrete: more WMS and TMS vendors are exposing lot, load, and consignee data through APIs instead of locking it inside separate reporting modules, which makes it possible to join that data on demand instead of reconstructing it by hand during a recall. The practical opportunity for a 3PL or fleet operator isn't a futuristic one — it's an agentic workflow that can run the WMS-to-TMS join the moment a lot number comes in, produce the affected-shipment list, and draft the consignee notifications for a human to review and send, instead of a warehouse manager building that list in a spreadsheet under deadline pressure. None of that replaces the underlying data discipline at receiving and pick; it just removes the manual reconciliation step that currently eats most of the response time.
Conclusion
A lot recall after shipment is won or lost at receiving and pick, long before anyone picks up the phone to report a problem. The warehouses and fleets that handle it well aren't the ones with the most paperwork — they're the ones whose WMS and TMS already agree on which lot went on which truck, so the trace is a query instead of a project. If your warehouse, carrier, or TMS setup would take more than a few hours to answer "which shipments had this lot," that's worth fixing before a real recall forces the question. Cooter Labs builds this kind of system integration work directly — see our systems integration and automation work — and you can talk to us about your warehouse and TMS setup before the next recall tests it.
Share this post:
Curious what this means for your business?
Get a personalized ROI estimate, or book a free discovery workshop with our team.