RECADV in full: the open receiving advice, and the reconcile it encodes

Written for ED-3 — the in-house supply-chain platform team — the platform engineer who owns the receiving side and wants the verdict machine-readable in the counterparty's own grammar.

One thesis: RECADV is the discrepancy-bearing document of the transaction cycle — received versus accepted versus rejected quantities, per line — and because it is UNTDID-open it can be fully documented here, which makes it the natural output format for a reconcile verdict: the diff, re-expressed in the counterparty's own grammar.

Every other document in the cycle asserts intent or claims performance. The receiving advice is the only one whose whole job is to disagree precisely — and it is the least implemented of the four, which is exactly why a platform team that ships it well holds the strongest position at every dispute that follows.

The document nobody sends, and where receiving actually lives

The X12 861 exists; adoption never followed. In 2026 the receiving fact is usually born as an ERP or WMS object — an item receipt, a goods receipt, a warehouse receiving order — and either dies there or travels as a phone call. The event record does not care where the fact is born: a goods receipt compiles to the same recadv reference that a wire-format receiving advice does, because CBV 2.0 §7.3 defines recadv beside po, desadv, and inv in its closed vocabulary. What RECADV adds — and what this page documents, since the directories are pinned and legal to print — is the fully structured, counterparty-legible expression of the disagreement itself.

The machinery: quantities that argue

RECADV's spine mirrors the DESADV it answers: BGM identifies the advice, RFF points at the despatch advice and the order, NAD carries the party GLNs, CPS/LIN walk the packaging tree. The difference is in the quantity layer. Where the DESADV states one number per line — despatched — the RECADV states several, each tagged by a qualifier from the pinned quantity-type code list: the quantity received; the quantity accepted; the quantity rejected, when acceptance and receipt disagree. Beside them, the QVR segment carries the signed variance against what was announced, with a coded reason — short shipment, damage, substitution — drawn from the same open code lists, each value annotated in the reference from its pinned directory file.

A self-authored fragment, answering the DESADV from the walkthrough post:

UNH+1+RECADV:D:96A:UN:EAN002'
BGM+632+REC7020015+9'            document: receiving advice
DTM+137:20260731:102'
RFF+DQ:DES8560001'               the despatch advice this answers
RFF+ON:4500123'                  the order it settles
NAD+BY+0345678000007::9'         buyer, by GLN
NAD+SU+0614141000005::9'         supplier, by GLN
CPS+1'
LIN+1++00614141123452:SRV'       the trade item, by GTIN
QTY+48:190'                      received: 190

against an announced 192 — with the variance segment carrying the minus two and its coded reason. Received, accepted, and rejected are typed verdicts, not remarks: a downstream system parses them without reading free text, which is the entire advantage of a controlled vocabulary over a comments field.

Reconcile output → RECADV: closing the loop in their grammar

Here is where the document stops being paperwork and becomes an interface. The reconcile verb compares an ASN against captured events and returns a typed diff with exit-code semantics — matched, missing, unexpected, lot-mismatch. Run the landing page's fixture: the ASN announced 192 cases, the dock's events observed 190, two findings, exit 1. That verdict object contains, field for field, everything a RECADV needs:

• announced quantity → the despatch reference and its lines,
• observed quantity → received, per GTIN, per tree node,
• the finding types → the variance segments and their reason codes,
• the event record's identifiers → the same GLNs and GTINs, unchanged.

So the pipeline treats RECADV as a projection of the reconcile verdict — reconcile produces the diff, and the emitter renders it as a conformant receiving advice addressed to the counterparty that sent the ASN. Your trading partner receives the disagreement in the grammar their systems already parse, and your own record keeps the verdict it was derived from. No prose email, no spreadsheet attachment, no second source of truth.

Either way, the reference lands

Whether the receiving fact arrives as a RECADV from a partner, an 861 from a legacy lane, or a WMS receiving order from an API, the compile is the same two moves: a receiving ObjectEvent (bizStep receiving, at the destination GLN's location) and a recadv reference stamped onto it, joined to the po and desadv references already riding the shipment's events. That completes the record's four-way story on one spine — ordered, despatched, billed, received — with the invoice post covering the third corner and the scope law that keeps money out of it.

Every event emitted along the way validates against the pinned official EPCIS 2.0 schema — superset where a document carries more than the standard models, and conformant always. And because RECADV is open content, the reference pages behind this walkthrough go all the way down: message, segments, elements, code values, each quoted from a directory file whose digest is pinned and whose license reading is journaled. The cycle's most honest document deserves nothing less than a fully checkable reference — and it is the one document of the four where this site can print every last code. If the receiving side is yours to close, say where your receipts live — the onboarding flow asks what record your receiving side holds today and who eats the claim when a shipment goes wrong.

---

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