Chain Traceability with EPCIS 2.0: Partner RFP and Acceptance Guide

Chain traceability is not complete merely because one factory can search its own history. It works only when suppliers, manufacturers, logistics providers and customers exchange events under the same identifier, vocabulary, time and correction rules—and when the receiver can reproduce the trace result. This guide turns GS1 EPCIS 2.0, partner onboarding, RFP, PoC, FAT/SAT and a 24-hour exercise into practical acceptance criteria.

The conclusion: procure reproducible event exchange, not a central database

An RFP for chain traceability should not stop at “build a central database” or “search by lot.” The deliverable is the ability to receive events created across company boundaries, validate their structure and business meaning, and repeat trace-back and trace-forward queries with the expected results.

A central repository, federated repositories or a message broker are architecture choices. None removes the need to agree on six questions:

The five canonical dimensions cited by the GS1 Global Traceability Standard 2.0 are who, what, where, when and why. “How” is an additional implementation lens in this article; it is not presented as a sixth canonical GTS dimension.

A successful HTTP response and schema-valid JSON are not enough. If one partner identifies a shipment by pallet and another receives by case without a parent-child relation, if time-zone offsets disappear, if shipping means “planned” to one party and “physically dispatched” to another, or if corrections overwrite history, destination tracking will fail. Acceptance must therefore compare an expected trace set with the receiver’s result, record the differences and preserve evidence.

Internal traceability versus chain traceability

Internal traceability links receiving, storage, issue, transformation, inspection, packing and shipping within one management boundary. Chain traceability connects events across that boundary: dispatch with receipt, material input with production output, and parent logistics units with their children.

Inside one company, employees may understand that item A-100, location WH1 and status OK have specific meanings. A partner cannot infer whether its A100-R2 is the same item, whether WH1 is a warehouse or factory, or whether OK means inspection passed or releasable. Exposing an internal screen does not create interoperability.

The GS1 Global Traceability Standard 2.0 explains that each organisation manages its own traceability data and that end-to-end traceability requires access to and combination of data from multiple organisations. It is technology-neutral. This supports distributed data ownership as long as authorised events can be discovered, retrieved and combined in time.

Do not wait for a mythical “100% complete” internal system before engaging partners. A model designed entirely inside one company may use a lot granularity or reason code that cannot match the supplier’s dispatch unit. Select one product family and one chain, then design internal and inter-company events together: supplier shipping, your receiving, production input, transformation, packing, shipping, logistics handover and customer receiving.

For adjacent internal controls, see the same-language guides on 4M change management and IoT retrofit for ageing equipment.

Using GS1 EPCIS 2.0 for cross-company events

EPCIS is a GS1 standard for representing, capturing and querying visibility events. EPCIS 2.0 supports JSON/JSON-LD as well as XML, RESTful capture and query bindings, sensor observations associated with events, and interface considerations for authentication and authorisation. The EPCIS 2.0.1 specification and published artefacts include OpenAPI, JSON Schema, SHACL, JSON-LD contexts and ontologies.

These artefacts are useful in procurement and testing. Payloads can be checked against a published schema and operations can be compared with OpenAPI rather than relying only on a vendor PDF. Yet shape validation does not prove semantic correctness. Partners must still agree on when a shipping event is triggered and what each vocabulary value means.

Select the event relationship that matches the business fact

If a customer receives a pallet SSCC but cannot resolve the cases under it, trace granularity breaks. If a finished lot has no transformation relationship to its inputs, trace-back cannot reach the supplier lots. The opposite extreme—serialising everything—is not automatically correct. GTS 2.0 describes class, batch/lot and instance identification; the right level depends on objective, risk, cost and partner coordination.

Treat CBV as a shared meaning contract

Core Business Vocabulary values for business steps, dispositions and related fields should be governed as a joint contract. Define standard terms, approved extensions, mappings from partner codes, handling of unknown values, owners, versions, effective dates and retirement dates.

User-interface labels may be translated into English, Thai, Japanese or Vietnamese, but the transmitted canonical code should remain language-independent. Receivers must not guess meaning by comparing translated text.

A minimum architecture for EPCIS event exchange

The diagram shows a supplier, manufacturer, logistics provider and customer exchanging authorised events while retaining their own data. It deliberately has no central database icon. That does not reject centralisation; it shows that interoperability depends on the event contract, not repository topology.

The supplier records objects, logistics units, time, place and transaction at dispatch. The manufacturer receives the same object or a mapped unit and records discrepancies as exceptions. Manufacturing connects inputs to outputs and packing connects cases to pallets. Logistics records handover and arrival; the customer records receipt.

Trace-back starts with a suspect finished lot and moves through transformations, input materials and supplier dispatch. Trace-forward starts with a material lot and moves through finished goods, pallets, shipments and receiving destinations. Splitting, aggregation, repacking, returns and subcontract processing create branches; a “one step back, one step forward” address list is not sufficient.

Exchange identifiers in a controlled canonical form

GS1 Thailand’s traceability page describes identification with GTIN, GLN and SSCC, capture with barcode or RFID, and sharing with EPCIS or Digital Link. An RFP still needs canonical forms, check digits, URI representation, leading zeros, packaging hierarchy, reuse rules, mapping of supplier-assigned IDs and relabelling controls.

PoC data should include leading zeros, maximum lengths, mixed package levels and reused local lot names. Common spreadsheet conversion errors are more valuable in a PoC than a perfectly prepared single record.

Exchange time under one rule

eventTime is when the physical or business event occurred. recordTime or API receipt time is when a repository recorded it. They diverge after offline operation. Require a time-zone offset, define clock sources and permitted skew, and specify how delayed and unknown timestamps are handled.

Never reconstruct sequence solely from arrival order. Preserve event and record times, detect future timestamps and isolate contradictory order. Test delayed transmissions and offline-device correction explicitly.

Never hide a correction with an overwrite

Mispicks and wrong lot associations will occur. If a sender silently edits an exchanged record, partner histories diverge. Use an error declaration or an agreed reversal-and-reissue method linked to the original event. Preserve who corrected what, when, why and when the partner received it.

An identical event ID and payload can be accepted idempotently. The same ID with different content must be quarantined rather than treated as “last update wins.” FAT should replay originals and corrections and prove that every participant converges on the same effective trace state.

Onboard trading partners through six validation gates

Installing an EPCIS repository does not onboard a partner. Manage onboarding through six gates, each with entry criteria, evidence, machine checks, business review, an approver and a retest rule.

Gate 1: identifier mapping

List items, lots, serials, logistics units, locations, parties and transactions. Map both identification systems and assign issuance responsibility and lifetime. Test leading zeros, maximum lengths, package levels, identical local lot names and returnable assets.

Gate 2: vocabulary and scenarios

Place shipping, receiving, commissioning, packing and other business steps in the real workflow. Map partner-specific terms to canonical values. Define rejection or quarantine for unmappable values. A vocabulary entry needs a definition, example, counterexample, owner, version and effective date.

Gate 3: time, ordering and correction

Agree on time zones, precision, clock synchronisation, delay tolerance, future-event rejection and record-time authority. Exercise duplicates, out-of-order delivery, retrospective entry, cancellation and error correction. The pass criterion is not “no error”; it is detected error, preserved history and deterministic convergence after reprocessing.

Gate 4: schema and interface

Machine-check media types, JSON/JSON-LD, mandatory fields, enumerations, URIs, units, OpenAPI operations, pagination and queries. Test authentication, authorisation, certificate or token rotation, secret storage, rate limits, timeouts, retry and audit logs. Version product-specific extensions and namespaces alongside GS1 artefacts.

Gate 5: business scenario

Run partial shipment, over/short receipt, pallet reconfiguration, lot splitting, transformation, subcontracting, return, reshipment and correction. Freeze the expected trace set before execution and compare both trace directions automatically.

Gate 6: production and monitoring

Baseline the approved schemas, vocabulary, mappings, certificates and endpoints. Monitor rejection, quarantine age, unknown codes, timestamp outliers, partner delay, missing corrections and trace completeness—not only event volume.

Smaller partners may use a portal, CSV converter or managed gateway rather than implement EPCIS directly. Different intake channels are acceptable only if they normalise to the same identifiers, vocabulary, time and correction rules and pass the same validation.

What to require in the RFP

Separate responsibilities across the user organisation, solution provider, partners, identifier governance, infrastructure and information security. “Data quality is the customer’s responsibility” is too broad. Assign owners at capture, transformation, repository validation, reconciliation and correction approval.

Non-functional tests should model month-end shipments, recall exercises and post-outage bursts, not just average volume. Query performance must cover a material lot branching into many finished goods and destinations. Test archive retrieval, event ordering after recovery, endpoint outage, queue visibility and certificate expiry.

Use the PoC to discover mismatch

A PoC is not an attractive dashboard demonstration. Its purpose is to expose semantic mismatch and operating effort before contract award. Select one product family, two or three partners, realistic packaging, at least one transformation and one split. Use anonymised real data containing variations in units, lot names, languages and identifier lengths.

Measurable exit criteria should include:

• reach every expected input lot from a selected finished lot;
• reach every expected finished item, logistics unit and destination from a selected material lot;
• prevent event multiplication on duplicate delivery and quarantine a conflicting same-ID event;
• detect missing offsets, future time and event/record-time differences;
• quarantine unknown vocabulary instead of silently defaulting;
• update the effective trace set after correction while preserving the original;
• deny cross-partner queries and retain audit evidence; and
• enable partner staff to retry, correct and query using only the runbook.

Every PoC issue should trace into an RFP requirement, mapping, vocabulary, runbook or commercial assumption. Finding many issues is not failure; awarding a contract without finding them is the risk.

Close acceptance with FAT and SAT

FAT verifies an agreed profile and repeatable scenarios in the supplier-controlled environment. SAT uses production-like networks, authentication, masters, devices, partner connections and operators. A chain cannot be accepted solely because one company’s repository works.

FAT should freeze the EPCIS/CBV profile, extension namespaces, positive and negative payload pack, schema and semantic results, expected trace sets, duplicate/delay/order/correction/access behaviour, performance shape and open points.

SAT should prove that real barcode, RFID, PLC or gateway sources produce correct IDs and event time; ERP/WMS/MES transactions reconcile to EPCIS; partner certificates, tokens, firewall, DNS and time synchronisation work; offline retries are idempotent; quarantine is visible; translations do not change canonical codes; and quality, logistics and IT staff can investigate and approve through the runbook.

Acceptance should include completeness, semantic mismatch, unresolved quarantine, trace-set difference and missing evidence—not only the number of severe defects.

Regulatory signals: keep EPCIS, EU DPP and FDA boundaries accurate

Regulation can justify investment, but a standard is not automatically a statutory format.

EU Digital Product Passport Registry

The European Commission launched the Digital Product Passport Registry and a testing environment on 20 July 2026. Its official announcement states that businesses can register through a secure UI or API, product data remains decentralised, and the Registry provides infrastructure for unique product identifiers and associated metadata. The DPP information page explains that product-specific requirements and transition dates depend on delegated acts or other EU legislation.

It would therefore be wrong to claim that the EU centrally stores every product record, that every product is already subject to a DPP, or that EPCIS is the mandatory DPP format. The useful design signal is the combination of unique identification, registration metadata, machine-readable models, access management and distributed product data.

FDA Food Traceability Rule and the 24-hour requirement

The FDA’s current rule page identifies Critical Tracking Events and associated Key Data Elements for covered foods and entities. Required records—and, where applicable, an electronically sortable spreadsheet—must be provided within 24 hours of a request or another reasonable time agreed by FDA. The same page states that Congress directed FDA not to enforce the rule before 20 July 2028 and that FDA intends to comply. This is not a withdrawal of the rule.

In the FDA’s 2026 traceability readiness tabletop exercises, participants had to locate records for a defined product and date range and produce an electronically sortable spreadsheet within 24 hours. FDA reported that proactive supply-chain coordination, rather than any particular technology, drove the strongest results. The FDA does not thereby mandate or endorse EPCIS as the submission format.

Run a 24-hour destination-tracking exercise

Twenty-four hours may be a legal requirement for covered FDA cases, but it is not asserted here as a universal deadline for Thai companies. Use it as a readiness target after checking applicable law and customer contracts.

Start with a fixed request time, identifier, date range, required columns, file format and approver. Do not give the operating team the answer in advance.

1. Record the request and appoint an incident owner.
2. Lock item, lot, period, site and exclusions.
3. Trace back through transformations, inputs and supplier events.
4. Trace forward through products, packaging, logistics units and destinations.
5. Reconcile EPCIS events, ERP/WMS records and partner responses.
6. Produce a sortable file with controlled data types, codes and time zones.
7. Obtain quality/regulatory approval, including documented exceptions.
8. Submit securely and preserve proof of receipt within the target.

Measure scope-lock time, first result, partner response, reconciliation, file generation, approval and final submission separately. Also measure completeness, duplicates, unknown IDs, time outliers, unresolved differences, manual adjustments and delay by partner.

Trace-back can branch through mixing, rework and substitute material. Trace-forward must include repacking, transfer, returns and remaining inventory, not merely a customer name on a delivery document. Reconcile input quantities with outputs, scrap, retained samples, work in process and stock, preserving original units and conversion versions.

Five controls that often degrade after go-live

1. Unannounced master and vocabulary changes: require impact analysis, partner notice, compatibility windows and sandbox retest.
2. Expired certificates and tokens: monitor expiry, define owners and preserve event time during queued recovery.
3. A quarantine that becomes a second warehouse: track reason, owner, oldest age and reprocessing success.
4. Partner exit, merger or system replacement: govern historical access, retention, export and identifier succession.
5. Assuming one acceptance lasts forever: repeat trace, negative, correction, access and recovery tests after material changes.

Frequently asked questions about chain traceability

What is chain traceability?

It is the ability to connect trace information held by multiple organisations under common identifiers and meanings, so history, location and relationships can be followed across the supply chain. Partner contracts, permissions, onboarding and correction rules distinguish it from internal traceability.

Is internal traceability enough?

It supports internal quality investigation but cannot by itself reach supplier lots or all downstream destinations. Your shipping event and the receiver’s receipt must refer to the same object, time, place and transaction relationship.

Is EPCIS 2.0 mandatory?

Not for every company or regulation. It is a strong interoperability option offering JSON/JSON-LD, REST, shared vocabularies, validation artefacts and sensor context. Existing EDI, portals or files can remain if they are reliably normalised to the shared event model.

What is the difference between trace-forward and trace-back?

Trace-back moves from a product through processes and inputs toward suppliers. Trace-forward moves from a material or product through outputs, packaging, shipments and receiving destinations. Recall readiness requires both directions and reconciliation of split, aggregation, transformation and returns.

How can destination tracking finish within 24 hours?

Exercise the full workflow: scope, partner contact, EPCIS-to-ERP/WMS reconciliation, exception decisions, sortable export, approval and secure submission. Confirm whether 24 hours applies legally to your products and jurisdictions.

What if a partner cannot implement EPCIS?

Use a portal, CSV template, managed gateway or EDI conversion, but normalise all intake to the same identifiers, vocabulary, time and correction rules and apply the same validation gates.

How should PoC, FAT and SAT be separated?

A PoC is a pre-contract activity used to uncover semantic mismatches, technical feasibility issues and the workload imposed on trading partners. FAT then verifies the agreed profile and abnormal scenarios reproducibly in the supplier-controlled environment. SAT completes acceptance with the actual network, devices, master data, partner connections and operating staff under production-like conditions.

Summary: share a verifiable contract, not merely a database

Chain traceability succeeds when who, what, when, where, why and the implementation detail of how are exchanged under common identifier, vocabulary, time and correction rules—and when the receiver can reproduce trace-back and trace-forward results.

EPCIS 2.0 and CBV 2.0 provide a practical foundation through JSON/JSON-LD, REST, vocabulary, sensor context and published validation artefacts. They do not replace semantic agreement or prove regulatory compliance. Govern partner onboarding through gates, define RFP deliverables and ownership, expose mismatch in the PoC, then accept reproducibility through FAT/SAT and a timed exercise.

TOMAS TECH can help structure an event catalogue, EPCIS/CBV profile, partner onboarding, RFP, PoC and FAT/SAT around existing ERP, WMS and MES systems. A discussion can start before product selection or with one product family and a small partner pilot via our contact page.

Primary sources

• GS1 Global Traceability Standard 2.0
• GS1 EPCIS overview
• GS1 EPCIS Standard 2.0.1
• GS1 EPCIS / CBV artefacts
• GS1 Thailand: Traceability
• European Commission: DPP Registry now live
• European Commission: Digital Product Passport
• FDA: Food Traceability Rule
• FDA: 2026 traceability readiness exercises