The document nobody sends: recadv, the 861, and the close of the cycle

Written for ED-1 — the supply-chain ISV / traceability-vendor engineering org — the integration engineer who has built the outbound cycle twice and the receiving side never.

One thesis: the receiving advice is the cycle's least-sent and best-supported document — CBV defines recadv beside po, desadv, and inv — and in 2026 its natural source is not an X12 861 at all but the goods-receipt object your ERP or WMS already creates, compiled to the same reference.

The spec support, first

The vocabulary makes no distinction of rank among the cycle's four documents. In the pinned EPCIS 2.0 JSON-LD context (sha256 5056c65f…, digests at epcis.dev/conformance), the receiving advice sits in the same sub-context as its famous siblings:

"desadv": "cbv:BTT-desadv",
"inv":    "cbv:BTT-inv",
"po":     "cbv:BTT-po",
"recadv": "cbv:BTT-recadv"

CBV 2.0 §7.3 defines it as the receiving advice — the receiver's statement of what actually arrived and was accepted, against what was claimed. X12 gave it a transaction set decades ago: the 861. EDIFACT gave it RECADV. The standards did their part; adoption is where the story thins.

Why the receiving side went quiet

The outbound documents had enforcement behind them. Retail hubs made the 856 a compliance requirement with chargebacks attached; the 810 is how suppliers get paid; the 850 is how anything ships at all. The 861 had no such patron in most lanes — the receiver already knows what it received, and telling the sender was a courtesy that cost an EDI map, so most receiving truth stayed inside the four walls, in whatever object the warehouse system writes at the dock. The result is an asymmetric record: supply chains prove what was claimed shipped in meticulous detail and prove what was accepted almost nowhere — which is exactly the half of the reconcile story that settles disputes. The asymmetry is not a data gap; it is a leverage gap, and it explains why the deduction argument always runs on the sender's evidence.

Where receiving actually lives in 2026

Not in the 861. In the systems of record, receiving is a first-class API object today — each of these verified against its official developer documentation:

• NetSuite — the item receipt record (itemReceipt in the REST record catalog): the transaction NetSuite creates when a purchase order's goods arrive.
• Dynamics 365 Business Central — purchaseReceipts and their lines in the standard API v2.0.
• ShipBob — Warehouse Receiving Orders (/warehouse-receiving-orders, developer.shipbob.com): the 3PL's inbound receiving object, lot-aware.
• Extensiv (3PL Central) — GET /inventory/receivers: the receiver records a 3PL's warehouse writes per inbound, with lot, expiry, and pallet detail on the lines.

That list is the connector hook of this post, and it carries the honest finding from surveying the field: outside the ERPs, WMS receiving objects are nearly the only place recadv semantics exist as structured data — and none of these systems speaks GLN or SSCC natively, which is why the compile to a conformant record runs through the identifier layer rather than around it.

Compiling a goods receipt to the record

One worked figure. A Business Central purchase receipt — receipt number GR-2231, against PO-8812, received at the buyer's dock — compiles to a receiving ObjectEvent exactly the way an 856 compiles to a shipping one:

{
  "type": "ObjectEvent",
  "action": "OBSERVE",
  "bizStep": "receiving",
  "disposition": "in_progress",
  "quantityList": [
    { "epcClass": "https://id.gs1.org/01/00614141123452/10/L42",
      "quantity": 47 }
  ],
  "bizTransactionList": [
    { "type": "recadv",
      "bizTransaction": "urn:epcglobal:cbv:bt:0724142000017:GR-2231" },
    { "type": "po",
      "bizTransaction": "urn:epcglobal:cbv:bt:0724142000017:PO-8812" },
    { "type": "desadv",
      "bizTransaction": "urn:epcglobal:cbv:bt:0614141000012:SHIP20260730001" }
  ]
}

The recadv reference uses CBV §8.5's scheme, scoped by the receiver's GLN — the party that assigned GR-2231. The event carries what the dock accepted at lot grain, joined by GTIN, and validates against the pinned official EPCIS 2.0 schema (sha256 0f46ff69…) — conformant, and a superset only where the receipt carries more than the standard models, never one without the other. An 861 or an EDIFACT RECADV, where a partner does send one, compiles to the same reference type — the wire format is a dialect; the transaction is the noun. The reference type is stamped either way: whether the receiving truth arrives as an EDI document, an API object, or a reconcile verdict promoted to paperwork, the record's consumers filter on recadv and never learn — and never need to learn — which rail carried it.

The three-way story on one record

With the receiving side compiled, one item's event chain carries the whole commercial argument as three references on core fields: what was ordered (po), what the sender claims shipped (desadv), what the receiver accepted (recadv) — the reconcile verdict made durable as paperwork, on the field every event type carries. The deduction dispute that today burns a week of emails becomes a query over one document; the executive reading of that same claim is visibility.cloud's brief.

Your stack already writes the receiving object. The missing move is the compile — and the cycle only closes when someone makes it. Say which systems hold your receipts; the onboarding flow asks the rest.

---

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