For food, beverage, health, industrial and durable goods businesses

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.

Book a Traceability Review (03) 9003 0111

Realistic ROI

Both directions

Traceability has to work forwards and back

From a batch to its customers, and from a customer complaint to its batch

1 quantity, many batches

Is the mismatch most integrations ignore

A single stock number cannot answer a recall question

Hours versus weeks

Is the realistic difference a design makes

The data either exists at the boundaries or it has to be reconstructed by hand

At the point of sale

Is where capture most often fails

Because it is the one place a person can skip the step under time pressure

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.

Batch on arrival

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.

First expired first out

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.

Order knows its batch

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.

Right level, right place

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.

Both directions

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.

Verified inbound

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.

FAQ

Our warehouse system tracks batches. Why is that not enough?

Because a recall question is about customers, not about stock. The warehouse can tell you what it holds and what it picked, but unless the batch that was picked is written back against the order line in the system holding the customer relationship, you cannot go from a batch to a list of people who received it. That link is the piece most commonly missing, and reconstructing it after the fact means correlating pick lists and dispatch records against orders by timestamp, which is slow and never entirely certain. The fix is usually a small change at pick time with a large effect on what is possible afterwards.

Should we assign batches at order time or at pick time?

Pick time is more accurate because it reflects what physically left, and it is the right default for most businesses. Order time assignment is useful when a customer needs to know the batch or the remaining shelf life before dispatch, as happens with some wholesale and healthcare arrangements, but it requires reservations to hold the assignment and a rule for what happens when the reserved batch turns out to be short. What matters more than the choice is that it is made deliberately and that whichever moment is chosen, the result is written back to the order rather than staying in the warehouse system.

How do we handle serial numbers when the shop is busy?

By making compliance faster than avoidance. Scanning rather than typing, the field required for the product types that need it rather than optional, and the sale unable to complete without it. Then report the capture rate weekly by store and by person, because that is what surfaces drift before it becomes a habit. If capture is genuinely impossible for some products at the counter, it is better to accept that explicitly and record which categories are untraceable at point of sale than to pretend otherwise and discover the gap during a warranty dispute or a recall.

What if our third party logistics provider only handles quantities?

Then you have a boundary where traceability stops, and you need to know that before you need the data rather than during a recall. Ask specifically whether they can receive, store and report batch and serial detail, what their file formats support, and how quickly they can answer a trace query. Some providers can with configuration, some can at additional cost, and some genuinely cannot. If the answer is that they cannot and your products require traceability, that is a procurement decision rather than an integration problem, and it is much cheaper to discover at contract renewal than afterwards.

Does this apply to us if we sell food but do not manufacture it?

Very likely yes. Australian food businesses are generally expected to be able to trace product one step forward and one step back, meaning who supplied it and who you supplied it to, and that obligation sits with the business rather than with whoever made the product. A retailer selling to consumers has different practical requirements to a wholesaler shipping pallets, but both need supplier and batch records at receipt. The sensible step is to confirm which obligations apply to your specific products and business type, then check whether your systems can actually produce what those obligations require.

How much of this can we do without changing systems?

Often more than you expect. Most modern inventory and warehouse systems already track batches and serials and the capability is simply not switched on or not carried across the boundaries. The trace rehearsal is what tells you: if the data exists in each system and is only lost in the handovers, the work is integration and process rather than replacement. If a core system genuinely cannot hold a batch at all, that is a different conversation, and we would rather establish which situation you are in during a short review than assume either answer.

How often should we rehearse a recall?

At least annually, and additionally whenever something structural changes: a new sales channel, a new logistics provider, a new supplier who reports differently, or a system upgrade. The drill is simple. Pick a batch from several months ago, produce every customer and location that received it, and time it. Then take a returned or randomly selected serialised unit and produce its full history. What makes the exercise worthwhile is that the gaps it finds are always specific and usually small, which means they are fixable in a quiet week rather than during the week you would otherwise discover them.

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.