X12 850 Purchase Order: Complete EDI Guide
A complete, segment-by-segment walkthrough of the X12 850 Purchase Order — what it is, how it's structured, how to map it, and how to troubleshoot the errors that show up most often in production.
In this article
If you work anywhere near a supply chain, you've dealt with the X12 850 whether you knew its name or not. It's the electronic purchase order that kicks off the order-to-cash cycle between a buyer and a supplier — the digital replacement for a faxed or emailed PO. This guide walks through exactly how it's built, segment by segment, with a real example you can trace end to end.
1. What is X12 850?
The 850 is an ANSI ASC X12 transaction set that represents a purchase order: what the buyer wants, how much of it, at what price, and where it should go. It's typically the first document in a chain that continues with an 855 (acknowledgment), 856 (ship notice), and 810 (invoice).
Where the 850 fits
Buyer sends 850 → Supplier sends 997 (technical receipt) → Supplier sends 855 (business confirmation) → Supplier ships and sends 856 → Supplier bills with 810.
2. Business workflow
- Buyer's ERP or procurement system generates a purchase order record.
- An EDI translator maps that internal record into 850 segments.
- The file is transmitted via AS2, SFTP, or a VAN to the supplier.
- The supplier's translator validates syntax and confirms receipt with a 997.
- The supplier's order management system reviews the order and responds with an 855.
- Fulfillment begins, followed eventually by an 856 ASN and 810 invoice.
3. X12 envelope structure
Every X12 transaction is wrapped in three nested envelopes. The ISA/IEA pair is the interchange envelope (sender/receiver at the organization level). The GS/GE pair is the functional group envelope (batches transactions of the same type, like all 850s). The ST/SE pair wraps a single transaction set — one actual purchase order.
| Envelope Level | Header | Trailer | Purpose |
|---|---|---|---|
| Interchange | ISA | IEA | Sender/receiver ID, control number for the whole file |
| Functional Group | GS | GE | Groups transaction sets of the same type |
| Transaction Set | ST | SE | Wraps one business document (one PO) |
4. Segment-by-segment explanation
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.
| Segment | Name | Purpose |
|---|---|---|
| BEG | Beginning Segment for Purchase Order | PO number, type, and date |
| REF | Reference Identification | Additional references (contract, department) |
| N1 | Party Identification | Buyer, ship-to, bill-to parties |
| PO1 | Baseline Item Data | One per line item: quantity, price, product ID |
| PID | Product/Item Description | Free-text description of the item |
| CTT | Transaction Totals | Count of line items for control purposes |
5. Example 850
Here's a realistic 850 for an order of barcode scanners and charging cables. Click any segment below in the interactive visualizer to see what it means in plain English.
ISA
This is an envelope or control segment. Select a highlighted segment on the left (shown in green) for a full business explanation.
6. Mapping example
Most enterprise buyers generate purchase orders from an ERP like SAP, which represents orders as IDocs rather than EDI segments. Mapping is the process of translating between the two structures field by field.
EDI Mapping Visualizer
Pick a source and target format to see how fields translate.
Source · SAP
Target · X12
Business fields represented: Item / Material · Quantity · Unit Price · Delivery Date · Order Reference. Hover a row to trace it across formats.
7. Validation
- BEG03 (PO number) must be unique per trading partner and non-blank.
- Each PO1 loop must resolve to a valid, active item number in the supplier's catalog.
- N1 loops must include at least one Ship To (ST) party with a resolvable address.
- CTT01 must equal the actual count of PO1 loops in the transaction.
- Quantity and unit price must be numeric and greater than zero.
8. Common errors
| Error | Likely Cause | Fix |
|---|---|---|
| 997 rejects with segment count mismatch | SE01 doesn't match actual segment count | Recalculate segment count before transmission |
| Supplier reports 'unknown item' | PO107 qualifier mismatch (VP vs. BP vs. UP) | Confirm the agreed item-number qualifier with the partner |
| Ship-to address not found | New location code not yet set up at supplier | Send location updates ahead of first order to that location |
9. End-to-end architecture
Zooming out from the transaction itself, here's how an 850 typically flows through a complete EDI platform, from the buyer's ERP to the trading partner and back. Press Play Flow to watch the message travel, or click any step for a deeper explanation.
How it works
How 850 Purchase Order Works
Sender
Buyer / Retailer / Distributor
Receiver
Supplier / Manufacturer / Vendor
Direction
Buyer → Seller
Standard
ANSI ASC X12
Version
005010
Transport
AS2 / SFTP / VAN
Business Purpose
Order Management
Sender — Buyer / Retailer / Distributor
EDI Transmission
850
Purchase Order
ANSI ASC X12 004010 / 005010
Receiver — Supplier / Manufacturer / Vendor
Related transaction flows
Need help understanding this EDI flow?
Ask EDI AI →850 Purchase Order workflow. Steps: Create Purchase Order, ERP Order Record, Generate X12 850, Validation, AS2 / SFTP / VAN, Supplier EDI Gateway, Translate to ERP, Order Processing. Transmitted from Buyer / Retailer / Distributor to Supplier / Manufacturer / Vendor via AS2, SFTP, VAN, following ANSI ASC X12 004010 / 005010.
10. Real-world implementation
In practice, most 850 implementations fail not because of the X12 syntax itself but because of item and location cross-reference gaps — the buyer's SKU doesn't match what the supplier expects, or a new distribution center hasn't been communicated. Before go-live with any new trading partner, exchange a full item and location cross-reference file, not just a sample transaction, and run at least one complete order-to-invoice cycle in a test environment.
Implementation tip
Log every rejected 850 with its raw payload for at least 90 days after go-live. The vast majority of onboarding issues repeat in predictable patterns across your first handful of trading partners.
Related transactions
Purchase Order Acknowledgment
The X12 855 is the supplier's formal response to an 850 Purchase Order, confirming, changing, backordering, or rejecting each line item.
Advance Ship Notice
The X12 856 (ASN) tells the buyer exactly what was shipped, how it was packed (pallet/case/item hierarchy), and when it will arrive — before the truck reaches the dock.
Invoice
The X12 810 is the electronic invoice a supplier sends after (or with) a shipment, billing the buyer for goods or services delivered.
Functional Acknowledgment
The X12 997 confirms that an interchange was received and whether it passed structural (syntax) validation — it does not confirm business acceptance of the content.
Frequently asked questions
Conceptually yes, but it's structured data meant for system-to-system exchange, not a human-readable document.
Related articles
X12 856 Advance Ship Notice: The Complete EDI Guide
Everything you need to build, validate, and troubleshoot an X12 856 ASN — including the HL hierarchy that trips up almost every new implementation.
EDI Mapping Explained: From ERP Fields to X12 and EDIFACT Segments
A practical guide to how EDI mapping actually works — the concepts, common source formats, and a worked example translating SAP IDoc fields into an X12 850.
Have a follow-up question about this topic?
Ask EDI AI →