The 850 asks, the 810 settles — anatomy of the commercial bookends

Written for ED-1 — the supply-chain ISV / traceability-vendor engineering org — the VP Engineering deciding where the three-way match should live.

One thesis: the 850 and the 810 are the transaction cycle's bookends — the order that asks and the invoice that claims — and the three-way match between them and the shipment is not an AP workflow problem but a join across three references the event record already has fields for. Where that join lives determines who can answer the cycle's questions, and how expensively.

BEG03 is the cycle's primary key

Strip an 850 to its load-bearing line and one element remains: the purchase-order number, third element of the BEG segment. Everything the cycle produces afterward echoes it — the 856's PRF segment cites it (the promise claim of the ASN), the 810 opens by citing it, the receiving advice closes against it. A synthetic 850, reduced to the segments that matter for the record (element-level dictionary detail lives at the licensed reference, linked and never republished):

ST*850*0001~
BEG*00*NE*PO-2026-0007**20260731~        the key: PO-2026-0007
N1*BY*ACME RETAIL*UL*0614141000012~      buyer, by GLN
N1*SE*BLUE CREEK FOODS*UL*0614142000011~ seller, by GLN
PO1*1*48*CA*12.50**UP*061414110006~      line 1: 48 cases of one GTIN
CTT*1~
SE*7*0001~

And the honest caveat that belongs beside any claim of a primary key: BEG03 decays. Change orders re-release it (the 860 exists precisely to mutate an open order), blanket orders spawn releases against one number, and some ERPs recycle numbering across years. The record's job is not to pretend the key is perfect — it is to carry the key on every event so that when the key does decay, the dispute is about one field's history rather than about three systems' recollections.

The 810's claim structure

The invoice is the mirror image: the same key, the same parties, the same line grain — but now as a monetary claim. Its structural spine is an identity (invoice number and date), the PO echo, and per-line quantity-times-price assertions that terminate in a total. Where the 850 said send 48, the 810 says you owe for 48. In practice the disagreements concentrate at the line level: quantity billed versus quantity shipped (short-ships invoiced whole), price versus the order's price (list-price drift, missed allowances), and lines invoiced that no shipment ever carried.

The three-way match as record algebra

Classically the match — does the order agree with the shipment agree with the invoice — is an AP workflow: three documents in three inboxes, reconciled by a clerk or an ERP module (where the cycle actually lives today), invisible to everyone upstream. The record-side alternative: each document compiles to a reference on the same events. CBV 2.0 defines all three types — po, desadv, inv — and one item's shipping event carries them together:

{
  "type": "ObjectEvent",
  "action": "OBSERVE",
  "bizStep": "shipping",
  "disposition": "in_transit",
  "eventTime": "2026-07-31T09:15:00.000Z",
  "eventTimeZoneOffset": "+00:00",
  "epcList": ["urn:epc:id:sgtin:0614141.110000.4471"],
  "bizTransactionList": [
    { "type": "po",     "bizTransaction": "urn:epc:id:gdti:0614141.06011.7007" },
    { "type": "desadv", "bizTransaction": "urn:epc:id:gdti:0614142.06012.4471" },
    { "type": "inv",    "bizTransaction": "urn:epc:id:gdti:0614142.06013.9102" }
  ]
}

Three bookkeeping systems' worth of "which documents govern this item's movement" collapse into one field on one event — core-spec fields, not extensions, with each identifier held to the one-document-one-identifier rule. Now the match is set algebra: items whose events cite a desadv but whose po covers a different quantity; invoices citing shipments no event corroborates; orders whose events simply never arrived. The shipped-versus-seen leg of that algebra is the reconcile verdict, and the fourth reference that closes the cycle — recadv, the receiving side's answer — lands on the same spine the same way.

The decision-brief tail: why the match belongs on the record

For the VP weighing where this capability lives, the argument is about who can verify. A match executed inside an ERP is authoritative exactly as far as that ERP's login page. A match expressed as references on a conformant event record is verifiable by any party holding the record — your auditor, your customer's auditor, a counterparty's agent — because every emitted event validates against the pinned official EPCIS 2.0 schema and the references are standard vocabulary, not house convention. The family's one sentence applies in full: the record holds up whether or not the reader joined anything. That is also why the executive view of this exact join — ASN and PO context on traces — can stand on the same events the engineering side emits, with nothing separate to audit.

And the honest boundary, stated as sharply as the capability: pricing disputes are not an event-record problem. Whether $12.50 was the agreed price, whether the allowance applied, whether payment terms triggered — that is adjudication, and it stays in AP where it belongs. What the record settles is presence and absence: this item moved, under this order, on this shipment, claimed by this invoice — or it did not. In three-way-match practice, presence and absence is most of the fight; the clerk's folder of "invoiced but never arrived" is precisely the query the spine answers mechanically.

The compile that stamps all three references is one pipeline — 850s, 856s, and 810s in, conformant events out. If your cycle's documents are already flowing, the access flow asks for exactly the facts that scope the join: which sets, which versions, which side of the match hurts.

---

859 words. The access flow is at /get-access/; the family's event door is epcis.dev.