# EDIFACT ORDCHG: Order Change Message Guide

> EDIFACT ORDCHG purchase order change explained: BGM+230, LIN action codes for added, deleted and changed lines, four live EANCOM examples and the 860 mapping.

<QuickAnswer>
EDIFACT ORDCHG is the purchase order change request, the equivalent of the X12 860. The buyer sends it to change or cancel an order already sent as ORDERS. BGM+230 identifies the message, RFF+ON names the original order, and each LIN carries an action code: 1 added, 2 deleted, 3 changed or 11 not amended.
</QuickAnswer>

Orders change. The buyer's forecast moves, a store promotion gets pulled, a product is discontinued. ORDCHG is how those changes reach you in a form your system can apply automatically, instead of as an email saying "can you add two more cases to Tuesday's order". Get it wrong and you pick the old quantity, ship to the old date and end up with a short-shipment or late-delivery deduction for an order you thought you had filled perfectly.

This guide follows the [GS1 EANCOM 2002 ORDCHG](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part2/ordchg/toc.htm) layout (subset version EAN007, directory D.01B). The examples continue the fictional order HL-PO-88231 from the [ORDERS guide](/guides/edi/edifact-orders), after the supplier's [ORDRSP](/guides/edi/edifact-ordrsp) accepted line 1, part-shipped line 2 and rejected line 3.

<EDIGuideCTA
  badge="For EDIFACT ORDCHG"
  transactionType="860"
  headline="Apply order changes before you pick the old order"
  body="Paste an ORDCHG into the free EDIFACT inspector to see every line's action code, quantity and date checked. OrderSync processes EDIFACT, EANCOM and TRADACOMS alongside X12, PDF, CSV and email, and applies order changes to the open order in your ERP."
  secondaryHref="/edifact-inspector"
  secondaryLabel="Try the free EDIFACT inspector"
/>

## What is an EDIFACT ORDCHG?

**ORDCHG (purchase order change request) is the UN/EDIFACT message a buyer sends to change or cancel a purchase order the supplier has already received.** It quotes the original order number and lists only what the buyer wants to change, line by line, with an action code on each `LIN` saying whether the line is new, deleted, changed or unchanged.

GS1 gives ORDCHG two jobs:

1. **A buyer-initiated change.** The buyer wants more, less, a different date, an extra product or a cancelled line.
2. **Confirmation of a supplier's proposal.** When the supplier's ORDRSP changes a line (a lower quantity, a later date), the buyer can confirm the amended terms with an ORDCHG.

## Rules that define the message

The EANCOM principles are short and strict. Learn these and most ORDCHG problems go away:

- **Three things can never change:** the order number, the buyer and supplier identities, and the line item numbers. To change any of them, cancel the order and send a new one.
- **Minimum content:** the mandatory segments, a `NAD` for the buyer and one for the supplier, and one `RFF` in segment group 1 identifying the order being changed.
- **Re-send everything below a changed LIN.** If any segment under a line changes, all segments under that line are transmitted again. The data under `LIN` with action 3 replaces what you hold for that line.
- **Re-sending unchanged data is not an error.** A partner may send action `11` lines purely for information.

## Where ORDCHG sits in the order-to-cash flow

| Step | Message | Sent by | X12 equivalent |
|---|---|---|---|
| 1 | [ORDERS](/guides/edi/edifact-orders) | Buyer | 850 |
| 2 | [ORDRSP](/guides/edi/edifact-ordrsp) | Supplier | 855 |
| 3 | **ORDCHG** | Buyer, any time before despatch | **860** |
| 4 | ORDRSP to the change (if the partner requires it) | Supplier | 865 |
| 5 | [DESADV](/guides/edi/edifact-desadv) | Supplier | 856 |
| 6 | [INVOIC](/guides/edi/edifact-invoic) | Supplier | 810 |

EANCOM has no separate "change acknowledgment" message. A supplier responding to an ORDCHG sends another ORDRSP. The buyer can ask for one explicitly in the fourth element of `BGM` (response type code `AC` acknowledge with detail and change, `AI` acknowledge only changes, `NA` no acknowledgement needed).

Timing matters more than anything else here. An ORDCHG that arrives after you have picked, or worse after the DESADV has gone, creates a mismatch between order, shipment and invoice. Agree a cut-off with each partner and make your system flag late changes rather than silently applying them.

## Example 1: quantity change

Harbour Lane Stores raises line 1 from 120 to 144 chopping boards. Only the changed line is sent, with every segment under it re-transmitted.

<EdifactSample
  title="ORDCHG increasing a line quantity"
  description="Line 1 changed (action 3) from 120 to 144; LIN detail re-sent in full and tied back to the original line."
  label="EANCOM D.01B EAN007"
  raw="UNA:+.? '
UNB+UNOC:3+5012345000008:14+5098765000002:14+261012:1015+HLS000462++ORDCHG'
UNH+1+ORDCHG:D:01B:UN:EAN007'
BGM+230+HL-PC-88231-1+4'
DTM+137:20261012:102'
RFF+ON:HL-PO-88231'
DTM+171:20261011:102'
NAD+BY+5012345000008::9'
NAD+SU+5098765000002::9'
LIN+1+3+5098765100016:SRV'
PIA+1+KV-1001:SA'
QTY+21:144'
PRI+AAA:6.50'
RFF+ON:HL-PO-88231:1'
UNS+S'
CNT+2:1'
UNT+15+1'
UNZ+1+HLS000462'"
/>

| Segment | What it says |
|---|---|
| `BGM+230+HL-PC-88231-1+4'` | Document 230 (purchase order change request), change number HL-PC-88231-1, function 4 (change) |
| `RFF+ON:HL-PO-88231'` | The order being changed |
| `DTM+171:20261011:102'` | Date of that order |
| `LIN+1+3+5098765100016:SRV'` | Line 1, action 3 (changed), same GTIN |
| `PIA+1+KV-1001:SA'` | Supplier's article number, re-sent because the line changed |
| `QTY+21:144'` | The new ordered quantity. It replaces 120; it is not "add 144" |
| `PRI+AAA:6.50'` | Net price, re-sent unchanged |
| `RFF+ON:HL-PO-88231:1'` | Ties this line to line 1 of the original order |
| `CNT+2:1'` | One LIN line in the change |

**QTY in ORDCHG is the new total, not a delta.** This is the most common mapping mistake. If the buyer wants 24 more, the message says 144. EANCOM does also define `QTY+18` (previous quantity), which some partners include so you can check you are changing the right baseline.

## Example 2: delivery date change

The DC has lost its Friday slot. Lines 1 and 2 move to Monday 19 October. Each changed line repeats its full detail, now with a line-level `DTM+2` requested delivery date.

<EdifactSample
  title="ORDCHG moving the delivery date on two lines"
  description="Lines 1 and 2 changed (action 3) with a new DTM+2 requested delivery date; quantities and prices re-sent."
  label="EANCOM D.01B EAN007"
  raw="UNA:+.? '
UNB+UNOC:3+5012345000008:14+5098765000002:14+261013:0830+HLS000465++ORDCHG'
UNH+1+ORDCHG:D:01B:UN:EAN007'
BGM+230+HL-PC-88231-2+4'
DTM+137:20261013:102'
RFF+ON:HL-PO-88231'
DTM+171:20261011:102'
NAD+BY+5012345000008::9'
NAD+SU+5098765000002::9'
NAD+DP+5012345000107::9'
LIN+1+3+5098765100016:SRV'
PIA+1+KV-1001:SA'
QTY+21:144'
DTM+2:20261019:102'
PRI+AAA:6.50'
RFF+ON:HL-PO-88231:1'
LIN+2+3+5098765100023:SRV'
PIA+1+KV-1002:SA'
QTY+21:60'
DTM+2:20261019:102'
PRI+AAA:9.80'
RFF+ON:HL-PO-88231:2'
UNS+S'
CNT+2:2'
UNT+23+1'
UNZ+1+HLS000465'"
/>

| Segment | What it says |
|---|---|
| `BGM+230+HL-PC-88231-2+4'` | A second change to the same order, with its own change number |
| `NAD+DP+5012345000107::9'` | Delivery point, sent as clarification. Optional in a change |
| `QTY+21:144'` | Line 1 keeps the quantity from the first change |
| `DTM+2:20261019:102'` | New requested delivery date for the line |

Two things to notice. First, line 1 carries 144, the quantity from change 1. Changes build on each other, so process them in order. Second, GS1 also allows `DTM+2` in the header to move the date for the whole order. Some partners prefer that; others always send dates per line. Support both.

## Example 3: cancel a line and add a substitute

The supplier's ORDRSP rejected line 3 (cotton tea towels). The buyer deletes it and adds a substitute product as a new line 4.

<EdifactSample
  title="ORDCHG deleting one line and adding another"
  description="Line 3 deleted (action 2) with only its reference; new line 4 added (action 1) with full detail."
  label="EANCOM D.01B EAN007"
  raw="UNA:+.? '
UNB+UNOC:3+5012345000008:14+5098765000002:14+261012:1120+HLS000463++ORDCHG'
UNH+1+ORDCHG:D:01B:UN:EAN007'
BGM+230+HL-PC-88231-3+4'
DTM+137:20261012:102'
RFF+ON:HL-PO-88231'
DTM+171:20261011:102'
NAD+BY+5012345000008::9'
NAD+SU+5098765000002::9'
LIN+3+2+5098765100030:SRV'
RFF+ON:HL-PO-88231:3'
LIN+4+1+5098765100207:SRV'
PIA+1+KV-1020:SA'
IMD+F++:::LINEN TEA TOWEL 2 PACK'
QTY+21:48'
DTM+2:20261019:102'
PRI+AAA:3.10'
UNS+S'
CNT+2:2'
UNT+18+1'
UNZ+1+HLS000463'"
/>

| Segment | What it says |
|---|---|
| `LIN+3+2+5098765100030:SRV'` | Line 3, action 2 (deleted). EANCOM says no other line data is needed |
| `RFF+ON:HL-PO-88231:3'` | Which original line is being deleted |
| `LIN+4+1+5098765100207:SRV'` | New line 4, action 1 (added). All required data must be sent, as for a new order line |
| `IMD+F++:::LINEN TEA TOWEL 2 PACK'` | Description of the new product |
| `QTY+21:48'`, `PRI+AAA:3.10'` | Quantity and price for the new line |

The new line gets a new number. Line numbers cannot be reused or changed, so "replace line 3 with a different product" is always a delete plus an add.

## Example 4: cancel the whole order

BGM message function `1` cancels the entire referenced order. EANCOM still requires the mandatory segments and both parties.

<EdifactSample
  title="ORDCHG cancelling a complete order"
  description="BGM function 1: cancel the order quoted in RFF+ON. No line detail needed."
  label="EANCOM D.01B EAN007"
  raw="UNA:+.? '
UNB+UNOC:3+5012345000008:14+5098765000002:14+261012:1405+HLS000464++ORDCHG'
UNH+1+ORDCHG:D:01B:UN:EAN007'
BGM+230+HL-PC-88290-1+1'
DTM+137:20261012:102'
RFF+ON:HL-PO-88290'
DTM+171:20261010:102'
NAD+BY+5012345000008::9'
NAD+SU+5098765000002::9'
UNS+S'
UNT+9+1'
UNZ+1+HLS000464'"
/>

Not every partner uses ORDCHG for cancellations. Some cancel through a portal or by email and expect nothing in EDI. Ask.

## ORDCHG segment reference

Status and repeats follow the EANCOM 2002 message structure chart. M is mandatory, C conditional.

| Segment | Name | Status | Repeats | Carries | X12 860 equivalent |
|---|---|---|---|---|---|
| UNH | Message header | M | 1 | `ORDCHG:D:01B:UN:EAN007` | ST |
| BGM | Beginning of message | M | 1 | 230, change number, function, response request | BCH |
| DTM | Date/time | M | 35 | 137 message date; 2, 63, 64 delivery dates | DTM |
| PAI, ALI, FTX | Payment, additional info, free text | C | 1, 5, 99 | Header clarifications | NTE |
| RFF (SG1) | Reference | C | 9999 | ON order being changed, POR response, PP change | BCH, REF |
| NAD (SG3) | Name and address | C | 99 | BY and SU required; DP, IV, SN optional | N1 |
| CUX (SG8) | Currencies | C | 5 | Currency | CUR |
| PAT (SG9) | Payment terms | C | 10 | Terms | ITD |
| TDT, TOD | Transport, delivery terms | C | 10, 5 | Carrier, Incoterms | TD5, FOB |
| ALC (SG20) | Allowance or charge | C | 99 | Header allowances | SAC |
| LIN (SG27) | Line item | C | 200000 | Line number, action code, GTIN | POC |
| PIA | Additional product id | C | 25 | Supplier or buyer item number | POC |
| IMD | Item description | C | 99 | Description | PID |
| QTY | Quantity | C | 99 | 21 new ordered quantity, 18 previous | POC |
| DTM | Line date | C | 35 | 2 requested delivery, 61 cancel-by | DTM |
| QVR | Quantity variance | C | 1 | Variance and reason | |
| PRI (SG32) | Price | C | 25 | AAA net, AAB gross | POC |
| RFF (SG33) | Line reference | C | 9999 | ON with original line number | REF |
| LOC, QTY, DTM (SG37) | Split delivery | C | 9999 | Quantity per location | SDQ |
| UNS | Section control | M | 1 | `S` | |
| MOA, CNT | Totals | C | 12, 10 | 2 = number of LIN lines | AMT, CTT |
| UNT | Message trailer | M | 1 | Segment count | SE |

## Code tables

### BGM message function (third element)

| Code | Meaning in EANCOM ORDCHG |
|---|---|
| `4` | Change: specified changes at line level to the referenced order |
| `1` | Cancellation of the whole referenced order |
| `9` | Original transmission of a change |
| `31` | Copy for a third party, for information |
| `42` | Confirmation of a change already made by other means, such as phone or email |

### LIN action code (second element)

| Code | Meaning | What your system should do |
|---|---|---|
| `1` | Added | Create a new order line. All required data is present |
| `2` | Deleted | Cancel the line referenced in RFF+ON. No other data needed |
| `3` | Changed | Replace everything held for the line with the data sent |
| `11` | Not amended | Information only. Change nothing |

### Line DTM qualifiers you will see

| Qualifier | Meaning |
|---|---|
| `2` | Delivery date/time, requested |
| `10` | Shipment date/time, requested |
| `63` / `64` | Latest / earliest delivery date |
| `61` | Cancel if not delivered by this date |

## ORDCHG vs the X12 860

| Data | EDIFACT ORDCHG | X12 860 |
|---|---|---|
| Change document | `BGM+230` with a change number | `BCH` |
| Change vs cancel | `BGM` function `4` or `1` | `BCH01` purpose code |
| Original PO number and date | `RFF+ON` with `DTM+171` | `BCH` PO number and date |
| Line action | `LIN` action `1`, `2`, `3`, `11` | `POC02` change code (for example AI, DI, QI, QD, PC, NC) |
| New quantity | `QTY+21` (new total) | `POC03` |
| New price | `PRI` | `POC05` |
| Dates | `DTM+2` header or line | `DTM` |
| Line count | `CNT+2` | `CTT01` |

The X12 860 tells you what kind of change happened at line level (quantity increase, price change and so on). ORDCHG only says "changed" and gives you the new state of the line. To work out what changed, compare the incoming line with the one you hold. That comparison is worth building anyway, because it is the only reliable way to catch a changed price hidden inside a line you thought was a date change. See the [EDI 860 guide](/guides/edi/860-purchase-order-change) for the X12 codes.

## Common ORDCHG errors and fixes

- **Treating QTY as a delta.** `QTY+21` is the new ordered quantity. Adding it to the old figure doubles the line.
- **Processing changes out of order.** Two ORDCHGs for the same order must be applied in sequence. Use the BGM change number and `DTM+137` to order them, and hold a change that arrives before its predecessor.
- **Matching lines by position instead of reference.** Use `RFF+ON:<order>:<line>` under each `LIN` to find the original line. Change messages often carry only one or two lines, so line 1 in the change may be line 7 of the order.
- **Ignoring action 11.** Lines marked "not amended" must not overwrite anything, even if their data looks different from what you hold. Flag the difference instead.
- **Accepting changes after despatch.** If the DESADV has gone, the change cannot be applied to that shipment. Reply through ORDRSP or the partner's agreed channel.
- **Changing what cannot change.** An ORDCHG that alters the buyer GLN or tries to renumber lines breaks the EANCOM rules. Reject it back to the buyer, usually through [APERAK](/guides/edi/edifact-aperak).

## Testing checklist

1. Confirm the partner sends ORDCHG at all, and whether cancellations come as ORDCHG function `1` or outside EDI.
2. Ask whether they send only changed lines, or every line with action `11` on the unchanged ones.
3. Ask whether they expect an ORDRSP in reply, and in what time.
4. Test each action code: add, delete, change quantity, change date, change price.
5. Test two changes to the same order in sequence, and a change arriving after despatch.
6. Validate segment counts and GTIN check digits in the [EDIFACT inspector](/edifact-inspector).
7. Agree the cut-off after which changes are refused.

OrderSync applies ORDCHG to the open order it already holds, shows the before and after for every line, and holds changes that arrive too late for a person to decide.

## Frequently Asked Questions

### What is ORDCHG in EDI?

ORDCHG is the UN/EDIFACT purchase order change request. The buyer sends it to change or cancel an order already sent as ORDERS. It identifies the original order in RFF+ON and gives each changed line an action code. It is the EDIFACT equivalent of the X12 860.

### What does BGM+230 mean?

230 is the document name code for a purchase order change request. The third element of BGM gives the message function: 4 for a change, 1 to cancel the whole order.

### What are the LIN action codes in ORDCHG?

The second element of LIN is the action request: 1 added, 2 deleted, 3 changed and 11 not amended. A changed line replaces everything previously held for that line.

### How do I cancel a single line in ORDCHG?

Send that line with action code 2, for example `LIN+3+2+5098765100030:SRV'`, followed by `RFF+ON` quoting the order number and original line number. No other line data is needed.

### How do you respond to an ORDCHG?

With an ORDRSP that references the change and gives the status of each line. EANCOM has no separate change acknowledgment message. Whether a response is required, and how quickly, is set by the trading partner.

### What is the difference between ORDCHG and ORDRSP?

ORDCHG comes from the buyer and asks for a change. ORDRSP comes from the supplier and responds to an order or a change, accepting, amending or rejecting it.

### Can ORDCHG change the delivery address?

Yes, within limits. A changed NAD+DP in the header or split deliveries at line level (LOC, QTY and DTM) can redirect goods. The buyer and supplier identities cannot change.

## Related guides

- **[EDIFACT explained](/guides/edi/edifact)**: syntax, envelopes and the full X12 mapping
- **[EDIFACT ORDERS](/guides/edi/edifact-orders)**: the order that ORDCHG modifies
- **[EDIFACT ORDRSP](/guides/edi/edifact-ordrsp)**: the supplier's response to an order or a change
- **[EDIFACT DESADV](/guides/edi/edifact-desadv)**: the despatch advice that should reflect the changed order
- **[EDIFACT RECADV](/guides/edi/edifact-recadv)**: what the buyer reports after receipt
- **[EDIFACT message types](/guides/edi/edifact-message-types)**: every EDIFACT message and its X12 equivalent
- **[EDI 860 purchase order change](/guides/edi/860-purchase-order-change)**: the X12 counterpart

## Sources

- [EANCOM 2002 S3: ORDCHG purchase order change request message](https://www.gs1.org/sites/default/files/docs/eancom/ean02s3/part2/ordchg/toc.htm), GS1
- [UN/EDIFACT D.01B ORDCHG message](https://service.unece.org/trade/untdid/d01b/trmd/ordchg_c.htm), UNECE
- [Introducing UN/EDIFACT](https://unece.org/trade/uncefact/introducing-unedifact), UNECE

Paste any ORDCHG into the free [EDIFACT inspector](/edifact-inspector) to see each line's action code and check the counts before you apply it.