GS1 EPCIS 2.0 was built to close that gap. This guide explains what it is, how its event-based model works, what the five event types mean, how it powers compliance with FSMA 204, EUDR, and Digital Product Passports, and how QR codes serve as the physical trigger for capturing EPCIS data at every point in the chain.
Key Takeaways
- EPCIS 2.0 is an open GS1 standard for capturing and sharing event-level supply chain data in a structured, interoperable format — ratified June 2022
- Events are structured around what, when, where, why, and how — creating a continuous, timestamped chain of custody
- Version 2.0 introduced REST APIs and JSON/JSON-LD support, replacing the older SOAP/XML-only architecture for simpler integration
- Compliance with FSMA Rule 204, EUDR, and Digital Product Passports depends on EPCIS 2.0 as the underlying data standard
- GS1 Digital Link QR codes are the primary physical data capture mechanism that triggers EPCIS events at each supply chain step
What Is GS1 EPCIS 2.0?
GS1 EPCIS (Electronic Product Code Information Services) is an open global standard for capturing and sharing event-level supply chain data across organizations. Unlike static records that describe what a product is, EPCIS describes what happened to it — timestamped, verifiable, and structured for machine-to-machine exchange.
What Version 2.0 Added
EPCIS 1.x was built on SOAP, a stateful XML-based messaging protocol designed for distributed enterprise environments. It worked, but it required significant custom integration work to connect two trading partners' systems. GS1 ratified EPCIS 2.0 in June 2022 with two major upgrades:
- JSON and JSON-LD support alongside existing XML, making events natively compatible with modern web services
- Standardised REST APIs for both data capture and querying, alongside the legacy SOAP/WSDL bindings
- GS1 Digital Link URI syntax for expressing GS1 identifiers within event data
Two EPCIS 2.0-compliant systems can now exchange supply chain data without custom integration work between them.
Where EPCIS Fits in the GS1 Ecosystem
GS1 organises its standards around three functions — Identify, Capture, Share:
- Identify — GS1 identifiers (GTIN, GLN, SSCC, SGTIN) define what product and what location is involved
- Capture — Barcodes, QR codes, and RFID tags read those identifiers in the physical world
- Share — EPCIS takes the resulting event data and makes it available across organisational boundaries
EPCIS sits entirely in the Share layer. It works alongside identifiers and barcodes, giving the event data they generate a structured path across organizational boundaries.
How GS1 EPCIS 2.0 Works: The Event Framework
In EPCIS, an event is any meaningful supply chain occurrence — manufacturing, packing, shipping, receiving, transformation — recorded along five structured dimensions. Together, these dimensions create a continuous, timestamped chain of custody that auditors and trading partners can query in full.
What: Object Identification
The "what" dimension uses GS1 identification keys to specify exactly which objects the event involves. Three levels of identification apply:
- Class level — GTIN alone (the product type, e.g., "a 500ml bottle of olive oil")
- Lot/batch level — GTIN plus batch/lot number (all units from a specific production run)
- Instance level — SGTIN or GTIN plus serial number (a single, globally unique item)
Regulatory requirements determine which level applies. FSMA Rule 204, for example, mandates lot-level tracking for foods on the FDA's Traceability List.
Where: Location Data
The "where" dimension uses Global Location Numbers (GLNs) to identify physical locations — farms, factories, warehouses, distribution centers, or sub-locations like a specific loading dock. Two fields capture this:
- readPoint — where the object was physically scanned
- bizLocation — where the object resides after the event, until a subsequent event changes it
When: Timestamps
Every EPCIS event captures a precise timestamp in UTC plus a local timezone offset. This time-stamping is what makes EPCIS data audit-ready — regulators can verify not just that an event occurred, but exactly when.
Why: Business Context
The "why" dimension is captured through two fields defined in the Core Business Vocabulary (CBV):
- bizStep — which business process was executing (e.g., "shipping," "receiving," "transformation")
- disposition — the state of the object after the event (e.g., "in_transit," "sellable_accessible")
These fields are what allow data to travel between unrelated systems and still carry consistent meaning — a shipper's "in_transit" record maps directly to a retailer's receiving workflow without custom translation.
How: Business Transaction Context
The "how" dimension links events to the business transactions that triggered them — purchase orders, invoices, return authorizations, and other document references. This is captured through the bizTransactionList field, which ties each physical event to its commercial record.
For industries like pharmaceuticals and food, this dimension closes the loop between physical traceability and financial audit trails, making EPCIS data actionable for both operations and compliance teams.
Breaking Down EPCIS 2.0 Event Types and the Core Business Vocabulary
The Five Event Types
| Event Type | What It Records | Typical Use Case |
|---|---|---|
| ObjectEvent | One or more objects observed during a business step | Shipping, receiving, commissioning |
| AggregationEvent | Objects physically grouped together (parent-child) | Cases packed onto a pallet |
| TransformationEvent | Inputs consumed to produce outputs | Food processing, manufacturing |
| AssociationEvent | Objects persistently linked to a parent or location | Component installed in an asset |
| TransactionEvent | Objects linked to a business transaction | Purchase order associated with items |
ObjectEvent is the most common by far. TransformationEvent is critical for food and pharma traceability — it's the only event type that explicitly breaks the lot chain and creates a new output lot from one or more input lots.
CBV: The Shared Language Behind EPCIS
CBV is the companion standard that defines the shared language EPCIS relies on. It includes 41 standardized bizStep codes covering every common supply chain business process, plus disposition codes defining object state. Without CBV, "shipping" in one organization's system might mean something subtly different in another's. CBV eliminates that ambiguity.
EPCIS 2.0 REST APIs
Once your vocabulary is aligned, the API layer is how events actually move between systems. The 2.0 API structure has three primary endpoints:
- /capture — asynchronous, accepts bulk event submissions
- /events — retrieves events matching specific criteria
- /queries — named queries, filtering, and subscriptions (a standing query that automatically pushes matching new events to a callback URL)
Instance/Lot Master Data (ILMD)
ILMD allows extra attributes to be embedded directly in an EPCIS event at the point of object creation — think harvest date, expiry date, and country of origin. This data is designed to be static over the object's life and travels with the event record, keeping critical facts attached to the lot from birth.
EPCIS 2.0 vs. Traditional Traceability Systems
Traditional systems — ERP, WMS, spreadsheets — answer "what do we have right now?" They capture status snapshots: inventory counts, shipment confirmations. They cannot explain how a product arrived at its current state, prove chain of custody, or link data across organizational boundaries.
EPCIS is event-driven. It captures every meaningful action as it happens, producing a continuous, verifiable product history.
The visibility gap is significant. McKinsey's supply chain research found that only 2% of surveyed companies had meaningful visibility into suppliers at the third tier and beyond.
Traditional traceability stops at Tier-1 because there's no shared standard for connecting events across organizational systems. EPCIS solves this through shared identifiers and standardized APIs, eliminating the need for bespoke bilateral data mapping agreements between trading partners.
| Dimension | Traditional Systems | GS1 EPCIS 2.0 |
|---|---|---|
| Data nature | Static snapshots | Continuous event stream |
| Visibility scope | Tier-1 only | Multi-tier, cross-organisation |
| Compliance style | Reactive audit preparation | Continuous, automated compliance |
| Integration cost | High — bespoke per trading partner | Low — standardised APIs |
GS1 EPCIS 2.0 in Practice: Regulatory Compliance
FSMA Rule 204 and Food Supply Chain Traceability
The FDA's FSMA Section 204 requires businesses that manufacture, process, pack, or hold foods on the FDA Food Traceability List to maintain records of Critical Tracking Events (CTEs) and Key Data Elements (KDEs) at lot level — and to provide that data to the FDA within 24 hours of request.
CTEs include harvesting, cooling, initial packing, shipping, receiving, and transformation. KDEs are the specific data fields required at each CTE — lot number, location, timestamp, trading partner details.
EPCIS 2.0 event types map directly onto FDA CTEs:
- ObjectEvent → harvesting, shipping, receiving observations
- TransformationEvent → food processing (input lot linked to output lot)
- AggregationEvent → packing into cases or pallets
GS1 US has published official EPCIS Recommendations for FSMA 204 Critical Tracking Events with mapping tables for each KDE. The FDA notes that EPCIS is an interoperability option — not mandated — but it's the most practical technical approach for multi-party compliance.
Practical enforcement date: July 20, 2028 (the FDA proposed a 30-month extension from the original January 2026 date and has stated it does not intend to enforce before that date).
A leafy greens example:
- Farm harvests (ObjectEvent: commissioning, batch GTIN + lot, farm GLN, timestamp)
- Packs into cases (AggregationEvent)
- Ships to distributor (ObjectEvent: shipping)
- Distributor receives (ObjectEvent: receiving)
- Processor transforms into packaged salad (TransformationEvent: input lot → output lot)
This complete event chain means a contamination source can be identified and isolated at the exact lot level — tracing a recalled product back to its origin farm in minutes rather than days.
EUDR, Digital Product Passports, and Broader Compliance
EUDR (EU Deforestation Regulation) requires that covered commodities are deforestation-free and legally produced. Operators must collect geolocation of all production plots and submit verifiable due diligence statements. Covered commodities include:
- Cattle, cocoa, coffee, palm oil, soya, rubber, and wood
Application dates: 30 December 2026 for large and medium operators; 30 June 2027 for micro and small operators.
EPCIS 2.0 connects farm-level origin events — harvest location, geolocation, date — through aggregation, processing, and export events in a continuous chain. GS1's EUDR Provisional Standard references EPCIS as one mechanism for communicating reference and verification numbers. The Wholechain Cattle Traceability project in Brazil demonstrates this in practice, using GS1 EPCIS as the framework for interoperable electronic traceability of deforestation-free cattle.
Digital Product Passports (DPPs), defined under the EU's ESPR regulation (in force July 2024), require product-specific data accessible electronically through a data carrier in open, interoperable, machine-readable formats. EPCIS serves as the event layer that continuously populates a DPP with verified lifecycle data:
- Sourcing and origin events
- Manufacturing and processing records
- Logistics and custody transfers
- End-of-life handling data
GS1's DPP Provisional Standard and GS1 Europe's DPP architecture documentation both use EPCIS as the traceability data transmission standard for DPP implementations.
How QR Codes Connect to GS1 EPCIS 2.0 Data Capture
EPCIS events don't generate themselves. They require a physical trigger — a moment when a real-world identifier is read and passed to a system that creates the event record. Barcodes, RFID tags, and QR codes are the primary AIDC (Automatic Identification and Data Capture) technologies that do this.
GS1 Digital Link QR codes are the format built specifically for this purpose. They encode GS1 identifiers — GTIN, batch/lot number, serial number, expiry date — in a web-native URI format that is both scannable by consumers and machine-parsable by supply chain systems. Traditional 1D barcodes don't have the data capacity to carry lot-level information; GS1 Digital Link QR codes do.
The GS1 Sunrise 2027 initiative is driving the global retail transition from 1D UPC barcodes to 2D QR codes. As of 2024, pilots were under way in 48 countries representing 88% of world GDP. By end of 2027, manufacturers should use them on packaging and retailers worldwide should be capable of reading them at POS.
The Scan-to-Event Connection
The practical workflow is straightforward:
- A warehouse worker scans a QR code on an inbound pallet
- The encoded SSCC identifier is extracted from the GS1 Digital Link URI
- The scanning system automatically adds the location GLN and UTC timestamp
- An EPCIS ObjectEvent (receiving) is generated and submitted to the /capture endpoint
That four-step sequence only works if the QR code on the pallet was generated correctly in the first place — with the right identifiers encoded in a valid GS1 Digital Link URI structure.
QRStuff generates Sunrise 2027-compliant GS1 Digital Link QR codes that encode a product's GTIN in the structured URI format EPCIS capture systems expect. Codes export as high-resolution SVG files for print-ready packaging, and the API supports programmatic generation at the point of packing or labeling — useful for operations that produce thousands of unique codes per shift.
Frequently Asked Questions
What are the GS1 supply chain standards for track and trace?
GS1 operates across three complementary layers: EPCIS captures visibility event data (what happened, where, when, why); GDSN synchronizes master data between trading partners; and GS1 EDI handles transactional data like orders, invoices, and dispatch advice. GS1 identifiers (GTIN, GLN, SSCC) are the globally unique IDs underpinning all three. "GS1 SHARE" refers to this sharing layer collectively, not a single product.
What is GS1 EPCIS 2.0 and how does it support traceability in the food supply chain?
EPCIS 2.0 is GS1's open standard for recording supply chain events in a structured, shareable format. In food supply chains, it maps directly onto FDA FSMA Rule 204's Critical Tracking Events and Key Data Elements — enabling lot-level tracking from harvest through transformation and delivery, with data shareable to the FDA within 24 hours upon request.
What is traceability in the food supply chain?
Food supply chain traceability is the ability to trace a product through every stage from farm to fork, including origin, processing, handling, and distribution. It relies on standardized data capture and sharing so any point in the chain can be identified quickly during a safety event or recall.
What is the FDA food traceability rule?
The FDA Food Traceability Rule (FSMA Section 204) requires businesses that manufacture, process, pack, or hold foods on the FDA's Food Traceability List to maintain lot-level records of Critical Tracking Events and Key Data Elements, and to provide that data to the FDA within 24 hours of request. Practical enforcement is expected from July 20, 2028.
What is a food safety traceability system based on blockchain and EPCIS?
EPCIS and blockchain are complementary. EPCIS defines what supply chain data to capture and how to structure it; blockchain defines how that data is stored in an immutable, tamper-resistant ledger. Some traceability platforms combine both, using EPCIS as the data standard and blockchain as the verification and storage layer.
