EDI 850 Purchase Order: What It Is and How to Read One

An EDI 850 is the electronic version of a purchase order, sent from a buyer to a supplier in the ANSI X12 format. It carries the same information as a paper or PDF purchase order (the PO number, order date, ship-to, line items, quantities, prices, and terms) but as structured data that both companies' systems read automatically, with no typing on either end. The 850 is the transaction that opens most retail and manufacturing trading relationships, and it is usually followed by an 855 acknowledgment, an 856 advance ship notice, and an 810 invoice.

If some of your suppliers or customers send EDI 850s while others still email PDF purchase orders, the PDFs are the ones that create manual work. Upload a PDF PO above and the AI returns the same fields an 850 would carry (PO number, vendor, line items, quantities, prices, and dates) as clean Excel or CSV in seconds, so every order reaches your system in the same structured shape whether it arrived as EDI or as an attachment.

What EDI 850 stands for

EDI stands for electronic data interchange, the standardized exchange of business documents between computer systems. The number 850 is the transaction set code for a purchase order in the ANSI ASC X12 standard, which is the EDI standard used across North America. When a large retailer or manufacturer places an order electronically, its system generates an 850 and transmits it to the supplier, whose system reads it straight into order management. No one rekeys the order, and no PDF changes hands.

The 850 is a formal, commercial request to buy at an agreed price. Once the supplier accepts it, the order is generally binding, the same as a written PO. What makes the 850 different is the delivery: instead of a human reading a document, a machine parses a defined structure, so the order is placed in seconds and errors from manual entry disappear.

What an EDI 850 purchase order contains

An 850 holds the same core order data as any purchase order, organized into defined segments rather than a page layout:

• BEG segment: the beginning of the purchase order, carrying the PO number, the PO type, and the order date.
• REF and DTM segments: reference numbers (like a department or contract number) and dates such as the requested delivery date.
• N1 loop: the parties on the order. The N1 segment identifies each party by role, using a code such as BY for the buying party and SU for the supplier or ST for the ship-to location.
• PO1 loop: the line items. Each PO1 segment carries a line's quantity, unit of measure, unit price, and product identifiers such as a UPC, vendor part number, or buyer SKU.
• CTT segment: the transaction totals, giving the number of line items and, when used, a hash total of the quantities so the receiver can confirm nothing was dropped in transmission.

Those segments map one to one onto the fields you already know from a PDF PO. The BEG segment is the header, the N1 loop is the buyer and supplier blocks, and the PO1 loop is the line-item table. Understanding that mapping is what lets a team treat an EDI order and a PDF order as the same order in two different wrappers.

How an EDI 850 is sent

The 850 travels between trading partners over a secure channel, most often a value-added network (VAN) that acts as a private post office for EDI, or a direct AS2 connection between the two companies. The buyer's system builds the 850, wraps it in the X12 envelope segments (ISA and GS), and transmits it. The supplier's system receives it, sends back a 997 functional acknowledgment to confirm the file arrived intact, and then processes the order. Setting up that pipeline with each partner is what makes EDI powerful for high-volume relationships and heavy for occasional ones.

EDI 850 vs a PDF purchase order

The 850 and a PDF PO carry the same order, but they behave differently in your workflow. An 850 arrives as structured data your system reads automatically, so there is no typing, but it requires an EDI setup with that specific partner. A PDF PO arrives as a document a person has to read and key, which is fine for a few orders and painful at volume. Many US suppliers deal with both: a handful of big customers send 850s, and everyone else sends PDFs by email. The practical goal is to get both channels into the same structured shape. For a fuller side-by-side, see EDI vs PDF purchase orders, which covers when each makes sense and how to give PDF orders EDI-like speed.

Giving PDF purchase orders EDI-like speed

You do not need an EDI connection to get structured order data from a PDF. Extraction reads the PDF PO and returns the same fields an 850 would carry, so a supplier who cannot justify EDI with a small customer still gets clean, importable data. Upload the PO, let the AI capture the header and the full line-item table, review it on screen, and export it. From there the data imports the same way structured order data always does: into accounting or an ERP through the ERP import workflow, into Odoo with a purchase order to Odoo import, or straight into your own systems over the purchase order API. Accurate purchase order line item extraction is what makes that PDF data as usable as an 850's PO1 loop. When the matching invoice arrives, smaller suppliers send it as a PDF too rather than an EDI 810, and you can turn that invoice into a spreadsheet the same way.

Where the 850 sits in the EDI order flow

The 850 is the first document in a chain of EDI transactions that mirror the normal buying process. The buyer sends the 850 to place the order. The supplier returns an 855 purchase order acknowledgment to confirm acceptance or flag changes, the electronic version of the confirmation covered in purchase order acknowledgment. When the goods ship, the supplier sends an 856 advance ship notice, and after delivery an 810 invoice that accounts payable matches against the PO and receipt. Each code is just an electronic stand-in for a document your team already handles.

EDI 850 purchase order: common questions

What is an EDI 850?

An EDI 850 is the electronic purchase order in the ANSI X12 standard, sent from a buyer to a supplier to place an order. It carries the PO number, dates, ship-to, line items, quantities, and prices as structured data that both companies' systems read automatically. It is the electronic equivalent of a paper or PDF purchase order, delivered without anyone typing it.

What does EDI 850 mean?

The 850 is the X12 transaction set code for a purchase order, and EDI means electronic data interchange, the standardized exchange of business documents between systems. So an EDI 850 simply means a purchase order sent electronically in the standard format. When a partner asks you to accept 850s, they are asking you to receive their POs by EDI rather than by email.

What is the difference between an EDI 850 and an 855?

The 850 is the purchase order the buyer sends to the supplier, and the 855 is the purchase order acknowledgment the supplier sends back. The 850 places the order; the 855 confirms whether the supplier accepts it as issued, accepts it with changes, or rejects it. Together they are the electronic version of sending a PO and receiving a confirmation.

Is an EDI 850 legally binding?

An EDI 850 is treated the same as any purchase order: it is the buyer's offer to buy, and once the supplier accepts it, typically by returning an 855 acknowledgment, the order generally becomes a binding agreement. Trading partner agreements usually spell out that EDI documents carry the same legal weight as paper. Always check the terms in your own partner agreement.

How do I read an EDI 850 file?

An 850 file is a string of segments separated by delimiters, so it is hard to read raw. In practice, EDI software or a translator maps the segments into readable fields: BEG for the PO header, N1 for the parties, PO1 for each line item, and CTT for the totals. Most teams never read the raw file; their system parses it into the order automatically.

Do I need EDI to receive purchase orders?

No. EDI is worth the setup for high-volume trading partners, but many suppliers receive most orders as PDFs by email and never touch EDI. The alternative is to extract the PDF PO into structured data, which gives you the same clean fields an 850 would provide without a VAN or AS2 connection. Larger customers may still require EDI, so many businesses run both channels.