Track and trace across the supply chain explained

Supply chain track and trace is the discipline of knowing where a product is, where it has been, and what has happened to it at each step. Done properly, it gives us a usable chain of evidence from source through manufacturing, storage, transport, delivery, and, where relevant, return, repair, resale, or recycling.

In practice, supply chain track & trace is not one screen or one barcode. It is a set of identifiers, scans, status events, and system updates that let us connect physical goods to reliable digital records. When the data model is sound and the operating process is simple enough for people to follow, track and trace becomes useful across operations, compliance, customer service, and risk control.

Track and trace is often used as one phrase, but the two parts are different.

Tracking is about the current and forward view. It answers questions such as: Where is the shipment now? Has the pallet left the distribution centre? Was the parcel delivered? Is the return in transit?

Tracing is about the backward view. It answers questions such as: Which batch of raw material went into this finished item? Which customers received products from a recalled lot? Which supplier site handled this component before assembly?

That distinction matters because the business process, the data, and the level at which we identify goods may differ. A courier parcel can be tracked with a consignment number and delivery events. A regulated or quality-sensitive product may need to be traced by GTIN, serial number, lot number, or batch number across multiple handovers.

The core idea is simple. We assign an identifier to a product, component, case, pallet, shipment, or return. At each meaningful point, someone or something captures an event against that identifier. The event records what happened, when it happened, where it happened, and who handled it. Those events update the systems that operations teams, customer service, suppliers, carriers, and compliance teams rely on.

For many businesses, the first decision is unit of traceability. Do we need visibility at item level, carton level, pallet level, or shipment level? There is no universal answer. Item-level serialisation is powerful, but it is not always necessary. If our actual business risk sits at batch level, forcing serialisation across every SKU can make the project heavier than it needs to be.

A working track and trace process starts before the first scan. It starts with identifier design.

At source, we create or capture the identifiers that will follow the goods through the chain. Depending on the process, that could include:

• SKU or internal product code
• GTIN or EAN
• Serial number for item-level identity
• Batch or lot number
• SSCC for logistics units such as pallets
• Purchase order number
• Sales order number
• Shipment or consignment reference
• Return merchandise authorisation, if we use one

Those identifiers are then attached to the physical item or handling unit through a barcode, QR code, RFID tag, NFC tag, printed label, or a digital product record. If we are working with consumer-facing identity and lifecycle data, this often overlaps with digital product passport design. Our digital product passport solutions are built around that principle, linking physical products to structured, reusable records.

Once goods move, event capture begins. A typical flow looks like this:

1. Source or manufacturing event Raw materials are received and logged. Components are issued to production. Finished goods are packed and assigned to a batch, lot, or serial range. The system records commissioning or creation events.

2. Packing and aggregation event Individual items are packed into cartons, cartons onto pallets, pallets into shipments. Aggregation matters because it lets us infer movement at lower levels when higher-level units are scanned. If a pallet SSCC is scanned at dispatch, the system can associate the movement with the cartons and items nested under it.

3. Dispatch event The warehouse confirms pick, pack, and ship. This may create an ASN, or Advance Shipping Notice, for the consignee. The transport management or warehouse management system records carrier, route, departure time, dock, and shipment references.

4. In-transit event As the goods move through hubs, cross-docks, ports, or linehaul legs, scans or telematics updates create status events such as received at hub, departed hub, customs cleared, out for delivery, or delayed.

5. Receipt event The receiving site scans the shipment, pallet, carton, or item and confirms quantity, condition, and time of receipt. If there are discrepancies, the event stream branches into exception handling.

6. Delivery event Final delivery is confirmed with time, location, recipient details, and often proof of delivery. In B2C flows, that may include photo evidence or geolocation, subject to local privacy controls.

7. Return or reverse logistics event If the product comes back, we issue a return reference, receive the item, inspect it, classify the condition, and route it to restock, repair, resale, recycling, or disposal. For businesses planning circular models, product lifecycle and resale workflows become part of the same traceability architecture.

Each scan or system update creates an event record. A good event record normally includes:

• Identifier being scanned
• Event type
• Timestamp
• Location
• Actor or system creating the event
• Quantity, where relevant
• Status or disposition
• Reference to the related order, shipment, or process step

The system then updates downstream records. Inventory changes. Customer service sees the latest status. Exceptions trigger alerts. Compliance teams can reconstruct the chain later if needed.

This can be done with handheld scanners, mobile apps, fixed readers, ERP transactions, WMS updates, carrier API feeds, and supplier portal inputs. The technology stack matters, but the process logic matters more. If the wrong identifier is scanned, or scanned at the wrong point, the best dashboard in the world will still be wrong.

Reliable visibility depends on disciplined data capture. Most stalled projects do not fail because there are too few dashboards. They fail because the underlying records are inconsistent, incomplete, or impossible to reconcile across systems.

At minimum, we need master data, transactional data, and event data.

This is the baseline reference data that should already be governed:

• Product name and internal code
• GTIN, EAN, UPC, or equivalent market identifier
• Serial number rule, if serialised
• Batch or lot structure
• Unit of measure
• Packaging hierarchy, item, inner, case, pallet
• Supplier and manufacturer IDs
• Site and warehouse location codes
• Carrier and logistics partner IDs
• Customer account and ship-to location IDs

If we are linking physical goods to richer product identity records, especially in sectors preparing for sustainability and transparency requirements, we also need clear ownership of product attributes and lifecycle records. For brand-led programmes, our guidance for brands building connected product records covers that operating model in more detail.

The exact event library depends on the supply chain, but most businesses need a controlled list such as:

• Created or commissioned
• Packed
• Aggregated
• Picked
• Shipped
• Departed site
• Arrived at hub
• Customs hold or customs release
• Received
• Put away
• Allocated
• Out for delivery
• Delivered
• Delivery failed
• Returned
• Inspected
• Reworked
• Recalled
• Destroyed or disposed

These event names should be standardised. If one site records "despatched", another records "shipped", and a carrier sends "linehaul departed", we need a mapping layer or event taxonomy so users can interpret the data consistently.

For each event, we should capture:

• What, the identifier and object type
• When, timestamp in a defined timezone format
• Where, site code, address, or geolocation where appropriate
• Who, person, supplier, carrier, or system
• What happened, event code and status
• How many, quantity and unit of measure
• Related references, order, shipment, invoice, return, work order
• Condition or exception reason, if relevant

For traceability, genealogy data is often the missing piece. We need to know parent-child relationships such as which components went into which finished item, or which cartons were on which pallet. Without those links, we can track movement, but we cannot always trace provenance or isolate impact during a recall.

Track and trace adds value at different points for different reasons.

At the front end of the chain, traceability helps us connect suppliers, materials, and production outputs. That supports quality control, root cause analysis, and supplier performance management. If a material issue appears in finished goods, we can isolate the affected lots instead of widening the problem unnecessarily.

In sectors affected by product transparency and circularity requirements, traceability also supports product identity, composition, and lifecycle records. In the EU, digital product passport requirements are emerging through product-specific legislation under the Ecodesign for Sustainable Products Regulation framework. The UK is not simply mirroring every EU rule on the same timetable, so businesses operating in both markets need to separate what is legally required in the EU from what is commercially or strategically useful in the UK.

In warehouses, accurate scan events reduce inventory uncertainty, improve put-away and picking accuracy, and shorten investigation time when stock goes missing or orders are disputed. Aggregation data also means fewer scans are needed later, because one pallet scan can update the status of everything nested beneath it.

For transport and distribution, track and trace improves handover control. We can see whether delays are happening at loading, linehaul, customs, final mile, or customer receipt. That makes service failures easier to diagnose and carrier performance easier to manage.

Customers do not only want a parcel status. They want confidence. A customer service team with access to reliable event data can answer specific questions quickly, instead of chasing the warehouse, the carrier, and the supplier in parallel.

After delivery, the same traceability foundation supports warranty, repair, returns, refurbishment, and resale. If we know the exact item, its original sale, its materials, and its lifecycle events, we can make better decisions on restocking, repair eligibility, and secondary market routing.

When a regulator, auditor, retailer, or major customer asks for evidence, we need records we can produce without rebuilding the past by hand. Depending on sector and market, that may relate to product safety, import controls, environmental claims, restricted substances, responsible sourcing, or waste obligations.

The risk-reduction benefit is practical. Better traceability shortens recall investigations, narrows the affected population, and improves confidence in what we are telling customers and authorities. It also reduces fraud opportunities where products can be substituted, diverted, or counterfeited.

Most track and trace projects do not stall because the objective is unclear. They stall because the operating reality is messier than the project plan assumed.

If product codes differ across ERP, WMS, supplier files, and carrier systems, event matching becomes unreliable. Duplicate identifiers, missing batch numbers, inconsistent units of measure, and poor packaging hierarchies create constant exceptions. Before scaling event capture, we usually need to clean and govern master data.

A traceability chain is only as strong as the weakest handover. If suppliers do not label consistently, send ASNs on time, or capture the agreed events, visibility breaks. This is often not a technology problem. It is a commercial and operational one. Supplier onboarding, contractual requirements, label standards, and escalation routes matter as much as APIs.

Many businesses already have ERP, WMS, TMS, MES, ecommerce, returns, and customer service platforms. The challenge is not finding another system. It is deciding which system owns which record, where events are created, and how updates are synchronised. Without a clear source-of-truth model, teams end up arguing over whose data is right.

If the process adds too many scans, people stop following it. If it adds too few, the event history is useless. Good process design focuses on meaningful control points. We define where identity is assigned, where aggregation changes, where custody changes, and where exceptions must be logged.

Track and trace changes frontline routines. Warehouse staff may need to scan at new points. Suppliers may need new labels. Customer service may need new workflows and exception codes. If training, SOPs, and accountability are weak, the process drifts quickly.

The safest way to start is not to model every product, every supplier, and every route at once. We get better results by narrowing scope, proving the operating model, and then expanding.

Start with the problem we are trying to solve. That could be recall readiness, inbound material traceability, delivery visibility, returns control, or preparation for product passport requirements. A vague goal such as "end-to-end visibility" is too broad to guide design decisions.

Pick one product family, one site, one lane, or one supplier group. Good pilots have enough complexity to be real, but not so much that every edge case appears at once. A high-value SKU range, a returns-heavy category, or a supplier with stable process discipline often makes a strong starting point.

Decide whether the pilot needs shipment, pallet, case, batch, or item-level visibility. Then define the minimum event set. Avoid collecting data just because it might be useful one day. Capture what is needed to answer the pilot’s business questions reliably.

We need named owners for master data, label standards, event taxonomy, supplier onboarding, integration, and exception management. Without governance, pilot decisions get revisited repeatedly and scaling becomes political.

Connect the systems that are essential for the chosen process. That may be ERP plus WMS, or ecommerce plus returns, or supplier portal plus manufacturing records. Over-integration at the start slows delivery and makes testing harder.

Use measures that reflect the original problem. Examples include scan compliance at key control points, time to investigate a discrepancy, percentage of deliveries with confirmed status, speed of recall scoping, return processing time, or reduction in manual status-chasing.

Once the pilot is stable, extend by product family, site, supplier tier, or lifecycle stage. This is also the point to connect broader product identity and transparency programmes. For businesses comparing architecture options, our guide to choosing a digital product passport system in the UK helps frame the decisions around data ownership, interoperability, and rollout priorities.

Supply chain track and trace works when we treat it as an operating model, not a reporting feature. The value comes from disciplined identifiers, sensible control points, and event data that people trust enough to act on. When we start with a clear use case and build in phases, we avoid the common trap of designing a perfect future state that never reaches the warehouse floor.