When a traceability project starts, someone usually asks: "Doesn't our ERP already do this?" It's a fair question. The ERP knows what was produced, which batches exist and what was shipped to whom. But an ERP and EPCIS are built to answer different questions, and confusing them leads to gaps in both.
Two different kinds of record
An ERP (enterprise resource planning system) is a company's transactional backbone. It records commercial and planning facts: a sales order was placed, a production order was released, 5,000 units of batch L2609 were booked into stock, an invoice was raised. It is designed to run one company's operations and accounts.
EPCIS is a GS1 standard for recording and sharing physical events about identified objects: a specific bottle was commissioned on line 3 at 09:14; a carton with a particular SSCC was packed with 24 named bottles; a pallet was received at a distributor's site. It is designed so that events can travel between companies and still mean the same thing.
A simple way to hold the difference: the ERP records what the business intended and transacted; EPCIS records what physically happened to identified things, in a form partners can share. The EPCIS business guide covers the event model itself.
Responsibilities side by side
| Question | ERP | EPCIS |
|---|---|---|
| Main purpose | Run the business: plan, buy, make, sell, account | Record and share visibility events about identified objects |
| Typical unit of record | Orders, batches, stock quantities, invoices | Events against GTIN + serial, batch quantities, SSCCs |
| Scope | Usually one company | Designed to cross company boundaries |
| Time | When a transaction was posted | When the event physically happened, with time zone |
| Location | Plants, storage locations in internal codes | Read points and business locations, often GLNs |
| Vocabulary | The company's own configuration | Shared CBV values such as shipping or in_transit |
| Standard format | Vendor-specific | GS1 standard (EPCIS 2.0, with JSON-LD and XML) |
| Example question | "How many units of L2609 do we have in stock?" | "Which pallets carried units of L2609, and where were they last received?" |
| Who can query | Internal users | Internal users and authorised trading partners |
The two overlap at the edges. Both may know about batches and shipments. The difference is granularity and audience: the ERP knows that a delivery of 960 units left; EPCIS can say which 960 serials, in which cartons, on which pallet, as recorded by the scanners that saw them.
Where the two meet
The interesting design work happens at the hand-off points. Take Volta Cables, a fictional cable manufacturer that serializes each reel:
- Serial allocation. Volta's ERP releases a production order and allocates a range of serial numbers for it. This is planning: no reel has been marked yet. What happens after an ERP creates a serial number? follows those serials to the line.
- Commissioning on the line. Line systems print each serial, read it back and confirm it. Only then is a commissioning event recorded. The ERP plan and the line's reality can now differ: some serials were rejected, some never printed.
- Reporting back. The line reports actual output to the ERP: how many reels of which batch were good, and which serials were consumed or voided. The ERP updates stock; the event history records what physically happened.
- Packing. Reels are packed onto pallets and aggregation events link each pallet SSCC to its reels. The ERP may only need to know that a pallet of 40 reels of a given batch exists.
- Despatch. The ERP creates a delivery for a customer order. When the pallet is scanned onto the truck, a shipping event is recorded, and EPCIS can reference the business transaction, such as the purchase order or despatch advice, so the physical and commercial records can be joined later.
At each step, one system is authoritative for one kind of fact. The ERP is authoritative for the order and the stock balance. The line and event records are authoritative for which serials were actually applied, verified and packed where. How ERP, printer, scanner and packaging line work together describes the factory-side wiring in more detail.
Common mistakes
Treating ERP allocation as commissioning. If commissioning events are generated when the ERP allocates serials, the history fills with products that were never made. Commission on physical evidence.
Letting either system overwrite the other silently. If the line rejected 37 serials, the ERP should learn about it through an agreed reconciliation, not by quietly correcting the event history, or vice versa.
Pushing every scanner read into the ERP. ERPs are not designed for millions of unit-level reads. Holding detailed events in a system built for them, and passing summaries to the ERP, is usually more robust.
Assuming ERP data is shareable as-is. Internal plant codes and custom statuses mean little to a distributor. Shared identifiers (GTIN, SSCC, GLN) and CBV vocabulary are what make event data portable.
Choosing where each fact lives
A practical rule for architects and operations leads: put each fact in the system that directly observes it, then share it with the systems that need it.
- Orders, prices, stock balances and invoices: ERP.
- Which serials were printed, verified and packed into which cartons: line systems, recorded as events.
- What partners did with the goods: their own systems, shared as EPCIS events where agreed.
Whether those events must be sent to GS1 is a separate question, answered in does EPCIS mean sending all my data to GS1? (it doesn't).
See how AIQR's event records sit alongside your ERP