BEG
Beginning segment: transaction purpose, PO type, PO number, and PO date.
EDI 850: Purchase Order
A buyer’s order to a supplier: the items, quantities, prices, dates, and ship-to locations. Buyer to supplier. This page covers what the 850 is for, the segments you meet when you open one, the documents it travels with, where it tends to go wrong, and how it moves over AS2 into your systems on Files.com, which receives, parses, validates, and routes it as configuration.
No credit card required · 7-day free trial · Live in minutes
#1 MFT vendor in Gartner Peer Insights
Trusted by 4,000+ companies
Every protocol included
What The 850 Is For
The 850 is the document most EDI relationships begin with. A retailer, distributor, or manufacturer sends it to a supplier to order goods, and it carries everything the paper purchase order used to: the PO number and date, the buyer and ship-to parties, each line item with its quantity, unit of measure, unit price, and product identifiers, and any terms, dates, or special instructions attached to the order.
Because it starts the cycle, the 850 anchors the documents that follow. The supplier acknowledges it with an 855, ships against it with an 856, and bills against it with an 810. Every one of those documents references the 850’s PO number, which is why a mismatch in that one field is the most common reason a downstream document rejects.
The Segments You Meet First
In document order, the segments that carry the 850's meaning. A partner's implementation guide says which are required and which fields each must hold.
REF
Reference identifiers such as a contract number, department, or vendor number.
DTM
Dates: requested ship date, requested delivery date, cancel-after date.
N1
A party: the buyer, the ship-to location, the bill-to, or the vendor, one loop per party.
PO1
A line item: quantity ordered, unit, unit price, and the product identifiers (UPC, buyer’s item number, vendor’s item number).
PID
A description of the item on the PO1 line above it.
CTT
Transaction totals: the number of PO1 lines, used to check the document arrived whole.
Where It Goes Wrong
Product identifiers are where 850s break. Buyers send their own item numbers, suppliers key on theirs, and a UPC that is off by a check digit lands an order in an exception queue. The second failure is dates: a requested-delivery DTM the supplier cannot meet has to come back as an 855 rejection or change, and a supplier who silently ships anyway creates a chargeback.
The Documents It Travels With
The 850 rarely moves alone. These are the documents that precede, answer, or settle it.
855 · Purchase Order Acknowledgment
The supplier’s answer to a purchase order: accepted, rejected, changed, or backordered, line by line.
See The 855856 · Ship Notice / Manifest (ASN)
The advance ship notice: what is in the shipment, how it is packed, and how it is labeled, sent before it arrives.
See The 856810 · Invoice
The supplier’s bill for goods or services delivered against a purchase order.
See The 810860 · Purchase Order Change Request (Buyer Initiated)
A buyer’s change to an order already sent: add, delete, or modify lines, quantities, prices, or dates.
See The 860997 · Functional Acknowledgment
The receipt that says an EDI transmission arrived and was parsed, with any syntax errors found.
See The 997How The 850 Moves On Files.com
A partner sends the 850 over AS2, SFTP, or FTPS, and it lands in that partner’s inbox folder on Files.com with the transport receipt recorded. From there it is a workflow, not a project: TransformScript parses the X12 natively into the JSON, CSV, or XML your ERP or WMS reads, content validation flags a document whose contents are wrong before anything ingests it, and an automation routes the result to the system and the people who act on it.
Outbound is the mirror image. Your system exports its record, TransformScript builds the 850 the partner’s guide specifies, and the file dropped in the partner’s outbox goes out over AS2 with automatic retries until the MDN confirms delivery. Every transmission in both directions is in the audit log, and delivery monitoring alerts when a 850 that was due never arrives. The full picture is on the EDI software page.
EDI 850 Questions
What teams ask about the 850 and how it moves on Files.com.
An EDI 850 is the X12 purchase order. A buyer sends it to a supplier to order goods, and it carries the PO number, the parties, and each line item with its quantity, price, and product identifiers. The supplier replies with an 855 acknowledgment and later an 856 ship notice and 810 invoice, each referencing the 850’s PO number.
The 850 places the order; the 860 changes it. A buyer sends an 860 Purchase Order Change Request to add, delete, or modify lines on an 850 already sent, and the supplier acknowledges the change with an 865.
Two. The 997 Functional Acknowledgment confirms the 850 was received and parsed. The 855 Purchase Order Acknowledgment is the business reply: accepted, rejected, backordered, or changed, line by line.
Yes. Files.com is a standards-compliant RFC 4130 AS2 endpoint, and a 850 sent by a trading partner lands in that partner’s inbox folder with a signed MDN receipt returned to the sender. Partners who exchange over SFTP or FTPS connect to the same platform and the document lands in the same place.
Yes. TransformScript parses the X12 850 natively and writes the JSON, CSV, or XML your systems ingest, as a step in the workflow that fires when the document arrives. Outbound, the same engine builds a 850 from your system’s export and drops it in the partner’s outbox for delivery.
Exchange The 850 Without The Legacy Stack
Start the 7-day trial, turn AS2 on, and exchange certificates with your partner. The 850 lands in their folder, parses into the record your system reads, and every transmission carries a signed receipt.
No credit card required • Free for 7 days • Live in minutes