EPCIS 2.0 and GS1 Digital Link for SMEs: events, a JSON-LD example and blockchain anchoring
Equipo Proovik · Sep 13, 2026 · 9 min read
EPCIS 2.0 is the GS1 standard, also published as ISO/IEC 19987, for recording and sharing traceability events: which objects, when, where and why (business step) passed through a point in the chain. Version 2.0 adds JSON-LD, a REST interface and sensor data. GS1 Digital Link is the syntax that turns a GTIN, a lot or a serial number into a web URL. Together they let two different companies describe the same movement with the same words.
This article is the technical guide of the traceability cluster. For the regulatory context (Regulation 178/2002, EUDR) start with Food traceability: Regulation 178/2002, the EUDR and how to make it verifiable; the short definition and the comparison with a classic repository are on the EPCIS 2.0 traceability page.
Why an SME should speak EPCIS
A cooperative, a roaster or a small laboratory does not need EPCIS to know what it does: it needs it so that its large customer, its certifier or the authority can understand its records without a bespoke spreadsheet. EPCIS fixes the vocabulary; what you put inside is still your information.
- Buyers increasingly demand an exchange of events, not a PDF.
- Rules with deadlines (EUDR, battery passport, pharmaceutical serialisation) ask for structured data per lot and facility; EPCIS already has a place for each.
- An EPCIS event is a small JSON document: it can be generated from a modest ERP, an exported spreadsheet or a web form.
The four dimensions and the five event types
Every EPCIS event answers four questions: what (object identifiers), when (eventTime with its UTC offset), where (readPoint, where it was read, and bizLocation, where the object sits afterwards) and why (bizStep, the business step, and disposition, the resulting state). EPCIS 2.0 adds an optional fifth dimension, how, with sensor data.
| Event type | What it describes | Example in an olive mill |
|---|---|---|
| ObjectEvent | One or more objects observed, created or retired | A lot of oil is commissioned (action ADD, bizStep commissioning) |
| AggregationEvent | Objects grouped into a container or removed from it | Twelve containers go onto a pallet (ADD); the pallet is broken down at destination (DELETE) |
| TransactionEvent | Objects linked to a business transaction | The lot is tied to a purchase order |
| TransformationEvent | Inputs consumed to produce outputs | Olives from three farms produce one lot of oil |
| AssociationEvent | An object and an asset travelling with it | A temperature logger is attached to a container |
There are only three actions: ADD, OBSERVE and DELETE. TransformationEvent carries no action because inputs are consumed and outputs appear. There are no "types" such as aggregate or disaggregate: they are the same AggregationEvent with different actions.
The vocabulary: CBV 2.0
The Core Business Vocabulary is the closed list of values for bizStep and disposition. A bizStep is always one defined by GS1 (commissioning, receiving, shipping, packing, inspecting, transporting, retail_selling...) and so is a disposition (active, in_transit, in_progress, sellable_accessible, recalled, destroyed...). If you need a step that does not fit, CBV has "other" and EPCIS allows extensions under your own prefix, but an invented value outside the vocabulary does not validate and nobody else will understand it.
Identifiers: GS1 Digital Link
A thirteen-digit GTIN printed in a barcode identifies a product class. To follow a specific lot or unit you need more: the lot (AI 10) and, where relevant, the serial number (AI 21). GS1 Digital Link writes all of that as a URL:
https://id.gs1.org/01/09506000134352identifies the product (GTIN-14 with a leading zero).https://id.gs1.org/01/09506000134352/10/L-2026-09identifies a lot.https://id.gs1.org/01/09506000134352/10/L-2026-09/21/00042identifies one unit of that lot.https://id.gs1.org/414/8412345000010identifies a facility (GLN).
The same URL serves as the identifier in the EPCIS event, as the link in a QR code and as a search key. GS1 is driving the migration from linear barcodes to 2D codes at the point of sale under its Sunrise 2027 initiative; a QR code carrying a Digital Link plays both roles. One detail that is often forgotten: the check digit. A GTIN or GLN whose last digit is miscalculated is invalid, and a serious system should reject it rather than store it.
A complete EPCIS 2.0 event
This document contains one ObjectEvent commissioning a lot of oil at a mill. It is valid JSON-LD against the GS1 schema: the context is the normative EPCIS 2.0 one, the GTIN and GLN carry correct check digits, and bizStep and disposition are CBV tokens.
{
"@context": ["https://ref.gs1.org/standards/epcis/epcis-context.jsonld"],
"type": "EPCISDocument",
"schemaVersion": "2.0",
"creationDate": "2026-09-15T08:30:00.000+02:00",
"epcisBody": {
"eventList": [
{
"type": "ObjectEvent",
"eventTime": "2026-09-15T08:12:45.000+02:00",
"eventTimeZoneOffset": "+02:00",
"epcList": ["https://id.gs1.org/01/09506000134352/10/L-2026-09"],
"action": "ADD",
"bizStep": "commissioning",
"disposition": "active",
"readPoint": {"id": "https://id.gs1.org/414/8412345000010"},
"bizLocation": {"id": "https://id.gs1.org/414/8412345000010"},
"ilmd": {"cbvmda:lotNumber": "L-2026-09", "cbvmda:itemExpirationDate": "2028-03-31"}
}
]
}
}Three details decide whether it validates: eventTimeZoneOffset is mandatory (it cannot be inferred from the server); action only accepts ADD, OBSERVE or DELETE; and the ilmd block (instance- or lot-level master data) only makes sense in events with action ADD, where the lot is born.
What anchoring events on a blockchain adds
EPCIS defines how to describe an event, not how to prove when it was written or that nobody edited it afterwards. An EPCIS repository stores a recordTime, but the system itself sets it. Anchoring adds two things:
- Chained integrity. Each event embeds the hash of the previous one. Modifying an old event forces every later one to be redone.
- A date backed by proof of work. The event hash is written in a transaction on a public network. The header of the block that includes it carries a timestamp covered by proof of work, and anyone can verify that header.
The event remains yours and remains in your repository. Only the hash goes on chain: 32 bytes that reveal no product, customer or quantity. If you later change provider or repository, the proof still holds, because it depends on neither.
How an SME gets started, in five steps
- Get your GS1 keys (company prefix, a GTIN per product, a GLN per facility). Without them you can use your own identifiers, but nobody outside your company will recognise them.
- Choose the minimum events. For most chains three are enough: lot commissioning, shipping and receiving. Add transformation if you blend lots.
- Capture the time zone in every event, even if your whole operation is in one place.
- Validate against the schema before sending. An event that fails validation is not stored; fixing it later costs more.
- Anchor and sign. Anchor the hash of each event (or of each lot) and sign with your company key, so the event says who declared it.
What the standards and the law say
EPCIS 2.0 (GS1, ratified in 2022; ISO/IEC 19987): defines the five event types, the three actions, the mandatory eventTimeZoneOffset and the JSON-LD syntax; CBV 2.0 (ISO/IEC 19988) fixes the values of bizStep and disposition. The JSON schemas and the JSON-LD context are published by GS1 in its public repository.
GS1 Digital Link: the GS1 standard that defines how to represent GS1 keys (GTIN, lot, serial, GLN, SSCC) as web URIs, accepted by EPCIS 2.0 as object and location identifiers.
Regulation (EU) 910/2014 (eIDAS), Article 41(1): an electronic time stamp cannot be denied legal effect or admissibility as evidence solely for being electronic or non-qualified. Blockchain anchoring is a non-qualified electronic time stamp: without the presumption of accuracy of Article 41(2).
Sector rules that ask for structured data: Regulation (EU) 2023/1115 (EUDR) with plot geolocation and a due diligence statement; Regulation (EU) 2023/1542 with the battery passport from 18 February 2027; Directive 2011/62/EU and Delegated Regulation (EU) 2016/161 with a unique identifier on every medicine pack since 9 February 2019. None of them requires EPCIS or blockchain; all of them require per-lot records that can be handed over and cross-checked.
How to do it with Proovik
Proovik's traceability API accepts events of all five EPCIS 2.0 types, validates them against the GS1 schema (including the check digit of GTIN, GLN and SSCC and the closed CBV vocabulary), chains them by hash, lets each actor sign them and anchors the hash on the Kaspa network, which produces about ten blocks per second; a seal is normally confirmed within seconds. Every lot can be exported as a JSON-LD EPCISDocument, searched by GTIN, lot or serial number, and verified from a public URL with a QR code. The proof is checked without Proovik using the specification on the verify page. The service is available from the traceability page.
What it proves: that the event existed on the block date and has not been altered. What it does not prove: that the event data is true, or that recording it amounts to complying with the EUDR, the battery regulation or pharmaceutical serialisation. Those rules demand specific data and filings; Proovik supplies the evidence of date and integrity for what you record.
Frequently asked questions
Do I need to be a GS1 member to use EPCIS?
To use the format, no: the standard is public. For your identifiers to be recognised outside your company you do need a GS1 company prefix, obtained from the GS1 member organisation in your country. Without it you can use your own URIs, and the event is still valid EPCIS, but it is not GS1-identified.
What is the difference between EPCIS 1.2 and 2.0?
EPCIS 1.2 used only XML and SOAP services. EPCIS 2.0 keeps XML, adds JSON and JSON-LD, a REST API, the AssociationEvent type and sensor data. A 1.2 event can be converted to 2.0; the reverse is not always possible.
Can I put the event content on the blockchain?
You can, but you should not: it is commercial and sometimes personal information, and once published it cannot be withdrawn. The right approach is to anchor the hash and keep the event in your repository. The hash is enough to prove that this exact event existed.
What if my ERP does not generate JSON-LD?
It only needs to export the fields (identifier, date with offset, place, business step). A small script or the API form itself turns them into a valid event. What matters is that the values are correct, not the tool.
Sources
- EPCIS 2.0, GS1 standard: ref.gs1.org/standards/epcis
- CBV 2.0, Core Business Vocabulary: ref.gs1.org/standards/cbv
- GS1 Digital Link: ref.gs1.org/standards/digital-link
- EPCIS 2.0 JSON schemas and JSON-LD contexts (GS1, GitHub): github.com/gs1/EPCIS
- Regulation (EU) 2023/1115 (EUDR): eur-lex.europa.eu/eli/reg/2023/1115/oj
- Regulation (EU) 2023/1542 (batteries): eur-lex.europa.eu/eli/reg/2023/1542/oj
- Delegated Regulation (EU) 2016/161 (unique identifier for medicines): eur-lex.europa.eu/eli/reg_del/2016/161/oj
- Regulation (EU) 910/2014 (eIDAS): eur-lex.europa.eu/eli/reg/2014/910/oj
Proovik team. Published 15 September 2026; last reviewed 6 September 2026.