Every enterprise you have worked in runs two record worlds that do not speak. The document world — purchase orders, advance ship notices, invoices, receiving advices — lives in the EDI stack and the ERP, governed by trading-partner agreements, reconciled by a team that has done it the same way for twenty years. The event world — scans, receipts, aggregations, the material truth of what moved — lives wherever your traceability programme is putting it. Between them sits a boundary every audit crosses the hard way: the trace says a case arrived; the ASN that announced it is in another system; a human joins them with a spreadsheet.

Here is the fact this post exists to put in your hands: the standard already dissolved that boundary. The Core Business Vocabulary — the companion vocabulary to EPCIS 2.0 — was written with your trading documents as first-class citizens, by name. Joining a purchase order to a custody event is not an integration your vendor builds. It is core-spec machinery.

The spec quotes, verbatim

CBV 2.0 §7.3 defines the business-transaction type vocabulary. Among its members: po (purchase order), inv (invoice), recadv (receiving advice), bol (bill of lading), prodorder — and desadv, whose definition the standard gives as:

"Despatch Advice. A document/message by means of which the seller or consignor informs the consignee about the despatch of goods. Also called an 'Advanced Shipment Notice,' but the value desadv is always used regardless of local nomenclature."

Read that second sentence twice, because a standards body wrote it about your paperwork: the ASN — the document your EDI team transmits thousands of times a week — is in the vocabulary, under a stable name, with an instruction that the name holds no matter what your industry calls it locally.

And where do those references live? CBV 2.0 §8.5 places them on the event itself: business transaction identifiers "populate the 'why' dimension of EPCIS events. This includes the bizTransactionList field in all EPCIS event types." Every event — object, aggregation, transaction, transformation, association — carries the list. Not a side table, not a linking service you subscribe to: fields of the record, defined by the same specification your programme already validates against.

The joined event, as a fixture

Here is what the join looks like in practice — a conformant TransactionEvent from the tested corpus behind this record, the same corpus the conformance suite passes on. Illustrative identifiers, real grammar: