Skip to content
LegacyFile
← Learn

What Is an EDI 850? Purchase Orders Explained in Plain English

By LegacyFile ·

Someone forwarded you a file that starts with ISA*00* and ends in tildes, and told you it's "the PO." There's no letterhead, no line-item table, no total at the bottom you can eyeball — just a wall of codes separated by asterisks. That's an EDI 850: the ANSI X12 transaction set that stands in for a purchase order when two companies' systems talk directly to each other instead of emailing a PDF back and forth. This article walks through exactly what's inside one and how to read it without owning an EDI translator.

What an EDI 850 is

The 850 is one of hundreds of standardized "transaction sets" defined by the ANSI ASC X12 committee — the same body behind the 810 invoice and 856 advance ship notice. Where a PDF purchase order is designed for a human to read, an 850 is designed for one company's ERP to hand directly to another's, with no human in the loop at all. That's the whole point of EDI: a supplier's order management system can receive an 850, create a sales order automatically, and start picking inventory within minutes of the buyer hitting "send" — no data entry, no email, no PDF parsing.

The tradeoff is readability. Every field is positional and coded, delimited by characters declared once in the file's ISA header (almost always * for elements, ~ for segments, : for sub-elements). Open one in a text editor and it means nothing until you know the segment dictionary — which is exactly what a free EDI viewer decodes for you.

Who sends and receives 850s

Buyers send 850s; suppliers receive them. It's the first document in the classic EDI order cycle: an 850 (purchase order) triggers an 856 (advance ship notice) when the goods ship, which is followed by an 810 (invoice) to bill for them. Retailers, distributors, and manufacturers with EDI trading-partner requirements — Walmart, Target, most grocery and big-box chains — expect 850s in this exact format, and a supplier's compliance with the spec is often a condition of the vendor relationship itself.

Anatomy of an 850

Here's a small but complete example, structurally identical to what a real trading partner would send:

ISA*00*          *00*          *ZZ*NORTHWINDBUY   *ZZ*ACMESUPPLY     *260710*0800*^*00501*000000123*0*P*:~
GS*PO*NORTHWIND*ACMESUPPLY*20260710*0800*1*X*005010~
ST*850*0001~
BEG*00*SA*PO-100234**20260710~
REF*DP*GROCERY-04~
N1*ST*Northwind Distribution Center*92*NWDC001~
N3*4400 Commerce Way~
N4*Springfield*IL*62704*US~
PO1*1*100*CA*12.50*PE*VP*SKU-88213*UP*04963000123~
PID*F****Organic Rolled Oats 42oz~
CTT*1*100~
SE*9*0001~
GE*1*1~
IEA*1*000000123~

Reading it top to bottom:

  • ISA / GS / ST — the envelope. Sender and receiver IDs, the interchange date, and the document type (850) and its control number (0001), which the closing SE trailer must echo back exactly.
  • BEG — Beginning Segment for Purchase Order. The header: purpose code (00 = original), PO type code (SA = stand-alone order — other common codes are NE new order, RL release against a blanket order, CO change), the PO number itself, and the order date.
  • REF — reference numbers. Free-form qualifier/value pairs for anything the buyer wants to carry along — a department code, a contract number, an internal cost center.
  • N1 / N3 / N4 — the ship-to/bill-to loop. N1 names the party and its role (ST ship-to, BT bill-to, VN vendor); N3 and N4 are the street address and city/state/zip that follow it. A purchase order commonly repeats this loop twice, once per party.
  • PO1 — one line per item ordered. Line number, quantity, unit of measure, unit price, and then repeating qualifier/ID pairs for however many product identifiers the buyer supplies — VP for the vendor's own part number, UP for a UPC, EN for an EAN, and so on.
  • PID — the item description, immediately following the PO1 line it describes.
  • CTT — transaction totals. A line-item count and, optionally, a hash total (the sum of every quantity) that receiving systems use as a cheap integrity check.
  • SE / GE / IEA — the closing trailers, each echoing a control number or count from its matching header.

Reading an 850 without an EDI translator

You don't need a six-figure EDI platform to read one purchase order. Drop or paste the file into the free EDI viewer here on LegacyFile and it decodes every segment above — BEG, N1 loops, PO1 lines, CTT totals — into a labeled, expandable view, plus a structured JSON version and a CSV export of every line item. It runs entirely in your browser, so the PO never leaves your device, and there's no row limit or signup wall. If your business receives 850s regularly enough that eyeballing one at a time gets old, that's exactly the kind of repetitive EDI work the batch mode I'm building next is for.