What Is an Aggregation Event?

A pallet of perfume leaves a factory with one label facing the forklift driver. Behind that label are 40 cartons and 960 bottles, each with its own serial number. The aggregation event is what lets one scan stand in for all of them, and it is also one of the easiest records in a traceability programme to get wrong.

What an aggregation event records

Aggregation is the act of packing identified items into a larger identified unit. In EPCIS, it is captured by its own event type, the AggregationEvent. Each event has three essential parts:

• The parent. The container's identifier, given in a field called parentID. For cartons and pallets this is usually an SSCC, the 18-digit GS1 code for logistic units.
• The children. The identities of what went inside, listed in childEPCs when each child is identified individually (for example, GTIN plus serial number). Children can also be recorded as quantities of a product class or batch.
• The action. ADD when children are placed in the parent, DELETE when they are taken out. A third action, OBSERVE, records that the relationship was seen without changing it.

Like other events, it records when, where and why. The why usually comes from the CBV (Core Business Vocabulary): the business step packing for an ADD, and an unpacking step for a DELETE.

A worked example: one carton

On a fictional Maison Ardent line, 24 bottles of eau de parfum have each been printed, verified and commissioned. A case packer drops them into a carton, a camera reads all 24 codes through the open top, and a labeller applies an SSCC to the carton. When the count and identities match, the carton is closed and the station records:

Forty such cartons later, the pallet is wrapped and labelled, and a second AggregationEvent links the pallet SSCC (parent) to the 40 carton SSCCs (children). The pallet's history now implicitly includes 960 bottles, through two levels of parent–child records.

In EPCIS 2.0 JSON-LD, the carton event might look like this. It is simplified and illustrative: only two of the 24 children are shown, and the identifiers are fictional.

{
  "type": "AggregationEvent",
  "eventTime": "2026-09-14T03:44:05Z",
  "eventTimeZoneOffset": "+05:30",
  "parentID": "https://id.maisonardent.example/00/395011010000000019",
  "childEPCs": [
    "https://id.maisonardent.example/01/09501101530003/21/AN7Q2X4K",
    "https://id.maisonardent.example/01/09501101530003/21/BF3M8R1T"
  ],
  "action": "ADD",
  "bizStep": "packing"
}

Why it matters

The payoff of aggregation shows up downstream:

• Shipping and receiving at container level. The factory scans one pallet label to ship; the distributor scans one to receive. Anyone with access to the history can expand that pallet into cartons and units. Why warehouses scan a carton or pallet instead of every unit explains the operational logic.
• Recalls. If a batch is affected, aggregation records show which cartons and pallets contain it, so partners can find and hold the right stock rather than everything.
• Unit-level questions. When a single bottle turns up somewhere unexpected, aggregation is how you work out which carton and pallet it travelled in, and therefore which shipment.

The physical side of building cartons and pallets, and where SSCC labels come from, is covered in how individual products become cartons and pallets. The broader concept, beyond EPCIS, is in what is aggregation in product traceability?

Disaggregation: keeping the record true

Containers don't stay closed forever. A distributor breaks a pallet down to fill smaller orders; a retailer opens a carton to stock a shelf; a quality team pulls three bottles from a carton for testing. Each time, the parent–child relationship changes, and the record has to change with it.

That is what DELETE is for. An AggregationEvent with action DELETE says that the listed children are no longer in the parent. If the whole container has been emptied, the event can name just the parent, meaning all its children have been removed.

Skipping disaggregation is the most common way aggregation data goes stale. Picture the distributor who breaks down pallet ...0026 and sends its cartons to ten different shops, without recording the DELETE. Six months later, a recall query on that pallet says all 40 cartons are still together at the distributor. The answer is confidently wrong.

Rework and re-packing

Factories re-pack too. If a carton fails inspection and two bottles are swapped, a correct record shows a DELETE for the two removed bottles and an ADD for the two replacements, against the same carton SSCC. If the carton is scrapped and its contents repacked into a new one, the old carton is emptied and a new ADD links the bottles to the new SSCC.

What makes an aggregation event trustworthy

The event format is the easy part. The quality comes from the evidence behind it:

1. Only commissioned children. A bottle with no commissioning event should never appear inside a carton.
2. A verified container label. The SSCC recorded as the parent should be the one actually read from the carton, not just the one the labeller was told to print.
3. A confirmed closure. Record the ADD when the carton is sealed with the right count and identities, not when packing starts.
4. Discipline downstream. Every party that opens containers should record what it removed.

These are factory and warehouse disciplines as much as data ones, which is why aggregation sits close to the line systems that read codes and close cartons. For how these events fit into a complete history, see the EPCIS business guide.