The trace carries its paperwork.

When a custody question lands on your desk — which lot, which case, which dock door, which hour — the answer is a trace: the chain of recorded events for that item, hop by hop, with a performer on every one. This page is about the other half of that answer, the half your auditors and your counterparties reach for first: the paperwork. The purchase order that asked for the goods. The advance ship notice that said they were coming. The receiving advice that closed the loop. A trace that cannot say which documents an event answers to is a trace your team still has to reconcile by hand.

So the record carries the documents with it. Every event in a trace can name the business transactions it belongs to — this shipment's ASN, this line's PO — and the parties on either side of the handoff, by GLN. Custody and context, one record.

---

The standard already has a field for your purchase order

Don't take our word for any of this — the specs are public.

• CBV 2.0 §7.3 defines the business-transaction type vocabulary itself: po (purchase order), desadv — the despatch advice, the standard noting it is also called an Advanced Shipment Notice — inv (invoice), recadv (receiving advice), bol (bill of lading), and the rest. The documents your business runs on are first-class citizens of the vocabulary, by name.
• CBV 2.0 §8.5 gives each of those documents an identifier syntax, and the event's own bizTransactionList is where the references ride — on the event, not in a side system. Every event type carries the list.
• CBV 2.0 §7.4 and §8.7 give the party join: source and destination, owning party and location, as GLNs — the same identifiers your item master and your trading-partner records already keep.

Four spec-sanctioned join points, zero extensions, involving nobody's word. When a trace on this record shows you a receiving event, the ASN reference, the PO reference and the party GLNs are fields of the event itself.

---

What the buyer of a custody answer sees

A trace here is a chain of events, and each event answers three questions at once: what happened (the business step, the items, the time), who it answers to (the documents on bizTransactionList), and who stood there (the attested observer — who — kept permanently distinct from capturedBy, the warrantor account that wrote the record). One event from a worked trace, in the record's own grammar:

Illustrative — rendered from the tested event model, the same corpus the conformance tests pass on. Not customer data, and not a customer's record: a worked figure in the record's own grammar.

Read the figure the way your auditor will. The case arrived at the dock — and the event names the ASN it arrived under, the PO that ordered it, the selling party and the buying party, and the person or agent who actually received it. The record shows that a case arrived and who received it and which paperwork it answers to. That last clause is what turns "we found the case" into "we can defend the case."

---

The reconcile question, answered from the record

Every operator knows the question that follows a delivery: does what was shipped match what was seen? The ASN says twelve cases of a GTIN under lot L42; the dock's events say eleven. Today, in most operations, that delta is a phone call — and when the shipment crossed a franchise boundary or a co-manufacturer boundary, it is a phone call to someone whose data is contractually somebody else's to hand over.

On a record where events carry their document references, that question changes species: it becomes a comparison between two things the record already holds — the quantities the despatch advice declared, and the events the dock actually captured under that ASN's reference. Record versus record. No call, no export, no favor owed across the boundary.

The exception view — the worked queue of ASN-versus-observed deltas, each line naming its shipment, its lot grain and its receiving events — will render exactly that comparison, and it carries its named entries in the open P0 ledger until it ships. The trace itself, with its document references and its attested observer on every hop, is the record that view reads from.

---

Who answers with this

The Director of Food Safety / QA. Your mock recall stalls where the record goes silent: a case arrived at a DC, and nothing says who received it or under which shipment. On this record the receiving event carries the ASN reference, the lot, and the attested who — so the traceback stays a query as it crosses the boundary that used to turn it into telephony.

The RFP responder. A shipper's traceability clause asks you to prove your custody answers connect to their commercial documents. The answer this record gives is citable: business-transaction references per CBV 2.0 §7.3 and §8.5 on every event type, party GLNs per §7.4 and §8.7, and an attested observer the standard's own party fields do not reach. Spec sections, not vendor adjectives.

The Director of Supplier Data. The GLNs on the event are the GLNs in your master data. The join between "what the suppliers send" and "what the docks see" runs on identifiers you already govern — the record adds the event side, it does not ask you to re-key the party side.

---

The same spine, from the developer side

Your integration team will ask the reasonable question: how do the documents get there? The developer door is epcis.dev/business-transactions — the business-transaction layer of the same spine: purchase orders, despatch advices, invoices and receiving advices compiled to the same CBV bizTransaction references and party joins shown above. EDI included, never EDI-only: X12 and EDIFACT land on the same joins as plain JSON from an order-and-shipment API. What your partners already send is what the record already speaks.

---

The two live actions on this origin: the get-started interview — branch Q serves the operator whose reads are already flowing — and your first trace, the worked example above at full length. We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read.