EDIFACT defines dozens of message types, each for a different business document. Here are the ones you are most likely to encounter, explained in plain English with the key segments you need to know.
ORDERSThe ORDERS message is how a buyer tells a supplier what they want to purchase. It contains the order number, the delivery date, the delivery location, and one or more line items each with a product identifier, quantity, and price.
When a retailer, wholesaler, or distributor places an order with you. This is usually the first message in a trading cycle.
BGMOrder number and document functionDTMOrder date and requested delivery dateNAD+BYBuyer name, address, and GLNNAD+SUSupplier name and GLNNAD+DPDelivery point addressLINLine item number and product GTINQTY+21Ordered quantityPRIUnit priceDESADVThe DESADV message is sent by the supplier to notify the buyer that goods have been despatched. It is the EDIFACT equivalent of a packing slip or advance ship notice (ASN). It tells the buyer what is coming, when it was shipped, how it is packed, and what SSCC barcodes are on the pallets or cartons.
When you need to tell your customer that you have shipped their order. Many buyers require this before the goods arrive so they can prepare their receiving area.
BGMDespatch advice numberDTM+11Despatch dateDTM+17Estimated delivery dateRFF+ONReference to the original purchase order numberNAD+SUSupplier detailsNAD+BYBuyer detailsNAD+DPDelivery pointPACPackage type and quantityPCI+33ESSCC barcode on the packageLINLine item shippedQTY+12Quantity despatchedINVOICThe INVOIC message is a request for payment. It references the original purchase order, lists the goods or services supplied with quantities and prices, and includes tax details and payment terms. It is the EDIFACT equivalent of a tax invoice.
When you need to bill your customer for goods or services you have supplied. Some trading partners require EDIFACT invoices instead of PDF invoices for automatic processing.
BGM+380Invoice number (380 = commercial invoice)DTM+137Invoice dateDTM+13Payment due dateRFF+ONOriginal purchase order numberNAD+SUSupplier (seller) detailsNAD+BYBuyer detailsTAXTax type and rate (GST, VAT etc)LINInvoice line itemQTY+47Invoiced quantityPRI+AAANet unit priceMOA+77Line item total amountMOA+9Total payable amountCONTRLThe CONTRL message is sent in response to any received EDIFACT message to confirm receipt and indicate whether the message was accepted or rejected. It is the EDIFACT equivalent of a read receipt, but with business meaning. A positive CONTRL means the message was received and syntactically valid. A negative CONTRL means there was a problem.
Most EDI platforms and trading partners require a CONTRL to be sent in response to every received message. If you receive an ORDERS, you should send back a CONTRL. Platforms like SPS Commerce and MessageXchange enforce this requirement.
UCIInterchange response, references the original UNBUCMMessage response, references the original UNHUCSSegment error, identifies a specific problem segmentORDRSPOrder ResponseSupplier to BuyerThe ORDRSP is a business-level response to an ORDERS message. While the CONTRL confirms technical receipt, the ORDRSP tells the buyer whether you can fulfil the order and on what terms. You can accept the order as-is, accept with changes (different quantity, different delivery date), or reject it with a reason.
RECADVReceiving AdviceBuyer to SupplierThe RECADV is sent by the buyer when they have physically received goods. It confirms what was actually received versus what was in the DESADV. Discrepancies in quantity or product can be flagged. This message is used to trigger payment in automatic invoice matching systems.
IFTMINInstruction MessageVariesThe IFTMIN is used in transport and logistics to give instructions to a carrier or freight forwarder. It is the EDIFACT equivalent of a booking request or transport instruction.
Use the free CleanEDI decoder to paste any EDIFACT message and get back a plain English breakdown of every segment. No account needed.
Try the decoderCleanEDI sits at the boundary and handles all of this for you. Your team works with clean JSON. No segment knowledge required.
See pricing