The BGM segment opens every EDIFACT business message and identifies what the message is and what it does. Element 1 is the document type code (220=purchase order, 380=invoice, 351=despatch advice). Element 2 is the document number (your PO number, invoice number etc). Element 3 is the message function code: 9=original, 5=replace, 1=cancel, 4=change.
BGMHover any part of the segment to see what it is. Open What your system receives to see the JSON or XML CleanEDI delivers.
BGM+220+PO-12345+9'Purchase order number PO-12345, sent as original.
| 1 | Document type | 220Purchase order |
| 2 | Document number | PO-12345 |
| 3 | Message function | 9Original |
{
"documentType": "purchaseOrder",
"documentNumber": "PO-12345",
"status": "original"
}Example shape. In production the field names and structure follow your own API contract.
Elements are separated by + and their parts by :. Positions match the explainer, so 2.3 is the third part of the second element.
| Position | Element | Parts |
|---|---|---|
| 1 | Document type | 1.1 Code |
| 2 | Document number | Single value |
| 3 | Message function | 3.1 Code |
| 4 | Response type | Single value |
| Code | Meaning |
|---|---|
9 | Price/sales catalogue |
35 | Inventory report |
220 | Purchase order |
221 | Blanket order |
224 | Rush order |
226 | Call-off order |
231 | Purchase order response |
351 | Despatch advice |
352 | Despatch advice (EANCOM) |
380 | Commercial invoice |
381 | Credit note |
383 | Debit note |
393 | Factored invoice |
632 | Goods receipt |
| Code | Meaning |
|---|---|
1 | Cancellation |
4 | Change |
5 | Replace |
7 | Duplicate |
9 | Original |
27 | Not accepted |
29 | Accepted without amendment |
31 | Copy |
Common EANCOM and UN/EDIFACT values. Your trading partner's implementation guide is the final word on which codes they send.
Have a real message with BGM in it? The explainer breaks down every segment and runs in your browser.
Explain my message