# EDIFACT ORDERS: Purchase Order Segments and Example

> EDIFACT ORDERS purchase order explained: live EANCOM examples, BGM, NAD, LIN, QTY and PRI segments, multi-drop orders, allowances and the X12 850 mapping.

<QuickAnswer>
EDIFACT ORDERS is the UN/EDIFACT purchase order message, the equivalent of the X12 850. A buyer sends it to order goods. The header carries the order number (BGM), dates (DTM) and parties as GLNs (NAD); each line starts with LIN and the product's GTIN, followed by quantity (QTY) and price (PRI). UNS and CNT close the message.
</QuickAnswer>

ORDERS is the first message in nearly every EDIFACT order cycle. If you are taking on a UK or European retail customer, it is the message your system has to read first and get right, because every response you send afterwards (ORDRSP, DESADV, INVOIC) quotes back what it contained. Misread one quantity or one delivery point here and the error travels through the despatch advice, the invoice and the remittance.

This guide uses the GS1 EANCOM 2002 layout of ORDERS (directory D.01B), which is what most retail partners base their specifications on. Every example below is live: it is parsed in your browser by the same engine as our EDIFACT inspector, so you can expand each segment, check the counts and open it in the full tool. If EDIFACT syntax is new to you, start with [EDIFACT explained](/guides/edi/edifact).

<EDIGuideCTA
  badge="For EDIFACT ORDERS"
  transactionType="850"
  headline="Read a partner's ORDERS file before you map it"
  body="Paste an ORDERS message into the free EDIFACT inspector to see every segment explained, with UNT and CNT counts and GTIN check digits verified. OrderSync processes EDIFACT, EANCOM and TRADACOMS orders alongside X12, PDF, CSV and email, straight into your ERP."
  secondaryHref="/edifact-inspector"
  secondaryLabel="Try the free EDIFACT inspector"
/>

## What is an EDIFACT ORDERS message?

**ORDERS is the UN/EDIFACT purchase order message: a buyer's request to a supplier for goods or services, with quantities, prices, dates and delivery locations.** It is defined in the UN/EDIFACT directories (for example D.96A and D.01B) and profiled for retail by [GS1 EANCOM](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part2/orders/toc.htm), which restricts it to the segments and codes the consumer goods sector uses.

The message has three sections:

- **Header**: order number and type, dates, references, parties, currency, payment and delivery terms.
- **Detail**: one segment group per line item, always starting with `LIN`.
- **Summary**: `UNS+S` marks the end of the detail section, then optional totals (`MOA`) and a `CNT` control count.

GS1's own principle for the message is simple: one purchase order for one delivery to one location at one time. Everything else (split deliveries, blanket orders, call-offs, promotions) is a variation on that, and each has a defined place in the structure.

## When ORDERS is sent in the order-to-cash flow

ORDERS starts the cycle. Everything after it refers back to its order number in an `RFF+ON` segment.

| Step | Message | Direction | Typical timing |
|---|---|---|---|
| 1 | **ORDERS** | Buyer to supplier | When the buyer's replenishment or buying system raises the order, often overnight in grocery |
| 2 | [CONTRL](/guides/edi/edifact-contrl) | Supplier to buyer | Within minutes: the interchange arrived and parsed |
| 3 | [ORDRSP](/guides/edi/edifact-ordrsp) | Supplier to buyer | Before picking starts, if the partner requires a response |
| 4 | [ORDCHG](/guides/edi/edifact-ordchg) | Buyer to supplier | Any time before despatch, to amend or cancel the order |
| 5 | [DESADV](/guides/edi/edifact-desadv) | Supplier to buyer | At despatch, before the goods arrive |
| 6 | [RECADV](/guides/edi/edifact-recadv) | Buyer to supplier | After the delivery is booked in |
| 7 | [INVOIC](/guides/edi/edifact-invoic) | Supplier to buyer | After despatch or delivery, per the partner's terms |

The full catalogue of messages is in [EDIFACT message types](/guides/edi/edifact-message-types). UK grocery suppliers often see the TRADACOMS order file instead of, or alongside, ORDERS; see [TRADACOMS ORDHDR](/guides/edi/tradacoms-ordhdr) for that format.

## Example 1: a standard order, segment by segment

A fictional UK retailer, Harbour Lane Stores, orders three homeware lines from a fictional supplier, Kestrel Valley Homeware, for delivery to its distribution centre. Every identifier is a made-up GS1-style number with a valid check digit.

<EdifactSample
  title="Standard purchase order, three lines, one delivery point"
  description="BGM+220 order with document date, requested delivery date, buyer, supplier and delivery party GLNs, and three GTIN lines with quantity and net price."
  label="EANCOM 2002 D.01B"
  raw="UNA:+.? '
UNB+UNOC:3+5012345000008:14+5098765000002:14+261011:0915+HLS000451++ORDERS'
UNH+1+ORDERS:D:01B:UN:EAN010'
BGM+220+HL-PO-88231+9'
DTM+137:20261011:102'
DTM+2:20261016:102'
NAD+BY+5012345000008::9'
NAD+SU+5098765000002::9'
NAD+DP+5012345000107::9'
CUX+2:GBP:9'
LIN+1++5098765100016:SRV'
PIA+1+KV-1001:SA'
IMD+F++:::BAMBOO CHOPPING BOARD LARGE'
QTY+21:120'
PRI+AAA:6.50'
LIN+2++5098765100023:SRV'
PIA+1+KV-1002:SA'
IMD+F++:::SALT ?+ PEPPER MILL SET'
QTY+21:60'
PRI+AAA:9.80'
LIN+3++5098765100030:SRV'
PIA+1+KV-1003:SA'
IMD+F++:::COTTON TEA TOWEL 3 PACK'
QTY+21:48'
PRI+AAA:2.25'
UNS+S'
CNT+2:3'
UNT+26+1'
UNZ+1+HLS000451'"
/>

| Segment | What it says |
|---|---|
| `UNB+UNOC:3+...` | Interchange from GLN 5012345000008 to GLN 5098765000002 (qualifier `14` = GS1) |
| `UNH+1+ORDERS:D:01B:UN:EAN010'` | An ORDERS, directory D.01B, EANCOM subset version 010 |
| `BGM+220+HL-PO-88231+9'` | Order (220), number HL-PO-88231, original (9) |
| `DTM+137` / `DTM+2` | Order date and requested delivery date, format 102 (CCYYMMDD) |
| `NAD+BY` / `SU` / `DP` | Buyer, supplier and delivery party GLNs, agency `9` (GS1) |
| `LIN+1++5098765100016:SRV'` | Line 1, GTIN 5098765100016 (`SRV` = GS1 GTIN) |
| `PIA+1+KV-1001:SA'` | The supplier's own article number |
| `QTY+21:120'` / `PRI+AAA:6.50'` | Ordered quantity 120 at a net price of 6.50 |
| `SALT ?+ PEPPER` | The `?` releases the `+` so it is read as text |
| `CNT+2:3'` | Control count: 3 line items |
| `UNT+26+1'` | 26 segments, counting UNH and UNT |

The association code at the end of the UNH (`EAN010` here) tells you which EANCOM subset version the sender built to. Partners name the exact value in their implementation guide. GS1's current ORDERS manual shows `EAN010` in its worked example while its UNH code list has moved on to `EAN011`, which is a good reminder to validate against your partner's guide rather than a single global rule.

## ORDERS segment reference

The table follows the EANCOM 2002 message structure. Status is M (mandatory) or C (conditional), and repeats are the maximum the manual allows. "SG" is the segment group the segment sits in.

| Segment | Name | Status | Repeats | What it carries | X12 850 equivalent |
|---|---|---|---|---|---|
| `UNH` | Message header | M | 1 | Message reference, type and version | `ST` |
| `BGM` | Beginning of message | M | 1 | Order type, order number, function | `BEG` |
| `DTM` | Date/time/period | M | 35 | Order date (`137`, mandatory) and delivery dates | `BEG05`, `DTM` |
| `PAI` | Payment instructions | C | 1 | How payment is to be made | none direct |
| `ALI` | Additional information | C | 5 | Special conditions for the whole order | none direct |
| `FTX` | Free text | C | 99 | Coded or free-form notes | `MSG`, `NTE` |
| `RFF` (SG1) | Reference | C | 9999 | Contract, promotion, price list numbers | `REF` |
| `NAD` (SG2) | Name and address | C | 99 | Buyer, supplier, delivery party, invoicee | `N1` loop |
| `CTA` / `COM` (SG5) | Contact | C | 5 | Order contact and phone or email | `PER` |
| `TAX` (SG6) | Duty/tax/fee | C | 5 | Order-level VAT | `TXI` |
| `CUX` (SG7) | Currencies | C | 5 | Order currency, exchange rate | `CUR` |
| `PAT` (SG8) | Payment terms | C | 10 | Terms for this order only | `ITD` |
| `TDT` (SG10) | Transport | C | 10 | Requested transport mode | `TD5` |
| `TOD` (SG12) | Terms of delivery | C | 5 | Incoterms and similar | `FOB` |
| `ALC` (SG19) | Allowance or charge | C | 99 | Order-level allowances and charges | `SAC` |
| `LIN` (SG28) | Line item | C | 200000 | Line number and GTIN | `PO1` |
| `PIA` | Additional product id | C | 25 | Buyer or supplier codes, substitutes | `PO106` to `PO125` |
| `IMD` | Item description | C | 99 | Coded or free text description | `PID` |
| `MEA` | Measurements | C | 99 | Size or weight for variable products | `MEA` |
| `QTY` | Quantity | C | 99 | Ordered quantity (`21`), free goods (`192`) | `PO102` |
| `DTM` | Date/time/period | C | 35 | Line delivery dates | `DTM` in PO1 loop |
| `MOA` | Monetary amount | C | 10 | Line amount (`203`) | `AMT` |
| `PRI` (SG32) | Price details | C | 25 | Net price (`AAA`), information prices | `PO104`, `CTP` |
| `RFF` (SG33) | Reference | C | 9999 | Line references, such as price list line | `REF` |
| `PAC` (SG34) | Package | C | 99 | Pack instructions where no despatch unit code exists | `PO4` |
| `LOC` (SG37) | Place/location | C | 9999 | Split delivery location | `SDQ` |
| `TAX` (SG38) | Duty/tax/fee | C | 10 | Line VAT if it differs from header | `TXI` |
| `ALC` (SG43) | Allowance or charge | C | 99 | Line allowances and charges | `SAC` |
| `UNS` | Section control | M | 1 | Separates detail from summary | none |
| `MOA` | Monetary amount | C | 99 | Order totals (`79`, `86`, `259`, `260`) | `AMT` |
| `CNT` | Control total | C | 10 | Line count (`2`) or quantity total (`1`) | `CTT` |
| `UNT` | Message trailer | M | 1 | Segment count and reference | `SE` |

In practice a typical retail order uses perhaps a dozen of these. The rest exist for specific business cases, which is why the partner's implementation guide matters more than the full list.

## Qualifier and code tables

### BGM: order type and function

`BGM+220+HL-PO-88231+9'` has three parts: the document name code, the order number, and the message function.

| Document code | Meaning |
|---|---|
| `220` | Order |
| `221` | Blanket order |
| `224` | Rush order |
| `226` | Call off order |
| `227` | Consignment order |
| `258` | Standing order |
| `402` | Cross docking order |

EANCOM recommends the more specific code where one applies, rather than the general `220`. A blanket order (`221`) sets a global quantity per line over a period, and later call-offs (`226`) draw down parts of it with their own dates and locations.

| Function code | Meaning |
|---|---|
| `9` | Original |
| `5` | Replace: cancels and replaces an order identified in `RFF` |
| `7` | Duplicate: re-sent at the receiver's request |
| `31` | Copy: for a third party, information only |
| `16` | Proposal: a suggested order |
| `46` | Provisional |

A fourth element can ask for a response: `BGM+220+HL-PO-88231+9+AC'` requests an acknowledgement with detail and changes, while `NA` says no acknowledgement is needed. If a partner sends `AC`, treat an [ORDRSP](/guides/edi/edifact-ordrsp) as required for that order.

### DTM: date qualifiers

| Qualifier | Meaning |
|---|---|
| `137` | Document date (mandatory in every EANCOM message) |
| `2` | Requested delivery date |
| `64` / `63` | Earliest / latest delivery date |
| `10` | Requested shipment date |
| `37` / `38` | Ship not before / ship not later than |
| `61` | Cancel if not delivered by this date |
| `15` | Promotion start date (only where no promotion reference is sent) |
| `X14` | Requested for delivery week commencing (format `616`, CCYYWW) |

Format `102` is CCYYMMDD and `203` is CCYYMMDDHHMM, so `DTM+63:202610181430:203'` means "deliver by 14:30 on 18 October 2026". A delivery window is two segments: `DTM+64` and `DTM+63`.

### NAD: party qualifiers

`BY` buyer and `SU` supplier are mandatory. `DP` delivery party and `IV` invoicee are added when they differ from the buyer; `SN` store number and `CO` corporate office also appear. Parties are identified by GLN, with `9` in the agency position. EANCOM allows a full name and address only where a coded identity cannot be used, so most partners send the GLN alone and expect you to hold the address in master data.

### PIA: other product codes

`PIA+1+KV-1001:SA'` adds the supplier's article number and `PIA+1+...:IN` the buyer's item number. `PIA+2` offers a substitute GTIN, `PIA+X1` says no substitution is accepted, and `PIA+5` carries the primary code for a product with no GTIN. EANCOM makes the GTIN in `LIN` mandatory whenever one exists.

### QTY and PRI

| Code | Meaning |
|---|---|
| `QTY+21` | Ordered quantity |
| `QTY+192` | Free goods quantity |
| `QTY+59` | Consumer units in the traded unit (confirmation only) |
| `QTY+11` | Split quantity for one location (inside the `LOC` group) |
| `PRI+AAA` | Net calculation price: gross plus charges minus allowances, excluding tax |
| `PRI+AAF` | Information price, excluding allowances, charges and taxes |
| `PRI+AAE` | Information price, excluding allowances and charges, including taxes |

EANCOM is firm on one point: the calculation price in an order is always the net unit price. Allowances and charges in the same order are there for information, so do not subtract them again from `PRI+AAA`.

## Example 2: multi-drop order with deliveries to several stores

Here the buyer orders for three stores at once. There is no header delivery party; instead, each line carries a `LOC+7` group per store with its own split quantity (`QTY+11`) and delivery date.

<EdifactSample
  title="Split delivery to three stores"
  description="Two lines, each split across store GLNs with LOC+7, QTY+11 and DTM+2. The split quantities on each line add up to that line's ordered quantity."
  label="EANCOM 2002 D.01B"
  raw="UNA:+.? '
UNB+UNOC:3+5012345000008:14+5098765000002:14+261012:0700+HLS000466++ORDERS'
UNH+1+ORDERS:D:01B:UN:EAN010'
BGM+220+HL-PO-88302+9'
DTM+137:20261012:102'
NAD+BY+5012345000008::9'
NAD+SU+5098765000002::9'
CUX+2:GBP:9'
LIN+1++5098765100016:SRV'
QTY+21:36'
PRI+AAA:6.50'
LOC+7+5012345000213::9'
QTY+11:12'
DTM+2:20261019:102'
LOC+7+5012345000220::9'
QTY+11:12'
DTM+2:20261019:102'
LOC+7+5012345000237::9'
QTY+11:12'
DTM+2:20261020:102'
LIN+2++5098765100030:SRV'
QTY+21:24'
PRI+AAA:2.25'
LOC+7+5012345000213::9'
QTY+11:24'
DTM+2:20261019:102'
UNS+S'
CNT+2:2'
UNT+27+1'
UNZ+1+HLS000466'"
/>

Three rules make split deliveries work:

1. **The split quantities must add up.** EANCOM requires the `QTY+11` values in the `LOC` groups to equal the line's `QTY+21`. Line 1 orders 36 and splits 12, 12 and 12.
2. **The line-level location overrides the header.** If the header has a `NAD+DP`, it is the default delivery point for lines without their own `LOC` groups.
3. **Each location becomes its own delivery.** Your warehouse needs one pick, one despatch advice and usually one invoice per store, all quoting the same order number.

This is where ERP imports most often go wrong. A sales order that can hold only one ship-to will either take the first `LOC` and send everything there, or reject the order. Decide before go-live how a multi-drop order becomes sales orders in your ERP (one per location is the usual answer), and keep the buyer's order number on each so the despatch advice and invoice can quote it.

## Example 3: promotional order with free goods

Retailers order differently for promotions: larger quantities, a promotional price, sometimes free stock. EANCOM handles this with a promotion reference at header level and promotional price and free goods codes at line level.

<EdifactSample
  title="Promotional order with a deal reference and free goods"
  description="RFF+PD identifies the promotion, PRI with price specification PRP marks the promotional price, and QTY+192 adds 24 free units to line 1."
  label="EANCOM 2002 D.01B"
  raw="UNA:+.? '
UNB+UNOC:3+5012345000008:14+5098765000002:14+261012:0715+HLS000467++ORDERS'
UNH+1+ORDERS:D:01B:UN:EAN010'
BGM+220+HL-PO-88340+9'
DTM+137:20261012:102'
DTM+2:20261026:102'
RFF+PD:PROMO-4471'
NAD+BY+5012345000008::9'
NAD+SU+5098765000002::9'
NAD+DP+5012345000107::9'
CUX+2:GBP:9'
LIN+1++5098765100047:SRV'
IMD+F++:::ENAMEL ROASTING TIN SET'
QTY+21:240'
QTY+192:24'
PRI+AAA:7.20::PRP'
LIN+2++5098765100054:SRV'
IMD+F++:::SILICONE BAKING MAT'
QTY+21:120'
PRI+AAA:3.10::PRP'
UNS+S'
CNT+2:2'
UNT+21+1'
UNZ+1+HLS000467'"
/>

What to check on a promotional order:

- **`RFF+PD`** is the promotion deal number. Carry it through to your invoice, because promotional pricing is usually reconciled against it.
- **`PRI+AAA:7.20::PRP'`** is still the net price you will be paid; `PRP` in the price specification position flags it as promotional. If it differs from your price list, that is expected for the promotion period, not a pricing error to reject.
- **`QTY+192:24'`** is a free goods quantity: pick and despatch it, but do not invoice it at the line price.
- **Header `DTM+15`** (promotion start) is only used when there is no promotion reference. With `RFF+PD` present, the dates live in your promotion agreement.

## Example 4: order with a line allowance and order totals

Some buyers show how the net price was reached: a list price, a discount and the resulting net price, with order totals in the summary.

<EdifactSample
  title="Order with a 5% trade discount on one line"
  description="Line 1 carries the net price (PRI+AAA), the list price for information (PRI+AAF), and an ALC/PCD/MOA allowance group. MOA+79 and MOA+260 give the order totals."
  label="EANCOM 2002 D.01B"
  raw="UNA:+.? '
UNB+UNOC:3+5012345000008:14+5098765000002:14+261012:0730+HLS000468++ORDERS'
UNH+1+ORDERS:D:01B:UN:EAN010'
BGM+220+HL-PO-88355+9'
DTM+137:20261012:102'
DTM+2:20261020:102'
RFF+CT:HL-CT-2026-014'
NAD+BY+5012345000008::9'
NAD+SU+5098765000002::9'
NAD+DP+5012345000107::9'
CUX+2:GBP:9'
LIN+1++5098765100023:SRV'
QTY+21:60'
MOA+203:558.60'
PRI+AAA:9.31'
PRI+AAF:9.80'
ALC+A+++1+TD'
PCD+3:5'
MOA+204:29.40'
LIN+2++5098765100016:SRV'
QTY+21:120'
MOA+203:780.00'
PRI+AAA:6.50'
UNS+S'
MOA+79:1338.60'
MOA+260:29.40'
CNT+2:2'
UNT+26+1'
UNZ+1+HLS000468'"
/>

On line 1, `ALC+A+++1+TD'` is an allowance (`A`), calculation step 1, of type trade discount (`TD`). `PCD+3:5'` makes it 5 percent and `MOA+204:29.40'` gives the amount (5% of 60 x 9.80). `PRI+AAF:9.80'` is the list price for information, `PRI+AAA:9.31'` the net price that counts, and `MOA+203:558.60'` the line amount. In the summary, `MOA+79` totals the line amounts and `MOA+260` the allowances. Because `PRI+AAA` is already net, a mapper that applies the `ALC` discount again will under-price the order by 5%. Map the allowance to a separate, informational field.

## ORDERS vs the X12 850

| Data | EDIFACT ORDERS | X12 850 |
|---|---|---|
| Order number | `BGM` second element | `BEG03` |
| Order type | `BGM` document code (`220`, `221`, `224`) | `BEG02` (`SA`, `BK`, `DS` and others) |
| Original / replace | `BGM` message function (`9`, `5`) | `BEG01` (`00`, `05`) |
| Order date | `DTM+137` | `BEG05` |
| Requested delivery | `DTM+2` | `DTM*002` |
| Buyer, supplier, ship-to | `NAD+BY`, `NAD+SU`, `NAD+DP` | `N1*BY`, `N1*SE` or `N1*VN`, `N1*ST` |
| Party ID | GLN with agency `9` | Qualifier in `N103` (`UL` for GLN, `92`, `1`) |
| Line item | `LIN` + `PIA` + `QTY` + `PRI` | `PO1` (one segment) |
| Product ID | GTIN in `LIN` (`SRV`) | `PO106` to `PO109` (`UP`, `VN`, `IN`) |
| Description | `IMD` | `PID` |
| Split delivery | `LOC+7` / `QTY+11` per line | `SDQ` |
| Allowance | `ALC` + `PCD` / `MOA` | `SAC` |
| Line count | `CNT+2` | `CTT01` |
| Currency | `CUX` | `CUR` |

The structural difference is that X12 packs a line into one `PO1` segment by position, while EDIFACT uses a group of small qualified segments. At the business level the two map cleanly, which is how one system can take both. See the [EDI 850 guide](/guides/edi/850-purchase-order) for the X12 side and [EDIFACT explained](/guides/edi/edifact) for the envelope differences (`UNB`/`UNZ` against `ISA`/`IEA`).

## UK retailer ORDERS requirements

UK grocers split between EANCOM ORDERS and the older TRADACOMS order file, and some run both. These are the points that shape your ORDERS mapping. Specs change, so confirm the current version with each retailer during onboarding.

### Tesco

- Purchase orders arrive as EANCOM ORDERS or as TRADACOMS `ORDHDR`, depending on your setup, so check which one your account uses before you build.
- Tesco trades over OpenText's network (formerly GXS Trading Grid). Connect directly or through a provider that is already connected.
- Expect to pass testing with Tesco's EDI onboarding team before the first live order.

See the [Tesco EDI requirements](/edi-compliance/tesco) page for the full message set.

### Morrisons

- Morrisons trades EDIFACT D96A: ORDERS, [ORDCHG](/guides/edi/edifact-ordchg), [DESADV](/guides/edi/edifact-desadv) and [INVOIC](/guides/edi/edifact-invoic).
- Purchase order amendments arrive as ORDCHG. Apply each one to the open order before you pick, or you will ship the original quantities.
- Connect through OpenText's TRADANET network or a direct AS2 connection, then pass Supplier Onboarding Verification testing and a live-proving phase.

See the [Morrisons EDI requirements](/edi-compliance/morrisons) page.

### Marks & Spencer

- M&S sends purchase orders and expects an [order response](/guides/edi/edifact-ordrsp) back.
- Whether your category trades EDIFACT or TRADACOMS varies, so confirm it with M&S before mapping.
- Testing covers business scenarios such as different delivery types, so include them in your sample orders.

See the [Marks & Spencer EDI requirements](/edi-compliance/marks-and-spencer) page.

### Retailers that order in TRADACOMS

[Sainsbury's](/edi-compliance/sainsburys), [Asda](/edi-compliance/asda), [Ocado](/edi-compliance/ocado), [Waitrose](/edi-compliance/waitrose), [Boots](/edi-compliance/boots) and the [Co-op](/edi-compliance/co-op) send purchase orders as TRADACOMS order files rather than EANCOM ORDERS. The [TRADACOMS ORDHDR guide](/guides/edi/tradacoms-ordhdr) covers that file line by line, and maps each field to its ORDERS equivalent.

## Common ORDERS errors and how to fix them

| Problem | What you see | Fix |
|---|---|---|
| Unescaped apostrophe | A store name like `O'BRIEN` ends the segment early; the next "segment" has a nonsense tag | The sender must write `O?'BRIEN`. On receipt, flag segments with invalid tags rather than guessing |
| Wrong UNT count | Partner rejects the interchange, or a CONTRL comes back with an error | UNT counts every segment from UNH to UNT inclusive. Off-by-two errors (forgetting UNH and UNT) are the classic mistake |
| CNT does not match LIN | `CNT+2:3` but only two `LIN` segments | The message was truncated or built wrongly. Reject it and ask for a resend; do not import a partial order |
| GTIN only in PIA | `LIN+1'` with the GTIN in `PIA+5` | Read both positions. Use `LIN` first, `PIA+5` as fallback |
| Pack and unit confusion | `QTY+21:10` on a case GTIN imported as 10 units | Check whether the GTIN is the consumer unit or the case. Hold both in your item master and convert before the ERP |
| Decimal mark | Prices parsed as 650 instead of 6.50 | Without a UNA, syntax version 3 defaults to a comma decimal mark. Read the UNA, and accept both `.` and `,` if your partner's guide allows |
| Split totals wrong | Store quantities add to 30 but the line says 36 | EANCOM requires them to match. Query the buyer before picking |
| Allowance applied twice | Invoice under the order value by the discount | `PRI+AAA` is already net. Treat `ALC` in ORDERS as information |
| Unknown GLN | `NAD+DP` with a GLN not in your master data | New stores open all the time. Hold the order, request the address, add the GLN, release |

Paste a failing file into the [EDIFACT inspector](/edifact-inspector) to see which of these applies: it checks UNT, UNZ and CNT counts, GTIN and GLN check digits, dates and segment tags.

## Testing and onboarding checklist

Before going live with a new ORDERS partner:

1. **Get the implementation guide.** Note the directory (`D:96A` or `D:01B`), the EANCOM association code, the character set (`UNOA` or `UNOC`) and whether the partner sends a UNA.
2. **Exchange GLNs.** Confirm the interchange GLNs in UNB, and get the full list of buyer, invoicee and delivery party GLNs with addresses.
3. **Load the item master.** Every GTIN the partner may order, with its pack size and whether it is a consumer unit or a case.
4. **Agree on responses.** Is ORDRSP required, and within what time? Is a CONTRL expected for every interchange?
5. **Ask for sample files** covering a standard order, a split delivery, a promotional order and a replacement (`BGM` function `5`).
6. **Run every sample through a validator** and your mapping, then compare the ERP sales order line by line with the file.
7. **Test the edge cases**: escaped characters in names, a GLN you do not know, a GTIN you do not stock, a line with a zero quantity.
8. **Run parallel** for the first live orders: check each one manually against the ERP before trusting automation.


## Frequently Asked Questions

### What does BGM+220 mean?

`220` is the UN/EDIFACT document name code for an order. It tells the receiver the message is a standard purchase order rather than, for example, a blanket order (`221`), a rush order (`224`) or a call-off (`226`). The second element is the buyer's order number and the third is the message function, usually `9` for an original.

### What is the difference between ORDERS D96A and D01B?

They are two directory releases of the same message. D.96A underlies EANCOM 1997 and D.01B underlies EANCOM 2002. The core segments (BGM, DTM, NAD, LIN, QTY, PRI) work the same way in both, but code lists and some segment groups differ, so map to the version your partner puts in the UNH.

### How do I cancel an EDIFACT order?

The buyer sends an ORDCHG (purchase order change) with BGM document code `230` and function `1` (cancellation), referencing the original order number. ORDERS itself has no cancellation function, though a buyer can replace an order with `BGM` function `5`. See the [ORDCHG guide](/guides/edi/edifact-ordchg).

### Do I need a GLN to receive EDIFACT orders?

For EANCOM-based retail partners, nearly always. They identify you in the UNB and NAD segments by GLN. UK companies get GLNs through GS1 UK membership. See GS1's [GLN overview](https://www.gs1.org/standards/id-keys/gln).

### Can one ORDERS message deliver to several locations?

Yes. Each line can carry up to 9,999 `LOC+7` groups, each with a split quantity and date. GS1 still recommends one order per delivery location where possible, and many partners send one ORDERS per store or depot for that reason.

### Is ORDERS the same as the TRADACOMS order?

No. TRADACOMS is a separate, older UK standard. Its order is a file of messages (ORDHDR, ORDERS, ORDTLR) with different syntax. See [TRADACOMS ORDHDR](/guides/edi/tradacoms-ordhdr) and [TRADACOMS file types](/guides/edi/tradacoms-file-types).

### How do I respond to an EDIFACT order?

With an [ORDRSP](/guides/edi/edifact-ordrsp) if the partner requires one: BGM `231`, quoting the order number in `RFF+ON`, with `29` for accepted, `4` for changed or `27` for not accepted. A CONTRL may also be required to confirm receipt of the interchange.

## Related guides

- **[EDIFACT explained](/guides/edi/edifact)**: syntax, envelopes and EDIFACT vs X12
- **[EDIFACT message types](/guides/edi/edifact-message-types)**: every message in the order-to-cash cycle
- **[EDIFACT ORDRSP](/guides/edi/edifact-ordrsp)**: accept, change or reject the order
- **[EDIFACT ORDCHG](/guides/edi/edifact-ordchg)**: buyer changes and cancellations
- **[EDIFACT DESADV](/guides/edi/edifact-desadv)**: the despatch advice that follows
- **[EDIFACT INVOIC](/guides/edi/edifact-invoic)**: the invoice
- **[EDIFACT CONTRL](/guides/edi/edifact-contrl)** and **[APERAK](/guides/edi/edifact-aperak)**: syntax and application acknowledgements
- **[EDIFACT PRICAT](/guides/edi/edifact-pricat)**: the price catalogue that orders are priced from
- **[EDI 850 purchase order](/guides/edi/850-purchase-order)**: the X12 counterpart

## Sources

- [EANCOM 2002 S3: ORDERS purchase order message](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part2/orders/toc.htm), GS1 (message structure, segment layouts and code lists used throughout this guide)
- [EANCOM 2002 S3: ORDERS BGM segment](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part2/orders/054.htm), GS1
- [EANCOM 2002 S3: ORDERS PRI segment](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part2/orders/0561.htm), GS1 (net calculation price rule)
- [UN/EDIFACT D.01B ORDERS message](https://service.unece.org/trade/untdid/d01b/trmd/orders_c.htm), UNECE
- [Global Location Number (GLN)](https://www.gs1.org/standards/id-keys/gln), GS1

Check your partner's sample orders in the free [EDIFACT inspector](/edifact-inspector), or see how OrderSync automates [X12 850 purchase orders](/guides/edi/850-purchase-order) and EDIFACT orders into your ERP.