EDI 850 purchase order
An EDI 850 is the ANSI X12 transaction set for a purchase order: a structured electronic document a buyer sends a supplier to order goods, carrying the same items, quantities, prices and delivery details as a paper or PDF order.
What an 850 contains
An 850 is made of segments, each a line of delimited values. The ones that matter most when an order becomes a sales order:
- BEG opens the order with the purchase order number and date.
- N1 loops name the parties, such as the buyer, the bill-to and the ship-to, each with an address.
- PO1 is one order line: quantity, unit of measure, unit price, and one or more product identifiers. A qualifier says which kind of identifier each one is, for example
BPfor the buyer’s part number,VPfor the vendor’s part number orUPfor a UPC. - PID carries a free-text item description.
- DTM gives dates such as the requested delivery date.
- CTT closes the order with the number of lines.
What comes back
A supplier normally answers an 850 with a 997 functional acknowledgment, which only confirms the file arrived and could be read. Whether the order is accepted is a separate document, the EDI 855. The EDI 856 and EDI 810 follow when the goods ship and are billed.
Why 850s still need checking
An 850 is structured, but structured is not the same as correct. Every trading partner publishes its own implementation guide saying which segments and qualifiers it uses, so two customers’ 850s differ. And the content can still be wrong for your system: a buyer’s part number with no cross-reference, a unit of measure you do not sell in, or a price that is not the contract price.
How Runtara handles it
EDI is set up by our team during implementation, working from each trading partner’s document specs and test files. Incoming 850s are mapped to your ERP inside the workflow and validated before anything is written. Orders that match create ERP sales orders, and exceptions are held for a person. Each document is kept with its run record.