Error declaration

EPCIS events are immutable. A captured event cannot be edited or deleted in place. To correct erroneous event data, EPCIS 2.0 provides a two-step correction pattern:

Declare the error: Capture a new event that is an exact copy of the erroneous event's identifying content, using the same event type and eventID, with an added errorDeclaration element. This marks the original event as erroneous.
Issue a corrective event (optional): Capture one or more new events with new eventIDs containing the corrected information, and reference them from an error declaration using the correctiveEventIDs field.

Error declaration rules and best practices

Assign an eventID to every event at capture time. Events that do not include an eventId can never be corrected.
The error declaration must be captured as the same event type as the original. For example, an erroneous AggregationEvent is corrected by an AggregationEvent error declaration.
Never reuse an eventID for anything other than its error declaration. Corrective events must always use new eventIDs.
A single declaration may reference multiple corrective events (for example, one erroneous aggregation may be replaced by two corrected ones.
did_not_occur error declarations do not require corrective events.
Corrective events are strongly recommended for incorrect_data error declarations.
Downstream consumers should treat any event whose eventID has an associated error declaration as superseded.
Corrective workflows should propagate to trading partners that received the original event. EPCIS does not auto-forward corrections.

Error declaration fields

The following table describes EPCIS 2.0 JSON document payload fields applicable to error declarations.

Name	Type	Description	Required	Example
declarationTime	DateTime	The time at which the error was declared (not the time of the original event).	Required	`2026-06-12T16:20:00.000Z`
reason	CBV/URI	The reason the original event is erroneous. CBV 2.0 error reasons: `did_not_occur` (the event never happened) and `incorrect_data` (the event happened but was recorded with wrong data).	Optional (strongly recommended)	`incorrect_data`
correctiveEventIDs	Array of URI	The `eventIDs` of the new corrective events that replace the erroneous one. Only applicable to `incorrect_data` declarations; omitted for `did_not_occur` declarations.	Optional	`["urn:uuid:9d23c1f0-…"]`
Extensions	Any	Namespace-qualified custom fields are permitted inside an error declaration.	Optional	`"ext1:reviewedBy": "QA"`

Error declaration examples

The following sections provide three EPCIS 2.0 error declaration examples with annotations.

Declaring an event that did not occur

Use this error declaration when the original event should never have been captured (for example, when a test scan was accidentally sent to production). You do not need to include a corrective event with this error declaration.

{ // Same event TYPE as the erroneous event "type": "ObjectEvent", // SAME eventID as the original erroneous event — this is how the // repository knows which event is being declared erroneous "eventID": "urn:uuid:5d1c5b21-9a64-4f1d-9d2c-1f6f1f8a2b1e", // The error declaration element "errorDeclaration": { // When the error was discovered/declared "declarationTime": "2026-06-12T16:20:00.000Z", // CBV error reason: the event never actually happened "reason": "did_not_occur" // NOTE: no correctiveEventIDs — there is nothing to replace it with }, // The remaining fields repeat the ORIGINAL event's content verbatim "eventTime": "2026-06-12T14:05:00.000Z", "eventTimeZoneOffset": "-06:00", "action": "OBSERVE", "epcList": [ "urn:epc:id:sscc:4012345.0111222333" ], "bizStep": "shipping", "disposition": "in_transit", "readPoint": { "id": "urn:epc:id:sgln:4012345.00011.dock-3" }
}

Incorrect data declaration

Use this error declaration when the event happened but contained incorrect data (for example, when the wrong EPCs were scanned, or the wrong bizLocation was used). Submit both the incorrect_data declaration and acorrective event.

{ "type": "ObjectEvent", // SAME eventID as the erroneous original "eventID": "urn:uuid:374d95fc-9457-4a51-bd6a-0bba133845a8", "errorDeclaration": { // When the error was declared "declarationTime": "2026-06-12T16:30:00.000Z", // CBV error reason: event occurred, but the recorded data was wrong "reason": "incorrect_data", // Points to the NEW corrective event(s) that carry the corrected data "correctiveEventIDs": [ "urn:uuid:9d23c1f0-3a6b-41d2-8c0e-fb7714aa9921" ] }, // Original (erroneous) content repeated verbatim "eventTime": "2026-06-12T08:30:00.000Z", "eventTimeZoneOffset": "+01:00", "action": "ADD", "epcList": [ "urn:epc:id:sgtin:4012345.011122.25", "urn:epc:id:sgtin:4012345.011122.99" // <-- the wrong serial that was captured ], "bizStep": "commissioning", "disposition": "active", "readPoint": { "id": "urn:epc:id:sgln:4012345.00005.line-1" }
}

Corrective event

This example provides the corrective event that follows the preceding incorrect_data declaration. It includes and new eventId,

{ "type": "ObjectEvent", // NEW eventID — referenced by correctiveEventIDs in the declaration above "eventID": "urn:uuid:9d23c1f0-3a6b-41d2-8c0e-fb7714aa9921", // Same real-world occurrence time as the original event "eventTime": "2026-06-12T08:30:00.000Z", "eventTimeZoneOffset": "+01:00", "action": "ADD", // CORRECTED data: serial 26 instead of the erroneous 99 "epcList": [ "urn:epc:id:sgtin:4012345.011122.25", "urn:epc:id:sgtin:4012345.011122.26" ], "bizStep": "commissioning", "disposition": "active", "readPoint": { "id": "urn:epc:id:sgln:4012345.00005.line-1" }
}