RECADV — Receiving Advice Message (D.96A)

The RECADV message tells the supplier that a delivery has been physically received: quantities actually received, plus any variances against the despatch advice (DESADV) or the original order (ORDERS).

Purpose

Per the official UN/CEFACT definition, RECADV "is to address the business needs related to the goods receipt. This message is used to report the physical receipt of goods. The message allows for the reporting of discrepancies in products, quantities, terms, packages, etc." It can either confirm that the received consignment matches exactly what was announced in the DESADV, or report discrepancies against the DESADV, ORDERS D.96A, DELFOR D.96A or DELJIT D.96A information.

In practice, RECADV is the pivot of the "3-way match" process in accounts payable (Order ↔ Receipt ↔ Invoice) and the trigger for self-billing in retail and automotive.

Segment structure

Unlike ORDERS or INVOIC, the D.96A RECADV segment table has no formal Header / Detail / Summary split: there is no UNS and no labelled Detail section. It can still be split into three logical zones: a head block, a long series of party / transport groups, then the SG16 (CPS) packaging loop that carries the received lines.

Mandatory header segments: UNH M , BGM M , and DTM M . The ALI C segment is conditional, right after DTM.

Then comes a long series of "message-head" groups:

SG1 RFF+DTM — references (RFF+ON for the order, RFF+DQ for the DESADV...).
SG2 DOC + SG3 CDI+INP — external documents.
SG4 NAD+LOC — parties (mandatory in the spec).
SG5 RFF+DTM and SG6 CTA+COM — party-level references and contacts.
SG7 TOD and SG8 CDI+INP — delivery terms and physical state.
SG9 LOC+CDI — locations and state per location.
SG10 TDT+DTM+CDI — transport.
SG11 EQD with SG12 CDI+INP, SG13 SEL+CDI (seals), SG14 EQA, SG15 CDI+INP — equipment.

Detail (received CPS + LIN)

The business core of RECADV sits in the SG16 loop (up to 9,999 occurrences) built around CPS M . Each CPS nests:

SG17 PAC+QVR — package and optional package-count variance, with sub-groups SG18 PCI+RFF, SG19 CDI+INP and SG20 GIN + SG21 CDI+INP to identify packages (received SSCCs) and their state.
SG22 — the item loop (up to 9,999) with LIN M , PIA C , IMD C , QTY C , QVR C , and DTM C .
SG23 CDI+INP, SG24 DOC, SG25 CDI+INP — line-level states and documents.
SG26 GIN + SG27 CDI+INP — line identifiers (serial numbers, lots).
SG28 RFF+DTM — line references.
SG29 PCI+QTY+QVR + SG30 CDI+INP and SG31 GIN + SG32 CDI+INP — line-level packaging and state.

Trailer

RECADV has no formal Summary section: no UNS. After the SG16 loop come directly: CNT C , then UNT M .

Mandatory / conditional

Five structural items are strictly mandatory in every D.96A RECADV:

UNH — opens the message.
BGM — gives the function (632 = receiving advice) and the number.
DTM in the header — at least one date (DTM+137 or DTM+50 receipt date).
SG4 with its NAD — at least one parties group (M in the spec, max 10 occurrences).
UNT — closes the message.

On the business side you also need: RFF+ON (referenced order), typically RFF+DQ (referenced DESADV), at least one CPS (SG16) wrapping at least one LIN (SG22) with QTY+194 (received quantity). Variances ride on QVR inside SG22 — without QVR, the receipt is implicitly fully compliant.

Real-world example

A receipt for two SKUs from a referenced DESADV: the first is received fully compliant (2 units), the second shows a negative variance (4 received vs 5 announced — 1 short, QVR+1).

edifact recadv-d96a-example.edi

UNB+UNOC:3+5410000000123:14+5410000000456:14+260521:0930+CTRL000030'
UNH+1+RECADV:D:96A:UN:EAN008'
BGM+632+RECADV-2026-0521-001+9'
DTM+137:20260521:102'
DTM+50:202605210900:203'
RFF+ON:ORDER789'
DOC+351:DESADV-2026-0521'
NAD+BY+5410000000123::9'
NAD+SU+5410000000456::9'
NAD+DP+5410000000789::9'
CPS+1'
PAC+10+++:::1 pallet'
PCI+33E'
LIN+1++3520000001234:EN'
QTY+194:2'
LIN+2++3520000005678:EN'
QTY+194:4'
QVR+1:21'
CNT+2:2'
UNT+18+1'
UNZ+1+CTRL000030'

BGM+632+RECADV-2026-0521-001+9 — type 632 (Receiving advice), number RECADV-2026-0521-001, status 9 (Original).
DTM+137 — document date. DTM+50 — physical receipt date/time (qualifier 203 timestamp).
RFF+ON:ORDER789 — reference to the originating order.
DOC+351:DESADV-2026-0521 — reference to the announcing DESADV.
NAD+BY / NAD+SU / NAD+DP — Buyer, Supplier, Delivery Point.
CPS+1 — packing sequence 1 (the received pallet).
First line: QTY+194:2 — 2 units received, no QVR (compliant).
Second line: QTY+194:4 + QVR+1:21 — 4 units received, short by 1 (reason 21 = quantity short shipped).
CNT+2:2 — 2 lines for 2 distinct SKUs.
UNT+18+1 — 18 segments.

Common errors

Missing RFF+DQ or DOC+351 — a RECADV without a reference to the DESADV that triggered it is unusable on the supplier side: no way to tie the receipt to the matching despatch.
QTY+194 vs QTY+12 — RECADV uses QTY+194 (received quantity), not QTY+12 (despatched quantity, which belongs in DESADV). Many naive implementations copy the DESADV QTY without changing the qualifier.
No UNS — RECADV has no UNS segment. Inserting one out of habit, by analogy with ORDERS/INVOIC, will trip up strict validators.
Ambiguous QVR — a variance is reported via QVR with a clear reason code (element 4221): 21 short shipped, 22 over shipped, 23 damaged, etc. Without a reason code, the supplier cannot classify the variance to issue a credit note or replacement.
Missing NAD — at least one NAD is mandatory (SG4 is M). Many implicit EDI receipt feeds skip this, which makes them non-compliant with the standard.

RECADV is the business-acknowledgment step of the order-to-cash cycle:

DESADV D.96A — the despatch advice that triggers the RECADV.
ORDERS D.96A — the referenced order.
ORDRSP D.96A — the order confirmation.
INVOIC D.96A — the invoice that must match the RECADV (3-way match) or be self-billed from it.
REMADV D.96A — the remittance advice, eventually.
CONTRL D.96A — the automatic syntactic acknowledgment.

JSON equivalent

JSON projection matching the example above. The mapping is not normative — it's an ediverse convention to ease integration in TypeScript / Python environments.

json recadv-d96a-equivalent.json

{
  "interchange": {
    "controlRef": "CTRL000030",
    "from": { "id": "5410000000123", "qualifier": "14" },
    "to": { "id": "5410000000456", "qualifier": "14" },
    "datetime": "2026-05-21T09:30:00Z",
    "syntax": { "id": "UNOC", "version": "3" }
  },
  "message": {
    "ref": "1",
    "type": "RECADV",
    "version": { "syntax": "D", "release": "96A", "agency": "UN", "association": "EAN008" }
  },
  "receivingAdvice": {
    "number": "RECADV-2026-0521-001",
    "function": "632",
    "status": "9",
    "issueDate": "2026-05-21",
    "receivedAt": "2026-05-21T09:00:00Z",
    "references": {
      "buyerOrder": "ORDER789",
      "despatchAdvice": "DESADV-2026-0521"
    },
    "parties": {
      "buyer": { "gln": "5410000000123" },
      "supplier": { "gln": "5410000000456" },
      "deliveryPoint": { "gln": "5410000000789" }
    },
    "packingSequences": [
      {
        "ref": 1,
        "package": { "type": "pallet", "quantity": 1 },
        "lines": [
          { "ref": 1, "gtin": "3520000001234", "received": 2 },
          { "ref": 2, "gtin": "3520000005678", "received": 4, "variance": { "type": "short", "value": 1 } }
        ]
      }
    ],
    "totals": { "lineCount": 2 }
  }
}

Foundations

Standards

Flagship messages

Tools

RECADV — Receiving Advice Message (D.96A)

Purpose

Segment structure

Header

Detail (received CPS + LIN)

Trailer

Mandatory / conditional

Real-world example

Common errors

JSON equivalent

RECADV — Receiving Advice Message (D.96A)

Purpose

Segment structure

Header

Detail (received CPS + LIN)

Trailer

Mandatory / conditional

Real-world example

Common errors

Related messages

JSON equivalent