EDI 850: The Purchase Order Transaction, Explained

Every X12 trading relationship starts with the same three digits. If you work anywhere near EDI, you've mapped, tested, or debugged an 850 even if nobody ever called it by name.

What is an EDI 850?

The EDI 850 is the ANSI X12 transaction set a buyer sends to a supplier to place a purchase order a formal business and commercial request sent by the buyer for delivery of goods or services at an agreed price. It carries the same line items, pricing, and delivery dates as a paper or PDF PO, just reorganized into segments a translator and an ERP can parse without a human touching a keyboard.

It's one of the oldest transaction sets in the X12 catalog and still one of the highest-volume ones moving through retail, manufacturing, and distribution networks today. A properly configured EDI 850 can post directly into your ERP as a sales order with no manual keying, provided you have the right technology in place. That's the whole pitch of EDI in one sentence: no fax, no re-keying, no transposed quantities.

What's actually inside an 850 — the key segments

An 850 is built from a small number of segments repeated in loops, wrapped inside the standard ISA/GS/ST envelope. Inside the ST/SE envelope, the 850's business content follows a predictable pattern: a BEG segment establishes the PO header, N1 loops identify the parties involved, PO1 loops list each line item, and a CTT segment totals everything up. Here's what each piece actually does:

• ST/SE — opens and closes the transaction set, with matching control numbers so the translator can confirm nothing was truncated in transit.
• BEG — BEG01 is the transaction set purpose code and separates an original from a cancellation or a replacement, BEG02 is the purchase order type code, and BEG03 is the purchase order number, which becomes the match key for every downstream document.
• N1 loop — identifies trading parties by functional qualifier: ST = ship-to, SF = ship-from, BY = buying party, VN = vendor, BT = bill-to.
• PO1 loop — each PO1 loop captures a single SKU with its unit price, unit of measure, and product identifiers, with PID and SAC segments nested inside for descriptions and line-level allowances.
• DTM, FOB, REF — delivery windows, freight terms, and reference numbers like department or buyer codes. Some retailers even push routing-guide instructions straight into the 850 via TD5 (carrier) and TD3 (equipment) segments.
• CTT — the hash total that proves nothing got dropped between sender and receiver.

A stripped-down real-world snippet looks like this:

ST*850*0001~
BEG*00*SA*PO-458921**20261103~
N1*BY*NORTHFIELD RETAIL GROUP*92*0084471~
N1*ST*NORTHFIELD DC 12*92*0084471-12~
PO1*1*600*EA*9.40**VN*APL-2291-M~
PO1*2*300*EA*9.40**VN*APL-2291-L~
CTT*2~
SE*9*0001~

That's a mid-size retailer, Northfield Retail Group, ordering two sizes of an apparel SKU from a supplier under a stand-alone order (BEG02 = SA). The PO number PO-458921 in BEG03 is the thread that ties every downstream document — acknowledgment, ASN, invoice — back to this one order.

EDI 850 vs the documents it gets confused with

850 vs EDIFACT ORDERS

Same business function, different standard and different syntax. ORDERS is the UN/EDIFACT message for communicating a purchase order from a buyer to a seller — segments for parties, line items, quantities, and pricing, wrapped in EDIFACT's own envelope structure. Structurally they're cousins: BEG maps to BGM, N1 maps to NAD, PO1 maps to LIN/QTY/PRI, CTT maps to UNS. But the wrapper and punctuation differ completely. X12 uses a tilde as segment terminator and ISA as the interchange header, while EDIFACT uses an apostrophe as segment terminator and UNB as the interchange header. X12 dominates North America; EDIFACT dominates everywhere else, especially automotive and European retail. If you're onboarding a European supplier who insists their system "doesn't support 850s," this is usually why — they're not wrong, they just speak ORDERS.

850 vs 875

The 875 is not a grocery-flavored 850, it's a separate transaction set with its own segment set. The EDI 850 is a Standard Purchase Order with comprehensive details, while the EDI 875 is a Grocery Products Purchase Order tailored for grocery stores and wholesalers. The 875 uses UCS-derived segments like grocery-specific segments like G50, G68, G69, G76 that follow UCS conventions, built around UPC-level identification and deal/allowance codes rather than the buyer part numbers common in an 850. It's worth knowing this isn't universal in grocery either — Walmart uses the EDI 850 exclusively, even for grocery items, and Kroger's EDI requirements also specify the 850 as their standard purchase order across all divisions. Always check the trading partner's implementation guide before assuming which one you'll receive.

850 vs 860 (PO change) and 855 (PO acknowledgment)

This is the single most common build mistake teams make: treating the 850 as if it can carry a change or a confirmation. It can't, by design. This transaction set should not be used to convey purchase order changes or purchase order acknowledgment information. Modifications belong in the 860, which references the original PO and applies only the delta, with the supplier's system maintaining the 850 as the base record and applying each 860 as a versioned change. Confirmations belong in the 855, which the seller sends back to accept, reject, or accept-with-changes. Many systems will treat a second 850 with the same PO number as a duplicate and reject it, so the safe default is the 860 unless your partner's implementation guide explicitly says otherwise.

A worked example: how one 850 moves through the supply chain

Take Northfield's PO-458921 from above. Their ERP generates the order, an EDI translator (Cleo, SPS Commerce, TrueCommerce, whatever sits in the middle) converts it to X12 segments, and it transmits over AS2 to the apparel supplier's mailbox. The supplier's translator fires back a 997 functional acknowledgment within minutes confirming the envelope was received intact, then their order management system reviews it and returns an 855 — accepted as-is, or accepted with a quantity reduced on one line because of a stock shortfall.

Once that 855 lands, the order stops being a procurement document and becomes a transportation problem. Someone has to get 900 units of a garment from the supplier's DC to Northfield's warehouse by the date in the DTM segment. This is the exact handoff point where EDI and transport execution software meet: the confirmed order quantities and ship-to address from the 850/855 pair feed a load tender, either as an X12 204 Motor Carrier Load Tender exchanged between shippers and carriers or as a direct API booking call. Platforms like Cargoson, MercuryGate, Descartes, and Alpega sit in this layer, consuming order and shipment data to automate carrier selection and tendering rather than leaving a planner to phone a broker. The supplier eventually ships, sends an 856 advance ship notice, and closes the loop with an 810 invoice once goods are received.

Common implementation mistakes with the 850

Most 850 problems aren't exotic. They're the same handful of errors repeating across trading partners:

• Assuming a resent 850 is a correction. Some buyers do resend a corrected 850 under the same PO number instead of issuing a proper 860, and if your mapping rejects duplicates by PO number, you'll silently drop the correction.
• Mismatched qualifiers in N1 loops. If your system expects "ST" for ship-to and the partner sends a different code for a multi-stop delivery, the order routes to the wrong dock, not to an error queue.
• Missing or wrong CTT hash totals. CTT01 must equal the actual count of PO1 loops in the transaction, and a mismatch here is exactly the kind of error that gets silently swallowed if your validation isn't strict.
• Assuming uniform unit-of-measure codes. One partner's "EA" is another's "CA" (case), and a mapping that assumes consistency across trading partners will ship the wrong volume with a perfectly valid-looking 850.
• Sending the wrong document for the wrong industry. A grocery-specialized partner expecting an 875 won't necessarily reject an 850 cleanly, it may just misroute it.

Why the 850 still matters in an API-first world

Despite a decade of API-migration talk, 850 volume hasn't collapsed, because the large retailers and manufacturers who mandate it for supplier onboarding haven't changed their compliance requirements. What's changed is what's behind the curtain. A growing share of "API integrations" that trading partners advertise are really EDI translated into JSON or REST by a provider like TrueCommerce, SPS Commerce, or Cleo sitting between the two parties — the 850 segments still exist, they're just not what either side's developers look at directly.

The same bridging logic shows up downstream in transport. Modern TMS and carrier-connectivity tools, Cargoson among them alongside Descartes, nShift, and FreightPOP, increasingly accept both EDI-based tender data and native API calls, so a shipper isn't forced to pick one integration method for execution just because their order data arrived as an X12 850.

FAQ

Is an EDI 850 the same as a PO?
Functionally yes. "EDI PO" is the common industry name, while "850" is the official ANSI X12 transaction set code — it's the electronic, structured version of the same document.

Who sends the EDI 850, buyer or supplier?
The buyer. The supplier is the receiving party and responds with a 997, then typically an 855.

What happens after an 850 is sent?
It's typically acknowledged with a 997 and an 855, followed by an 856 advance ship notice and an 810 invoice.

Can an 850 be used to change an order?
No. The 850 should not be used to convey purchase order changes or purchase order acknowledgments — those belong to the 860 and 855 respectively.

Is EDI 850 still used, or has it been replaced by APIs?
Still very much in use. Large retail and manufacturing buyers continue to mandate it for supplier onboarding, and many modern "API" connections are EDI translated behind the scenes by B2B integration providers rather than a genuine replacement of the standard.