A supplier calls on a Tuesday morning. A single drum of pigment from batch IOR-2025-114 has tested out of spec and needs to be recalled. By lunchtime you need to know three things: which of your finished batches used it, who you shipped those batches to, and how much of it is still on your own shelves.
That sequence (ingredient batch → finished batch → customer shipment) is the definition of traceability, and it is the thing spreadsheets do worst. This post walks through how a multi-batch recall lookup is structured, what breaks when it is not, and why getting the answer in under a minute is both possible and non-negotiable.
What “multi-batch” actually means
Most manufacturing runs are not fed from a single batch of every component. You start the run on a part-used drum of pigment from batch A. Halfway through, the drum empties and the operator opens a fresh one from batch B. A finished batch has now consumed two batches of the same component. That is mid-run batch switching, and it is the rule more often than the exception in small-batch manufacturing.
Traceability systems that assume one-batch-per-component will either miss half the exposure during a recall or force the operator to split the production run into two batches on paper, creating reconciliation problems elsewhere. A proper traceability model needs to record component consumption as a list of (batch, quantity, timestamp) tuples attached to the finished batch, not a single batch reference.
The lookup, in plain English
An ingredient-first recall answers one question: “given this component batch, find everything downstream of it”. The path through the data is:
Spreadsheet-based traceability can get you to step one. It almost never survives step two, because component usage is usually recorded per run, not per batch inside a run. By step three you are cross-referencing shipment lines back to batch numbers in a separate file. Step four is a phone call to your fulfilment person.
Why spreadsheets choke on this
A production spreadsheet typically captures the run, the BOM, and the output batch number. It rarely captures which batch of which component was consumed in which quantity at which point in the run. Even when the discipline exists, the lookup is a manual VLOOKUP chain, error-prone, slow, and unauditable.
Worse: sales and production usually live in different files. Your Shopify export has customer + SKU + shipment date. Your production log has run + batch. Your goods-in log has component batches. Joining those three by hand during a live recall is how small manufacturers miss customers.
What a good recall tool does
- Captures batch consumption at the shop-floor level. When the operator opens a new drum, the system records it with a timestamp, not the end-of-day paperwork.
- Supports continuous and discrete consumption, a litre of fragrance oil used gradually vs. a single sealed-unit component are different patterns, and both need to land on the batch record correctly.
- Links shipments to batches automatically, the shipment line knows its batch number because the warehouse picked from that batch, not because someone retyped it.
- Exposes one lookup: “show me downstream of batch X”. One screen, one number in, the full tree out. Forward and backward from any node.
- Is auditable, the trail is not reconstructed each time; it is recorded as it happens.
Why the 60-second bar matters
Recalls are time-boxed by regulation and by reputation. For food, FDA 204 (the FSMA Food Traceability Rule) requires 24-hour response on key data elements for covered foods. For cosmetics, MoCRA sets similar expectations on adverse-event response. In practice, if a buyer at a large retailer calls you about a quality issue, you have the length of that phone call to sound like a company that knows where its product is.
The difference between a manufacturer that can tell you in a minute and one that needs three days is not a system difference. It is a credibility difference.
How Stokka does it
Stokka treats component batches as first-class citizens on every production run. Batch consumption is captured through the assembly flow, with quantities and timestamps recorded on every build. When a run switches batches mid-flow, the finished batch records both contributing batches with the quantities consumed against each.
That genealogy is recorded on every build in the product today. The one-screen ingredient-first recall report is in the box at launch: give it a component batch number and it will return every finished batch it touched, every customer shipment of those batches, the status of each shipment, and the remaining on-hand stock still traceable to that batch. Forward from any batch. Backward from any shipment. One lookup.
Further reading
If you are building this out from scratch, start with our guide to batch tracking for small manufacturers, then read how FDA 204 applies to SMBs if you make covered foods. For the component-side mechanics, see how to build a bill of materials properly.