What Is EPCIS? A Plain-English Business Guide

A product identifier tells you which thing you are holding. It doesn't tell you where that thing has been. When a retailer asks where a batch went, when a regulator asks for recall scope, or when a distributor disputes a delivery, the answer depends on a history of events, and that history usually spans several companies. EPCIS is the GS1 standard for writing that history down in a way every partner can read.

EPCIS in one paragraph

EPCIS stands for Electronic Product Code Information Services. It is the standard GS1 publishes for capturing and sharing event data: records of what happened to identified objects, "across, between and within enterprises". An event might say that a perfume bottle was given its identity on a packing line, that 24 bottles were packed into a carton, or that a pallet arrived at a distributor's warehouse.

EPCIS is not a barcode, not a database GS1 runs, and not a replacement for your ERP. It is an agreed shape for event records and an agreed way to send and ask for them. The current version is EPCIS 2.0, ratified in June 2022.

The questions every event answers

The easiest way to understand EPCIS is to imagine a short, strict diary entry. Each event is built around the same small set of questions, though not every event fills in all of them:

The "what" uses GS1 identifiers: GTIN plus serial for an individual unit, GTIN plus batch for a quantity, an SSCC for a carton or pallet. The "where" usually uses GLNs, which give partners an unambiguous way to name a site, or a specific dock door or line within it. If these identifiers are new to you, GTIN, batch, serial, SSCC and GLN explained sets them side by side.

The "why" is where EPCIS earns its keep. A record that says "serial AN7Q2X4K seen at 09:12" is a log line. A record that says "serial AN7Q2X4K was commissioned at 09:12 and is now active" is a business fact that another company can act on.

Five kinds of event

EPCIS 2.0 defines five event types. Most traceability programmes use the first two heavily and the others when a specific process calls for them.

Two of these have their own articles. A commissioning event is the ObjectEvent that brings a product's identity into use and starts its history. An aggregation event records the parent–child link between a container and its contents, which is what lets a warehouse scan one pallet label instead of every unit.

CBV: the shared dictionary

If every company described its processes in its own words, event data would be impossible to combine. One company's "despatched" is another's "shipped" and a third's "goods out". The CBV (Core Business Vocabulary) fixes that. CBV 2.0, published alongside EPCIS 2.0, defines standard values used inside events.

Two families of CBV value matter most to business readers:

• Business steps say what process was happening. Examples include commissioning, packing, shipping, receiving and decommissioning.
• Dispositions say what state the objects are in afterwards. Examples include active, in_transit, in_progress, recalled, expired and destroyed.

So a shipping event might carry business step shipping and disposition in_transit. A recall team can then ask a precise question across several partners' data, such as "show me every unit from batch L2609 whose latest disposition is not recalled", and get a meaningful answer.

A worked example: one carton, four events

Maison Ardent, a fictional perfume house, fills its Ambre Nuit eau de parfum at a contract factory. Here is a simplified history for one carton, shown in the timeline at the top of this page:

1. Commissioned. Each bottle's serialized code is printed and read back by a camera on the line. Once a bottle passes, the factory records an ObjectEvent with action ADD, business step commissioning and disposition active.
2. Aggregated. Twenty-four verified bottles go into a carton labelled with an SSCC. An AggregationEvent links the carton (the parent) to the 24 bottles (the children). Later, 40 cartons are linked to a pallet in the same way.
3. Shipped. The pallet leaves the factory. Its SSCC is scanned and an ObjectEvent with business step shipping is recorded. Because of the aggregation records, nobody needs to scan the 960 bottles inside.
4. Received. The distributor scans the pallet at its warehouse and records a receiving event at its own GLN.

Steps 1 to 3 are captured by the factory or brand; step 4 by the distributor. Put together, these events answer "where is this bottle and how did it get there?" without anyone owning the whole chain. The full sequence, including what happens when a carton is opened and re-packed, is walked through in EPCIS explained through the journey of one product. The physical side of packing units into cartons and pallets is covered in how individual products become cartons and pallets.

Notice the condition in step 1: the bottle is commissioned after the code is printed and checked. A serial that exists only in the ERP, or one the printer acknowledged but the camera never read, is not a commissioned product. Why that distinction matters is explained in why "printed" is not the same as "verified".

What changed in EPCIS 2.0

Earlier versions of EPCIS were XML-based and mainly exchanged through SOAP web services, which suited large enterprise integrations but was heavy for smaller partners and modern web tools. EPCIS 2.0 kept those options and added:

• JSON and JSON-LD syntax, alongside XML. Events can now be written in the format most web developers use every day.
• REST bindings, alongside SOAP, for capturing and querying events over ordinary web APIs.
• A "how" dimension, filled from sensor data (the standard calls the structure a SensorElement), so an event can carry readings such as temperature.
• GS1 Digital Link URIs inside event data, so the same web-style identity printed in a GS1 Digital Link QR code can appear in events.
• Certification information, and persistent disposition for states that should carry forward until they are explicitly cleared.
• AssociationEvent, the fifth event type described above.

Here is what a commissioning event for one bottle might look like in EPCIS 2.0 JSON-LD. It is simplified and illustrative: it omits the surrounding document and context declarations, and every identifier is fictional.

{
  "type": "ObjectEvent",
  "eventTime": "2026-09-14T03:42:40Z",
  "eventTimeZoneOffset": "+05:30",
  "epcList": [
    "https://id.maisonardent.example/01/09501101530003/21/AN7Q2X4K"
  ],
  "action": "ADD",
  "bizStep": "commissioning",
  "disposition": "active",
  "readPoint": { "id": "https://id.maisonardent.example/414/9501101000018/254/LINE3" },
  "bizLocation": { "id": "https://id.maisonardent.example/414/9501101000018" }
}

Read it against the table above. epcList is the what: one bottle, identified by a GS1 Digital Link URI containing its GTIN and serial. eventTime and eventTimeZoneOffset are the when. readPoint (where it was seen: line 3) and bizLocation (where it now is: the factory) are the where. bizStep and disposition are the why. A business reader never needs to write this by hand, but it helps to know the fields map directly onto plain questions.

Who holds EPCIS data

EPCIS data is captured by businesses and shared with their trading partners. The factory keeps its commissioning and packing events; the distributor keeps its receiving events; each decides who may query them. No GS1 source describes a central GS1 repository of everyone's events.

How do partners find each other's data, then? One emerging route is the resolver. A resolver connects a product identity to a set of links, and the GS1 Web Vocabulary includes link types gs1:epcis and gs1:traceability for pointing to a brand's event resources. The link says where to ask; the resource behind it still applies its own access control. What is a GS1 resolver? explains the mechanism.

EPCIS and its neighbours

EPCIS sits between systems you already have, which is a common source of confusion:

• ERP records orders, stock, batches and financial transactions. EPCIS records physical events against identified objects and makes them shareable. They overlap at the edges but do different jobs; see EPCIS vs ERP.
• Line systems (printers, cameras, line controllers) generate the physical evidence, such as a code read or a carton closed, from which commissioning and aggregation events can be created.
• Consumer scans are engagement data. A shopper opening a product page is not a shipping or receiving event, and mixing the two muddies both.
• Resolvers advertise where information about an identity can be found, including event resources. They are not where events are stored.

Where a business should start

EPCIS adoption is less about technology than about agreeing what you will record and with whom. Before choosing software, a brand usually needs answers to a few questions:

1. Which events do partners actually need? Many programmes start with commissioning, packing, shipping and receiving, and add others later.
2. At what level? Unit-level serials, batch quantities, or logistic units only. Each gives a different depth of traceability at a different cost; what is product traceability? explains how to choose.
3. What evidence creates each event? A commissioning event should rest on a verified print, an aggregation event on a validated carton closure, a shipping event on an actual despatch scan.
4. Who may see what? Detailed manufacturing history is commercially sensitive. Decide which partners can query which events before anyone asks.
5. How are mistakes corrected? Wrong events will happen. Agree how corrections are recorded rather than silently editing history.

EPCIS gives every partner the same grammar for describing what happened to a product. The value comes from the events you capture honestly, at the moment they happen, and share deliberately.