# TRADACOMS DLCHDR: Delivery Confirmation Explained

> TRADACOMS DLCHDR delivery confirmation files explained: DLCDET and DLCTLR, DST and DCD variance codes, live proof of delivery examples and EANCOM RECADV.

<QuickAnswer>
DLCHDR is the TRADACOMS delivery confirmation file a UK customer sends its supplier after goods arrive, often called the proof of delivery. It holds a DLCHDR header, one DLCDET message per delivery with DCD lines for the quantities received and variance codes for shortages or damage, and a DLCTLR trailer. Its EANCOM equivalent is RECADV.
</QuickAnswer>

The delivery confirmation is the retailer telling you what it actually received. Not what you picked, not what your delivery note says, but what was counted at goods-in. If those differ, this file is your first warning, and it usually arrives before the deduction on your remittance does.

Not every UK retailer sends one. Where they do, it is the document to invoice against. M&S's EDI guides for Food suppliers say it plainly: the proof of delivery tells suppliers the quantities M&S received, and suppliers should invoice those quantities. This guide explains how a DLCHDR file is built, how to read its variance codes, and how it maps to the [EDIFACT RECADV](/guides/edi/edifact-recadv) receiving advice.

<EDIGuideCTA
  badge="For TRADACOMS DLCHDR"
  transactionType="856"
  headline="Read a delivery confirmation line by line"
  body="Paste a TRADACOMS DLCHDR into the free EDIFACT inspector to see every delivery, line and variance, with MTR and END counts checked. OrderSync processes EDIFACT, EANCOM and TRADACOMS alongside X12, PDF, CSV and email, and matches receipts back to the order in your ERP."
  secondaryHref="/edifact-inspector"
  secondaryLabel="Try the free EDIFACT inspector"
/>

## What is a TRADACOMS DLCHDR file?

**DLCHDR is the delivery confirmation file in TRADACOMS, the UK retail EDI standard created by the Article Numbering Association, now GS1 UK.** The customer sends it to the supplier to confirm the goods and quantities delivered at a location. Its transaction code, `0670`, is defined in the TRADACOMS code list as "Confirmation of Delivery: confirms the goods and quantities which have been delivered at a location".

Do not confuse it with **DELHDR**, the delivery notification file. They flow in opposite directions:

| | DELHDR delivery notification | DLCHDR delivery confirmation |
|---|---|---|
| Sent by | Supplier | Customer |
| When | At or before despatch | After the goods are received |
| Says | "This is what we are sending" | "This is what we received" |
| Detail message | `DELIVR` | `DLCDET` |
| EANCOM equivalent | [DESADV](/guides/edi/edifact-desadv) | [RECADV](/guides/edi/edifact-recadv) |
| X12 equivalent | [856](/guides/edi/856-ship-notice) | [861](/guides/edi/861-receiving-advice) |

## DLCHDR file structure

```
STX   Start of transmission (customer to supplier, APRF DLCHDR)
│
├── MHD DLCHDR   Delivery confirmation header    once per file
│     TYP  SDT  CDT  FIL  (DNA  FDT)
│   MTR
│
├── MHD DLCDET   Delivery confirmation details   once per delivery, repeats
│     CLO                                        where it was delivered
│     ODD                                        order, delivery note, POD reference
│     DST                                        overall delivery status
│     DCD  (DPI  DNB) ...                        one per product line received
│     RCD  (RPI  RNB) ...                        one per product line returned
│     DCT                                        number of DCD and RCD lines
│   MTR
│
├── MHD DLCTLR   Delivery confirmation trailer   once per file
│     COT                                        confirmations in this file
│   MTR
│
END   End of transmission (number of messages)
```

Each message carries its own version number in `MHD`, and for this file they are not 9. The TRADACOMS table in IBM's Gentran:Server documentation lists version 4 for all three release 9 delivery confirmation messages, so the examples below use 4. Other tools list other versions, so use whatever your partner's guide names.

## Example: confirmation with one damaged case

Fictional retailer Harbour Lane Stores confirms a delivery from fictional supplier Kestrel Valley Homeware to its northern distribution centre. Forty cases of chopping boards were ordered and delivered, but one case arrived damaged. The other two lines were received in full. Identifiers are made up, with valid GS1 check digits.

<EdifactSample
  title="DLCHDR file confirming a delivery with a damaged case"
  description="One DLCDET message: delivery status 1 (variance) with reason D, 39 cases received in prime condition and 1 damaged, and two lines received in full."
  label="TRADACOMS"
  raw="STX=ANA:1+5012345000008:HARBOUR LANE STORES LTD+5098765000002:KESTREL VALLEY HOMEWARE+261015:183000+000611+PASSW+DLCHDR+B'
MHD=1+DLCHDR:4'
TYP=0670+DELIVERY-CONFIRMATIONS'
SDT=5098765000002:000041207'
CDT=5012345000008+HARBOUR LANE STORES LTD'
FIL=611+1+261015'
MTR=6'
MHD=2+DLCDET:4'
CLO=5012345000107:00212+HARBOUR LANE NORTHERN DC'
ODD=1+HL-PO-88340::261012+KV-DN-55120:261015+++HL-POD-77310:261015'
DST=1+D'
DCD=1+5098765100016:KV-1001+++6+39+BAMBOO CHOPPING BOARD:LARGE+1++40'
DCD=2+5098765100016:KV-1001+++6+1+BAMBOO CHOPPING BOARD:LARGE+2+D'
DCD=3+5098765100023:KV-1002+++4+20+SALT AND PEPPER MILL SET+1++20'
DCD=4+5098765100030:KV-1003+++12+10+BAMBOO UTENSIL SET+1++10'
DCT=4'
MTR=10'
MHD=3+DLCTLR:4'
COT=1'
MTR=3'
END=3'"
/>

| Segment | What it says |
|---|---|
| `STX=...+DLCHDR+B'` | Customer to supplier; application reference `DLCHDR` |
| `TYP=0670+...` | Transaction code 0670: confirmation of delivery |
| `SDT` / `CDT` | Supplier and customer, sent once for the whole file |
| `FIL=611+1+261015'` | File generation number 611, version 1 |
| `CLO=5012345000107:00212+...` | The location that received the goods |
| `ODD=1+HL-PO-88340::261012+KV-DN-55120:261015+++HL-POD-77310:261015'` | The order and its date, your delivery note and its date, and the customer's proof of delivery number and the date the goods were delivered |
| `DST=1+D'` | Delivery status `1`: variance from the instruction; reason `D`: damaged goods |
| `DCD=1+...+6+39+...+1++40'` | 39 cases of 6 received in prime condition (stock status `1`) against 40 required |
| `DCD=2+...+6+1+...+2+D'` | 1 case received damaged (stock status `2`), reason `D` |
| `DCD=3` / `DCD=4` | The other two lines, received in full |
| `DCT=4'` | Four confirmation lines in the message |
| `COT=1'` | One delivery confirmation in the file |
| `END=3'` | Three messages |

How partners record damaged stock varies. Splitting a product across two DCD lines with different stock status codes, as here, is one way the segment allows; others send a single line with the accepted quantity and a variance reason. Check your partner's guide.

## Segment reference

Release 9 layouts. "M" is mandatory and "O" optional in the standard. The EANCOM column gives the closest equivalent in the [RECADV receiving advice](/guides/edi/edifact-recadv).

### DLCHDR: file header

| Segment | Name | Status | What it carries | EANCOM equivalent |
|---|---|---|---|---|
| `MHD` | Message header | M | Message number and `DLCHDR:version` | `UNH` |
| `TYP` | Transaction type | M | 0670 confirmation of delivery | `BGM+632` |
| `SDT` | Supplier details | M | Supplier GLN and code | `NAD+SU` |
| `CDT` | Customer details | M | Customer GLN and name | `NAD+BY` |
| `DNA` | Data narrative | O | File-level notes | `FTX` |
| `FIL` | File details | M | File generation number, version and date | No direct equivalent |
| `FDT` | File period dates | O | Period end dates covered by the file | `DTM` period |
| `MTR` | Message trailer | M | Segment count | `UNT` |

### DLCDET: one per delivery

| Segment | Name | Status | What it carries | EANCOM equivalent |
|---|---|---|---|---|
| `CLO` | Customer's location | M | Receiving location: GLN and codes | `NAD+DP` |
| `ODD` | Order and delivery references | M, repeats | Order number and date, delivery note number and date, number of units, weights, proof of delivery number and delivery date, carrier | `RFF+ON`, `RFF+AAK`, `DTM+50` |
| `DST` | Delivery status | M | Delivery condition code, reason for variance, action (cancel or rebook) | `QVR` reason, or no variance |
| `DNA` | Data narrative | O | Delivery-level notes | `FTX` |
| `DCD` | Delivery confirmation details | O, repeats | Product, pack, quantity delivered, stock status, variance reason, quantity required | `LIN`, `QTY+194`, `QTY+21`, `QVR` |
| `DPI` | Delivered pallet identity | O, per line | Identity of the pallets the line arrived on | `GIN+BJ` (SSCC) |
| `DNB` | Data narrative | O, per line | Line-level notes | `FTX` |
| `RCD` | Returns confirmation details | O, repeats | Product and quantity returned or uplifted | `LIN` with a returns quantity |
| `RPI` / `RNB` | Returned pallet identity, returns narrative | O | Pallet IDs and notes for returns | `GIN`, `FTX` |
| `DCT` | Delivery confirmation trailer | O | Number of DCD and RCD lines | `CNT+2` |

### DLCTLR: file trailer

| Segment | Name | Status | What it carries | EANCOM equivalent |
|---|---|---|---|---|
| `COT` | Confirmation file totals | M | Number of DLCDET messages in the file | None |

## Reading DST and DCD

The delivery status segment `DST` gives the overall result; each `DCD` gives the line.

**DST delivery condition codes (code list 21), the ones you will see most:**

| Code | Meaning |
|---|---|
| `0` | Delivered as instructed |
| `1` | Delivery variance from a previously transmitted instruction |
| `2` | Completely undelivered; not to be replanned |
| `3` | Delivery variance with no prior transmitted instruction |
| `4` | Completely undelivered; to be replanned |
| `M` | Proof of delivery |

**DCD line layout:**

| Position | Field | In `DCD=1+5098765100016:KV-1001+++6+39+BAMBOO CHOPPING BOARD:LARGE+1++40'` |
|---|---|---|
| 1 | `SEQA` line number | `1` |
| 2 | `SPRO` GTIN of the traded unit, supplier's code, DUN-14 | `5098765100016:KV-1001` |
| 3 to 4 | `SACU` consumer unit EAN, `CPRO` customer's codes | empty |
| 5 | `UNOR` consumer units per traded unit | `6` |
| 6 | `DELQ` traded units in the delivery | `39` |
| 7 | `TDES` description | `BAMBOO CHOPPING BOARD:LARGE` |
| 8 | `SSTC` stock status: 1 prime, 2 damaged, 3 out of date, 4 quarantined, 5 written off | `1` |
| 9 | `DUAC` reason for variance and action | empty |
| 10 | `AQTY` traded units required | `40` |
| 11 | `SREF` secondary reference | empty |

**Reasons for variance (code list 17)** appear in both `DST` and `DCD`. Common ones: `A` out of stock, `C` refused delivery, `D` damaged goods, `E` driver short delivered, `N` over delivery, `Q` product delivered not ordered, `V` late delivery, `Z` substitute product, and `AA` confirmation of no variance. The optional second component is an action: `C` cancel or `R` rebook.

Like every TRADACOMS quantity, `DELQ` and `AQTY` count traded units, so 39 here means 39 cases of 6, not 39 boards.

## Example: a file covering two store deliveries

Store suppliers often receive one file covering several drops. Here the Leeds store received only two of three cases of tea towels (reason `E`, driver short delivered), while York received its order in full. The supplier details travel once, in the header.

<EdifactSample
  title="DLCHDR file with a short store delivery and a clean one"
  description="Two DLCDET messages: Leeds with DST 1 and a short line (reason E), York with DST 0 and AA, no variance. DLCTLR counts two confirmations."
  label="TRADACOMS"
  raw="STX=ANA:1+5012345000008:HARBOUR LANE STORES LTD+5098765000002:KESTREL VALLEY HOMEWARE+261014:220000+000612+PASSW+DLCHDR+B'
MHD=1+DLCHDR:4'
TYP=0670+DELIVERY-CONFIRMATIONS'
SDT=5098765000002:000041207'
CDT=5012345000008+HARBOUR LANE STORES LTD'
FIL=612+1+261014'
MTR=6'
MHD=2+DLCDET:4'
CLO=5012345000114:0114+HARBOUR LANE LEEDS'
ODD=1+HL-PO-88341::261012+KV-DN-55121:261014+++HL-POD-77311:261014'
DST=1+E'
DCD=1+5098765100016:KV-1001+++6+4+BAMBOO CHOPPING BOARD:LARGE+1++4'
DCD=2+5098765100047:KV-1004+++10+2+LINEN TEA TOWEL TWIN PACK+1+E+3'
DCT=2'
MTR=8'
MHD=3+DLCDET:4'
CLO=5012345000121:0121+HARBOUR LANE YORK'
ODD=1+HL-PO-88342::261012+KV-DN-55123:261014+++HL-POD-77312:261014'
DST=0+AA'
DCD=1+5098765100016:KV-1001+++6+2+BAMBOO CHOPPING BOARD:LARGE+1++2'
DCT=1'
MTR=7'
MHD=4+DLCTLR:4'
COT=2'
MTR=3'
END=4'"
/>

The Leeds shortfall is now on record from the customer's side. Invoice two cases, not three, or expect a debit note for the third and send a [credit note (CREHDR)](/guides/edi/tradacoms-crehdr) with reason code `38` to match it.

## What to do when a DLCHDR arrives

1. **Match it to the delivery.** Use the order number and delivery note number in `ODD` to find your despatch record.
2. **Compare line by line.** For each `DCD`, compare `DELQ` with what you despatched, not just what was ordered. Look at `SSTC` for damaged or out-of-date stock.
3. **Read the reason.** `E` driver short delivered points at the carrier; `D` damaged goods at packing or transit; `A` out of stock usually means you short-shipped and already know.
4. **Invoice the confirmed quantity**, where your partner asks for that. M&S's Food guides ask suppliers to invoice the POD quantities.
5. **Dispute quickly.** If you hold a signed delivery note or carrier proof showing a different count, raise it now, while the delivery is recent.

## DLCHDR to EANCOM RECADV

M&S publishes the same proof of delivery flow both ways: its TRADACOMS guides name DLCHDR, and its EANCOM proof of delivery guide is built on the RECADV message. Here is how the content lines up.

| Business data | TRADACOMS delivery confirmation | EANCOM RECADV |
|---|---|---|
| Document type | `TYP=0670` | `BGM+632` |
| Receiving location | `CLO` | `NAD+DP` |
| Order reference | `ODD` order number | `RFF+ON` |
| Your delivery note or despatch reference | `ODD` delivery note number | `RFF+AAK` (despatch advice) |
| Date received | `ODD` proof of delivery date | `DTM+50` |
| Overall result | `DST` | No single segment; implied by line variances |
| Product | `DCD` `SPRO` | `LIN` GTIN |
| Quantity received | `DCD` `DELQ` | `QTY+194` (received and accepted) |
| Quantity expected | `DCD` `AQTY` | `QTY+21` or `QTY+12` |
| Variance reason | `DCD` `DUAC`, `SSTC` | `QVR` with a discrepancy code |
| Pallet received | `DPI` | `GIN+BJ` SSCC |
| Line count | `DCT` | `CNT+2` |
| Confirmations in file | `COT` | None |

The X12 counterpart is the [861 receiving advice](/guides/edi/861-receiving-advice).

## Which UK retailers send DLCHDR

Public evidence is thinner for DLCHDR than for orders and invoices, because fewer retailers send it.

- **M&S** sends a proof of delivery to Food suppliers. Its TRADACOMS implementation guides name DLCHDR as the TRADACOMS message and its EANCOM guide for the same flow uses RECADV. See the [Marks & Spencer page](/edi-compliance/marks-and-spencer).
- **Sainsbury's** lists proof of delivery among the messages commonly set up with suppliers, and trades both EDIFACT and TRADACOMS, per Cegedim. Which standard carries it for your account is for Sainsbury's EDI team to confirm. See the [Sainsbury's page](/edi-compliance/sainsburys).

If your partner does not send one, you will usually learn about shortages from a debit note or a remittance deduction instead, which is later and harder to dispute.

## Common DLCHDR problems

1. **Reading DELQ as consumer units.** Delivered quantities are traded units, with the pack size in `UNOR`.
2. **Treating it as the despatch notice.** DLCHDR comes from the customer after receipt. Your outbound notice is DELHDR, or DESADV in EANCOM.
3. **Ignoring stock status.** A line can show the full quantity delivered with `SSTC` 2 (damaged). Count it as a shortfall for invoicing.
4. **Not matching on the delivery note.** One order can arrive in several deliveries. Match on the order number and the delivery note number in `ODD` together.
5. **Envelope counts.** As with every TRADACOMS file, `MTR` counts from `MHD` to `MTR` inclusive and `END` counts every message, so a file with two confirmations has `END=4`. Checking `COT` against the number of `DLCDET` messages catches truncated files.

## How OrderSync handles DLCHDR

OrderSync reads delivery confirmations in TRADACOMS and EANCOM and matches each line to the order and despatch already in your system, so a short or damaged line becomes an exception to review before you invoice, not a deduction you find a month later. Paste a file into the free [EDIFACT inspector](/edifact-inspector) to see what it contains first.

## Frequently Asked Questions

### What is DLCHDR in EDI?

DLCHDR is the TRADACOMS delivery confirmation file used in UK retail. The customer sends it after goods are received to confirm what arrived. It contains a DLCHDR header, one DLCDET message per delivery and a DLCTLR trailer.

### Is DLCHDR the same as a proof of delivery?

In practice, yes. Retailers that send a proof of delivery in TRADACOMS use the delivery confirmation file, and the ODD segment carries the proof of delivery number and the date of delivery. M&S's EDI guides use the terms together.

### What is the difference between DLCHDR and DELHDR?

DELHDR is the delivery notification the supplier sends before or at despatch, saying what is on its way. DLCHDR is the delivery confirmation the customer sends after receipt, saying what arrived. They are the TRADACOMS counterparts of DESADV and RECADV.

### What is the EDIFACT equivalent of DLCHDR?

The EANCOM RECADV receiving advice, with document code `BGM+632`. In X12, the closest equivalent is the 861 receiving advice.

### What does DST=0 mean in a delivery confirmation?

`DST` is the delivery status segment and `0` means the delivery was made as instructed. `1` means there is a variance from the instruction, and the second element gives the reason, such as `D` damaged goods or `E` driver short delivered.

### Should I invoice the ordered or the confirmed quantity?

Invoice what your partner will pay for. Where a retailer sends a delivery confirmation, that is usually the confirmed quantity: M&S tells Food suppliers to invoice the POD quantities. Invoicing more leads to a debit note and a credit note to clear it.

## Related guides

- **[TRADACOMS explained](/guides/edi/tradacoms)**: syntax, STX and END, and how files work
- **[TRADACOMS file types](/guides/edi/tradacoms-file-types)**: every file type and its EANCOM equivalent
- **[TRADACOMS INVFIL](/guides/edi/tradacoms-invfil)**: invoicing the confirmed quantities
- **[TRADACOMS CREHDR](/guides/edi/tradacoms-crehdr)**: crediting shortages and damages
- **[EDIFACT RECADV](/guides/edi/edifact-recadv)**: the EANCOM receiving advice

## Sources

- [TRADACOMS release 9 DLCDET layout](https://www.kasoftware.com/schema/edi/tradacoms/9/messages/DLCDET/), KA Software schema reference, including the DLCHDR, DLCTLR, DST, DCD, DCT, COT and TYP code list pages
- [M&S Purchase Order implementation guide (TRADACOMS)](https://mands.gxs.co.uk/content/Implementation_Guides/MS%20Message_Implementation%20Guide_Purchase_Order_tradacom_071110.pdf) and [M&S Proof of Delivery implementation guide (EANCOM RECADV)](https://mands.gxs.co.uk/content/Implementation_Guides/MS_Message_Implementation_Guide_%20Proof_of_Delivery_Eancom.pdf), Marks & Spencer via GXS
- [Using proprietary TRADACOMS standards](https://public.dhe.ibm.com/software/commerce/doc/gentran/server/unix/61/TB_tcom.pdf), Gentran:Server technical bulletin, IBM: the TRADACOMS header, detail and trailer message table with message versions
- [Connect to Sainsbury's via EDI](https://www.cegedim-business-services.co.uk/resources/blog/connect-to-sainsburys-via-edi), Cegedim
- [TRADACOMS](https://en.wikipedia.org/wiki/TRADACOMS), Wikipedia: the delivery confirmation file in the list of 25 transaction files
- [Ending support for TRADACOMS](https://www.gs1uk.org/insights/news/ending-support-for-tradacoms), GS1 UK

Check a DLCHDR's structure and counts in the free [EDIFACT inspector](/edifact-inspector).