Definition
The ORDERS message transmits a complete purchase order in structured form. The header carries order number, order date, requested delivery date, delivery address and the parties involved. Each line then contains a LIN segment with the article identifier — in retail usually the GTIN — a QTY segment with the ordered quantity and a PRI segment with the agreed price, plus packaging and scheduling details. Because every field is normalised, the receiving system can post the order without interpretation. The supplier answers with ORDRSP, stating whether the order is confirmed in full, in part, or rejected.
Why it matters
ORDERS is where the value of an EDI connection shows up first: what used to arrive as a PDF and be retyped now sits in the ERP as an order seconds after it was sent — no typos, no queue time, nobody watching an inbox. At high order frequency this is the single largest lever in the whole process. The return direction matters just as much: the ORDRSP stops the buyer planning with quantities that will never ship. Automating only the inbound order while handling the response manually captures barely half the benefit.
How it works
Three things determine whether an ORDERS process runs cleanly. First, article matching: the GTIN in the order must resolve unambiguously to an article in your ERP — with variants, bundles and packaging units, this is the most common breaking point. Second, price validation: a price in the order that differs from the agreed price must surface automatically, not during invoice reconciliation weeks later. Third, the response window: in the vendor model the acknowledgement deadline is part of the agreement, and rejections or quantity changes belong in the ORDRSP, not in an email.
Real-world examples
• An ORDERS with 120 lines arrives overnight and is posted automatically; in the morning order processing sees only the five lines where stock is short. • The supplier confirms 118 lines in full via ORDRSP, one with a reduced quantity and one as a rejection — the buyer immediately replans with corrected figures. • The buyer moves the delivery date of a live order and sends an ORDCHG rather than a new ORDERS.
Common pitfalls
• **Matching articles on descriptions:** matching must run on GTIN or an agreed article number. Text-field matching breaks at the first assortment change. • **Automating only the inbound side:** without an automated ORDRSP the manual effort simply moves to the response, and the deadline becomes a risk. • **Waving through price differences:** a mismatched price in the order becomes an invoice dispute later. Validation belongs at the start, not the end. • **Treating changes as new orders:** an ORDCHG amends an existing order. Processing it as a fresh ORDERS creates duplicates.
Frequently asked
What is an ORDERS message?+
ORDERS is the EDIFACT message for a purchase order. It transmits a complete PO in structured form from the buyer's system to the supplier's — order number, delivery date, addresses, and article, quantity and price per line — so it can be posted as a sales order without manual entry.
What is the difference between ORDERS and ORDRSP?+
ORDERS is the buyer's purchase order; ORDRSP is the supplier's response to it. The ORDRSP states whether the order is accepted in full, with changed quantities or dates, or rejected. Only the two together form a closed order process.
What is the X12 equivalent of ORDERS?+
Transaction 850 (Purchase Order). The order response ORDRSP maps to 855 and the order change ORDCHG to 860. EDIFACT is used predominantly in Europe, X12 in North America.
How does an Amazon purchase order reach my ERP via EDI?+
In the vendor model Amazon sends the purchase order as an X12 850 or EDIFACT ORDERS over the agreed transport — typically AS2 or Amazon-hosted SFTP. A converter translates the message into your ERP's format, where it is posted as an order. The supplier replies with an acknowledgement within the agreed window.