Batch, Serial and Expiry Data That Survives the Trip Between Systems
Most integrations move a quantity. If you sell food, beverages, supplements, therapeutic goods, chemicals, batteries or anything with a warranty, a quantity is not enough. You need to know which batch went where, which serial number belongs to which customer, and which stock expires first, and you need that to still be true after the data has passed through four systems.
The failure is almost never in the warehouse system, which usually tracks this properly. It is at the boundaries: the order that arrives without a batch, the point of sale that captures a serial only sometimes, the return that comes back with no idea what left, and the online store that shows one number for stock that is actually spread across three expiry dates. This page is about designing those boundaries so a recall is an afternoon of work rather than a fortnight of guessing.
Realistic ROI
Four Reasons Traceability Breaks at the Boundaries
The tracking usually works inside each system. It is the handovers between them that lose the detail, and always in the same four places.
A stock level and a batch level are different things
Your warehouse system knows it holds four hundred units across three batches with three expiry dates. Your online store knows it has four hundred. That simplification is usually correct for selling and completely useless for a recall, because the store cannot tell you which of its orders drew from which batch. The design decision is where the batch is assigned: at pick time in the warehouse, which is accurate and late, or at order time, which is early and needs reservations to hold. Either can work, but it has to be decided rather than assumed, and the assignment has to travel back to the order record.
Capture is a process problem before it is a technical one
A serial number that was never scanned cannot be integrated. In practice the gap is almost always at the counter or the dispatch bench, where a person under pressure can skip the step and the sale still completes. Making capture mandatory in the workflow, giving people a scanner rather than asking them to type sixteen characters, and rejecting a dispatch that lacks required data are process decisions the integration depends on. An integration built on optional capture produces traceability that is right most of the time, which in a recall is the same as wrong.
Expiry changes what allocation means
Selling stock in the order it arrived is the ordinary approach and it is wrong for dated goods. First expired first out means the allocation logic has to consider the expiry date rather than the receipt date, and it has to apply consistently whether the order came from the online store, a wholesale customer or the shop counter. It also means the systems need to agree on minimum remaining shelf life, because a wholesale customer with a contractual requirement for a set number of days remaining will reject a delivery that a purely quantity based allocation happily sent.
Returns are where the chain usually breaks
A serialised item comes back and the question is whether it is the one that went out. Without the outbound serial linked to the order, you cannot verify warranty entitlement, you cannot detect a swapped unit, and you cannot tell whether the returned item belongs to an affected batch. The same applies to dated stock returned from a wholesale customer, which needs its remaining shelf life assessed before it goes back into sellable inventory. Designing the inbound side of traceability is as important as the outbound side and it is routinely left out of scope.
What Full Traceability Actually Requires
Six pieces. Missing any one of them leaves a gap that only becomes visible when you need the data urgently.
Capture at receipt
Batch, lot, serial and expiry recorded when goods are received, ideally from the supplier’s advance shipping notice or barcode rather than typed in. Suppliers who cannot provide structured data need a defined fallback, because a supplier record that arrives as a scanned document is a manual step that will be skipped on a busy delivery day. Getting the data in cleanly at receipt is far cheaper than reconstructing it later, and it is the point at which the whole chain either starts or does not.
Allocation by expiry
Picking and allocation follow expiry rather than receipt order, consistently across every channel, with minimum remaining shelf life enforced per customer or per channel where that matters. Wholesale customers frequently have contractual shelf life requirements and consumer channels have practical ones, and both are cheaper to enforce in the allocation logic than to handle as rejected deliveries and complaints afterwards.
Assignment carried to the order
When stock is picked, the batch or serial that was actually shipped is written back against the order line in whichever system holds the customer relationship. This is the single most commonly missing link and the one that makes recall possible, because it is what turns a question about a batch into a list of customers rather than a search through paperwork. It also has to survive partial shipments, where one order line draws from two batches.
Visibility where it is needed
The online store usually needs a simple availability number, but a wholesale portal may need expiry visibility, and the customer service team needs to see the batch on the order. Deciding what each audience sees prevents both the unhelpful extreme of exposing batch detail to consumers who cannot use it and the harmful one of hiding it from the people handling a complaint. For serialised goods, a service team lookup by serial is usually the highest value single view in the whole design.
Recall and trace queries
From a batch, produce every customer, order and location that received it, including stock still on hand and stock sitting with a third party logistics provider. From a customer complaint or a returned unit, identify the batch, the supplier and everything else that came from the same lot. Both queries need to run in minutes, and the way to be sure they will is to run them as a rehearsal before you need them rather than discovering the gaps under pressure.
Returns and warranty
A returned serial is checked against what was actually shipped so warranty entitlement is a lookup rather than a judgement call, and a returned batch has its remaining shelf life assessed before anything is made sellable again. Australian Consumer Law guarantees apply regardless of what a warranty document says, so the value of this is accurate handling and a clean record rather than a way to decline claims.
Traceability Tasks Before and After Integration
| Task | Traditional | Traced End to End | Notes |
|---|---|---|---|
| Recall a specific batch | Days of spreadsheet work | Customer list in minutes | Only possible if the shipped batch was written back to the order line at pick time. |
| Goods receipt with batch data | Typed from a delivery docket | Captured from the notice or barcode | Suppliers without structured data need a defined fallback, not an assumption. |
| Pick the right stock | Oldest received, or nearest | First expired first out | Applied consistently across every channel, with shelf life rules per customer. |
| Wholesale shelf life requirement | Checked manually, sometimes | Enforced at allocation | Cheaper than a rejected pallet and a credit note. |
| Warranty claim on a serialised item | Ask for the receipt | Serial lookup to the original order | Faster for the customer and it detects units that were never yours. |
| Stock held at a third party warehouse | Batch detail lost at the boundary | Carried both ways | The 3PL boundary is a common trace gap and needs to be in the contract. |
| Short dated stock approaching expiry | Found during a stocktake | Flagged in advance | Enough notice to discount or redirect it rather than write it off. |
| Return with no traceable origin | Restocked anyway | Quarantined and queued | Putting untraceable stock back into a sellable pool destroys the chain for everything after it. |
Where Traceability Chains Break
The batch was never written back to the order
This is the defining failure. The warehouse knows what it picked and the order record does not, so a recall question can be answered for stock on hand and not for stock already sold. Reconstructing it afterwards means correlating pick lists, dispatch records and orders by time, which is slow, uncertain and exactly what nobody has capacity for during a recall. Write the batch or serial back to the order line at pick time as a required step, and handle the partial shipment case where one line draws from two batches.
Capture was optional at the point of sale
If a sale can complete without the serial being scanned, some proportion will complete without it, and the proportion rises exactly when the shop is busiest. Make it a required field for the product types that need it, use scanning rather than keyboard entry so it is faster to comply than to skip, and report on the compliance rate weekly. A traceability design that assumes people will do an optional step reliably under pressure is not a design, it is a hope.
The third party logistics boundary loses the detail
When stock sits with an external warehouse, batch and serial data has to cross the boundary in both directions: outbound so they know what to pick and inbound so you know what they shipped. Many arrangements only pass quantities. Establish before signing whether the provider can receive, hold and report batch level detail, what their file format supports, and how quickly they can answer a trace query. Retrofitting this into an existing arrangement is a commercial negotiation as much as a technical one.
Expiry was tracked but never acted on
Recording expiry dates and then allocating stock by receipt order gives you the reporting without the benefit. Short dated stock accumulates, gets discovered at a stocktake and is written off, while newer stock ships first. Enforce first expired first out in the allocation logic, alert on stock approaching a threshold with enough lead time to act, and check that every channel uses the same rule, because one channel picking differently undermines the whole approach.
Regulated obligations were treated as a paperwork exercise
Food businesses in Australia are required to be able to trace product one step forward and one step back, and therapeutic goods carry their own record keeping and recall obligations. These are obligations on the business regardless of what your systems happen to do, and a recall conducted from paper records while the systems hold the answer is both slower and harder to defend. Work out which obligations apply to your products, then check that the systems can actually produce what they require, rather than assuming an inventory module covers it.
Nobody ever rehearsed a trace
The time to discover that batch data stops at the warehouse boundary is not the morning a supplier notifies you of a contamination. Run a rehearsal: pick a batch from six months ago and produce every customer who received it, then take a random serialised unit and produce its full history. Time both. The gaps that appear are specific and fixable, and finding them in a quiet week costs a few hours instead of a reputation.
How Yes AI Builds Traceability
A trace rehearsal before we quote
We take a real batch and a real serial number and try to trace them end to end with what you have today, then write down exactly where the chain breaks. That document usually reframes the project, because the gaps are rarely where people expect and are often narrower than feared.
Boundaries designed, not assumed
Every handover between systems is specified explicitly: what data crosses, in which direction, what happens when it is missing, and who is told. The integration runs on a managed cloud automation layer we operate, so the trace data is logged at record level and can be produced years later.
Capture that people can actually follow
We design the capture steps with the people who will do them, at the receiving dock and the counter, because a required field that adds thirty seconds to every sale will be worked around. Scanning over typing, required over optional, and a weekly compliance report so drift is visible.
Rehearsed recall, not theoretical recall
Once it is live we run the trace queries as a drill and time them, then fix whatever the drill exposes. We repeat it periodically, because a new channel or a new logistics provider can open a gap that nothing else will reveal until it matters.
From Partial Records to a Chain That Holds
Five steps. The rehearsal takes days, and a typical build is six to twelve weeks depending on how many boundaries are involved.
Rehearse a trace on what exists today
Take a real batch and a real serial and follow them from supplier to customer with current systems and records. Write down every point where the chain breaks and how long each gap takes to bridge by hand. This is the evidence the rest of the project is scoped from.
Decide where each piece of data is captured and owned
Receipt, allocation, pick, dispatch, sale and return, with one owner for each and a defined behaviour when data is missing. Includes the third party logistics boundary and what your provider can genuinely support, checked rather than assumed.
Specify the flows and the exception rules
What crosses each boundary, what happens to an unbatched receipt or an unscanned serial, whether a dispatch is blocked or flagged, and who clears the queue. Written so the warehouse manager and the quality lead can both check it before build.
Build, then test with awkward cases
Split batches across one order line, partial shipments, a return with no traceable origin, stock at an external warehouse, and a product that changes from untracked to tracked. Tested on real data because these are the cases that expose design gaps.
Drill, monitor and keep it honest
Timed recall drills after go live and periodically thereafter, capture compliance reported weekly, expiry thresholds alerting with enough lead time to act, and the design revisited whenever a channel or logistics provider changes.
Related Reading
SaaS Integration Explained
The six patterns and the decisions behind them.
Multichannel Inventory Sync
One stock pool across store, shop and marketplace.
3PL and Warehouse Integration
Stock you cannot see, and the data that has to cross.
Returns and RMA Automation
The inbound half of traceability, done properly.
Failed Integration Rescue
When the chain has already been broken for months.
Custom API Integration
When the connector you need does not exist yet.
FAQ
Find Out Whether Your Chain Actually Holds
Book a traceability review. We rehearse a real trace against your current systems, write down exactly where it breaks, and tell you what it would take to close each gap. The findings are yours either way.
All discussions held in confidence. Australian-based consultants.