# The document nobody sends: recadv, the 861, and the close of the cycle > transactions.dev · by visibility.cloud — 2026-07-31 > Written for 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](https://epcis.dev/conformance/)), the receiving advice sits in the same sub-context as its famous siblings: ```json "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](/blog/the-asn-said-48-the-dock-saw-47/) 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](https://barcoding.dev) 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](/blog/from-856-to-epcis-document/): ```json { "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](/blog/the-gtin-is-the-join-key/), 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](/blog/every-wire-format-is-a-dialect/). 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](/blog/the-asn-said-48-the-dock-saw-47/) made durable as paperwork, on [the field every event type carries](/blog/the-why-dimension-rides-on-every-event/). 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](https://visibility.cloud/asn-po-context-in-traces). 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](/get-access/); the onboarding flow asks the rest. --- Access: https://transactions.dev/get-access/ · All posts: https://transactions.dev/blog/ · Machine face: https://transactions.dev/llms.txt