Supply chain traceability is the ability to follow the history, processing and movement of a product, material, component or batch. A useful traceability system should help an organisation answer practical questions about where something came from, what happened to it, which suppliers contributed information and where the finished product went.
These questions matter during recalls, supplier investigations, audits, sustainability reviews and product-data reporting. They also become important when an organisation needs to prove a claim rather than merely publish it.
Australia’s National Agricultural Traceability Strategy recognises traceability as an important part of market access, biosecurity, sustainability and agricultural growth. Its implementation plan covers activities led by government and industry between 2023 and 2028.
At the same time, Digital Product Passport requirements are moving from policy development towards implementation in Europe. The European Commission launched the operational DPP Registry on 20 July 2026, and product-specific requirements will be introduced progressively.
A business should not begin this work by choosing blockchain, buying labels or creating a passport page. It should begin by defining what must be traced, which decisions the data needs to support and what evidence will make that information trustworthy.
Start with the business, safety or compliance decision
The first step is to identify why traceability is needed.
A food manufacturer may need to identify which customers received an affected batch. A fashion brand may need to connect fibre composition claims with supplier declarations. A manufacturer may want to trace components through production, servicing and end-of-life processes.
These use cases require different data. A recall system may focus heavily on lot codes, quantities and distribution. A sustainability system may need material origin, certifications, test results and chain-of-custody evidence.
Write down the questions the system must answer. For example, the organisation may need to determine which finished goods contain a particular ingredient, which supplier provided it and which customers received those products.
The desired answer should also include an acceptable timeframe. A system that can eventually locate a batch after several days of manual spreadsheet work may technically contain the information, but it may not support an urgent recall or customer request.
The business should define who will use the information. Production teams, procurement staff, auditors, customers and regulators may require different views of the same underlying records.
Clear objectives prevent traceability from becoming a collection of disconnected data fields that no one knows how to use.
Set the product, supplier and lifecycle boundaries
Traceability can cover one production site, one product range or a network of suppliers and distributors.
Begin with a manageable boundary. Identify the products, materials, locations and partners that need to be included in the first stage.
The boundary should reflect the main risk or business objective. A food business may begin with high-risk ingredients and finished products. A manufacturer preparing for product-passport requirements may begin with one priority product group and its main materials.
Decide where tracing begins and ends. It may begin with a direct supplier or extend further upstream to farms, mines, processors or component manufacturers. Downstream tracing may stop at a distributor or continue through retailers, service providers, recyclers and end users.
The business should also decide which lifecycle stages matter. These may include sourcing, manufacturing, packing, shipping, installation, repair, refurbishment and disposal.
A narrow pilot can still be designed with future expansion in mind. Identifiers, event records and supplier roles should be consistent enough to support additional products or partners later.
Choose the Right Identification Level
Traceability depends on being able to identify the object being traced.
GS1 distinguishes between class-level identification, batch or lot-level identification and instance-level serialisation. Class-level identification distinguishes one type of product from another. Batch-level identification distinguishes one production group from another, while serialisation identifies each individual item.
The correct level depends on the product, risk, lifecycle and business process.
Batch identification is often suitable where products are manufactured or processed in groups. It can help a business identify all units connected with a particular production run, ingredient delivery or quality issue.
Serialisation may be more useful for high-value equipment, regulated products or items with long service lives. It allows maintenance, ownership and lifecycle events to be connected to one specific item.
More detailed identification can improve traceability precision, but it also requires more labels, scanning, storage and data management. The business should not serialise every low-risk item when batch-level identification already supports the required decision.
The identifier should remain unique and consistent. Reusing codes or allowing different sites to create conflicting formats can make records difficult to combine.
Maintain batch continuity through transformation and distribution
Global batch traceability becomes more difficult when materials are combined, split, repacked or transformed.
A manufacturer may receive ingredients in several supplier lots, combine them during production and create a new finished-product batch. The traceability record must preserve the relationship between the input lots and the output batch.
The same principle applies when a large batch is divided between packages, pallets, distribution centres or countries. Each movement should remain connected with the appropriate product and lot identifier.
GS1’s traceability standard states that transformation events should record relationships between inputs and outputs. It also recommends recording events such as production, receiving, packing, shipping and transport using consistent identifiers and data.
Without this connection, a business may know which ingredients entered a factory and which finished products left, but it may not be able to prove which ingredient lot entered a particular finished batch.
The organisation should document how new batch codes are created, who is authorised to create them and what happens when products are reworked, blended or repacked.
Testing should include reverse and forward tracing. Reverse tracing follows a finished product back to its materials and suppliers. Forward tracing identifies every product and customer affected by a particular input or batch.
Map the Events, Data and Evidence
Record critical tracking events and key information
A traceability system needs to record what happened, where it happened, when it happened and which product was involved.
GS1 describes these moments as Critical Tracking Events. Examples include receiving, producing, packing, shipping and transporting. Key Data Elements describe the important information associated with each event.
A receiving event may record the supplier, product identifier, batch number, quantity, date and receiving location. A transformation event may connect input batches with an output batch. A shipping event may record the customer, destination, dispatch date and quantity.
The business should map these events before selecting software. This reveals which data already exists, which information is missing and which teams are responsible for recording it.
Data should be captured as close as practical to the event. Reconstructing production or shipping information several weeks later increases the risk of gaps and mistakes.
Event records also need a consistent time, location and responsible party. Different sites should not use conflicting names for the same supplier, facility or process.
Standards-based systems can improve information exchange across organisations. EPCIS, for example, provides a common method for recording and sharing supply-chain event data and supports JSON, JSON-LD, REST APIs, sensor data and certification details.
Connect supplier claims with supporting documents
Traceability records show what moved through the supply chain, but they do not automatically prove every claim made about the product.
A supplier may state that a material is recycled, ethically sourced or compliant with a particular standard. The organisation should record the supporting declaration, certificate, test report or audit evidence where relevant.
The evidence should be connected with the correct supplier, product, material, facility and validity period. A general certificate should not be applied automatically to every product supplied by the organisation.
Expiry dates and document versions also need attention. A claim supported by an expired certificate may require review before the information is shared with customers or regulators.
The system should show who supplied the evidence, who reviewed it and whether any conditions or limitations apply.
This is the difference between a database containing claims and a source of trusted digital information. Trust depends on evidence, governance, review and clear responsibility, not simply on storing more data.
Supplier access should be controlled. Partners may need to upload or update information without seeing confidential records belonging to other suppliers.
Prepare for Food Safety and Product Recalls
Traceability in food has direct safety and recall implications.
FSANZ states that Australian food businesses should know where their food and inputs came from and where products were sent. Relevant records can include supplier and customer details, delivery dates, batch or lot identifiers and quantities received or supplied.
Food manufacturers, wholesale suppliers and importers must have a written recall plan. The plan needs to support the removal of unsafe food and provide details such as product names, date marks, batch codes, distribution contacts and quantities.
Food labels may also need product identification, lot information and Australian or New Zealand supplier details, depending on the applicable requirements. Commodity-specific standards can create additional traceability obligations.
Businesses should keep ingredient and packaging records as well as finished-product data. A recall may result from an undeclared allergen, packaging error or ingredient change rather than a problem with the main product itself.
This was particularly relevant in 2025, when undeclared allergens caused 38% of the 92 food recalls coordinated by FSANZ.
The traceability system should therefore connect formulation, ingredient, packaging and supplier changes with the affected production batches.
Test whether records can support a targeted recall
A written recall procedure should be tested before an actual incident.
A mock recall can begin with one ingredient batch and ask the team to identify every finished product that used it, every location holding stock and every customer who received affected units.
The test should measure how long this takes, which records are missing and whether reported quantities can be reconciled.
A broad recall may remove more products than necessary when the organisation cannot identify affected batches precisely. Better records can help limit the scope to the products connected with the actual issue.
The process should also work in the opposite direction. Starting from a finished product code, the team should be able to identify its production record, inputs, suppliers and relevant evidence.
FSANZ recommends practice recalls as a way to check whether a food recall plan works. It also expects recall plans to contain distribution information and records of the amount distributed and unaccounted for.
The test results should lead to corrective work. Missing batch links, supplier details, quantities or customer information should be assigned to an owner and resolved.
A traceability system should not be considered ready simply because data can be entered. It should be considered useful when that information can support a timely and accurate decision.
Select the Right Technical Architecture
Compare centralised and standards-based data exchange
Traceability technology can range from structured spreadsheets and enterprise systems to specialised platforms and shared networks.
A central database may be practical where one organisation controls the process and receives information from suppliers. It can provide simpler administration and a clear system owner.
More complex supply chains may involve manufacturers, logistics providers, distributors, auditors and recyclers using separate systems. In that situation, standardised identifiers and event structures can make information easier to exchange.
The GS1 Global Traceability Standard is technology-neutral. Its approach focuses on identifying traceable objects, capturing relevant information and sharing data consistently across supply-chain parties.
This means an organisation does not need to replace every existing enterprise system. It may instead establish a structured information layer that connects product identifiers, supplier records and lifecycle events from different sources.
The technical design should consider APIs, batch uploads, supplier portals and manual review. Smaller suppliers may not have sophisticated systems, so the project may need more than one method of collecting data.
Permissions are important. Commercially sensitive information should not automatically become visible to every supply-chain participant.
The architecture should also provide version history and an audit trail showing when important records were created or changed.
Decide when blockchain for traceability adds value
Blockchain can support traceability by recording transactions or integrity events across a shared ledger.
NIST has examined the use of blockchain and related technologies for manufacturing supply chain traceability, particularly where product data is exchanged among several organisations.
However, blockchain should not be selected simply because the supply chain has several participants.
The organisation should first ask who needs to share information, which parties do not fully trust one another and whether an independently verifiable event history is required.
Blockchain for traceability may be considered where several parties need to record or confirm important events without allowing one participant to alter the history unilaterally. It may also be used to preserve integrity records or evidence hashes.
This does not prove that the original data was accurate. A permanent record of an incorrect supplier declaration remains an incorrect declaration. This is an inference from the technology’s role in preserving transaction history rather than independently verifying every real-world input.
The design still needs trusted identifiers, supplier controls, evidence review and responsibility for data quality.
A conventional database may remain the better choice where one organisation controls the workflow, changes need to be corrected through normal governance and distributed consensus adds no practical value.
The technology should support the traceability objective rather than becoming the objective itself.
Prepare for Digital Product Passports and Choose a Solution
A digital product passport is a structured digital record that makes defined product information available to authorised parties.
Under the EU Ecodesign for Sustainable Products Regulation, DPPs will be introduced progressively through product-specific requirements. The European Commission’s current implementation priorities include areas such as textiles, furniture, tyres, mattresses, iron and steel, and aluminium.
The DPP Registry became operational on 20 July 2026. The registry records unique product identifiers and associated metadata, while the underlying product data remains decentralised.
A passport should not be treated as a static web page containing marketing statements. The organisation may need to connect product identity, materials, compliance information, lifecycle records, supplier evidence and access rules.
Australian exporters should identify which products may fall within current or future EU requirements. They should then determine which required data is already available and where the gaps sit.
The official term is digital product passport, although some searchers use the alternative wording product digital passport. The underlying preparation remains the same: organise reliable product data before deciding how it will be published.
DPP readiness should begin with controlled source records. A QR code or online interface cannot compensate for incomplete supplier information or unsupported claims.
Compare traceability and product-data platforms
The right solution depends on whether the organisation needs operational tracking, product-data governance, evidence management, passport publishing or a combination of these functions.
A warehouse traceability system may record receipts, production and shipments effectively but provide limited support for sustainability claims or supplier certificates.
A basic passport builder may publish a clear product page but offer little help with upstream evidence, lifecycle changes or internal approval.
When comparing platforms, ask how they identify products, batches, materials, suppliers and facilities. Examine how transformations, version changes and supporting documents are recorded.
The platform should also explain how it manages permissions, data ownership, exports, integrations and long-term access.
Ask whether it uses recognised standards or creates proprietary identifiers and structures that will be difficult to transfer later.
Blockchain capability should be assessed separately from basic traceability capability. A provider should explain which records are placed on a ledger, what remains in the main platform and how corrections or disputed information are handled.
The final selection should be based on the information and decisions the organisation needs to support, not the number of technologies listed in a sales presentation.
Know When to Contact Aleverum™
Seek support when product data is fragmented
Aleverum™ may be contacted when an organisation is preparing Digital Product Passports or needs to bring product records, supplier evidence, lifecycle information and governance workflows into a more structured environment.
Its current website describes a platform for creating and governing Digital Product Passports, connecting product information with supplier evidence, certifications, compliance documents and lifecycle records. It also describes blockchain integrity records as an available part of its broader product-data approach.
The platform may be relevant when information is currently spread across spreadsheets, shared drives, enterprise software and supplier emails.
Contact may also be useful when a business can trace the movement of a batch but cannot connect that batch with the evidence supporting material, sustainability or compliance claims.
Aleverum™ states that it does not currently claim formal registration with or a live connection to the EU Central DPP Registry. Any future registry connection, sector-specific readiness or project integration should be confirmed for the organisation’s requirements [VERIFY].
The organisation should not wait until a passport publication deadline to review its data. Supplier onboarding, evidence collection and record correction can take longer than creating the final interface.
Prepare the information needed for an initial discussion
Begin by identifying the products, markets and supply-chain stages that need to be included.
Describe how products, batches and suppliers are identified today. Provide examples of existing batch codes, product identifiers and facility records where appropriate.
Explain which systems contain product information, supplier records, compliance documents and distribution events. This may include ERP, PIM, PLM, warehouse, quality or document-management systems.
Identify the claims and evidence the organisation needs to manage. Examples may include composition, origin, recycled content, certifications, test reports and chain-of-custody documentation.
State whether the project involves internal governance, customer-facing passports, regulatory preparation or all three.
Ask Aleverum™ to confirm the suitable data model, evidence workflow, access controls, implementation scope, integration requirements and current platform availability [VERIFY].
Supply chain traceability becomes valuable when it connects identifiers, events and evidence in a form people can use. By defining the purpose, preserving batch relationships and governing supplier information before selecting technology, organisations can prepare stronger recall systems, product records and Digital Product Passports.
