Skip to content

Stacksync × Supabase Miami: AI-Native OperationsOct 13Reserve your spot

X12 transaction code

EDI 850 Purchase Order (X12 850)

EDI 850 is the electronic purchase order (PO), the X12 Purchase Order transaction set, used when a buyer places an order. The buyer (retailer, distributor, or manufacturer procurement) sends the 850 to the supplier or vendor fulfilling the order.

Standard
X12
Code
850
Partner references
389
Book an EDI demo ← All trading partners

At a glance

EDI 850 at a glance

What the 850 carries, who sends it to whom, when it goes out, and the segments trading partners list for it.

X12 850 Purchase Order summary
Document X12 850 Purchase Order
Business record Purchase order or sales order
Who sends it to whom The buyer (retailer, distributor, or manufacturer procurement) sends the 850 to the supplier or vendor fulfilling the order.
When it is sent A buyer's procurement or replenishment system releases an approved order for goods to a specific supplier.
Match on Buyer purchase order, order line and trading-party identifiers
Partner references 389 trading partners in this directory
Related documents X12 855 Purchase Order Acknowledgment, X12 856 Ship Notice/Manifest, X12 810 Invoice, X12 860 Purchase Order Change Request (Buyer Initiated)

Key segments in an EDI 850

The business segments that appear in at least half of the 514 partner document references listed below, most common first. The table leaves out envelope segments (ISA, GS, ST, SE, GE, IEA). Your partner guide sets which segments and elements your account must send.

Segment Name Purpose Partner references
BEG Beginning Segment for Purchase Order To indicate the beginning of the Purchase Order Transaction Set and transmit identifying numbers and dates. 514 of 514
PO1 Baseline Item Data To specify basic and most frequently used line item data. 514 of 514
N1 Party Identification To identify a party by type of organization, name, and code. 509 of 514
CTT Transaction Totals To transmit a hash total for a specific element in the transaction set. 503 of 514
DTM Date/Time Reference To specify pertinent dates and times. 489 of 514
N3 Party Location To specify the location of the named party. 484 of 514
N4 Geographic Location To specify the geographic place of the named party. 480 of 514
PID Product/Item Description To describe a product or process in coded or free-form format. 479 of 514
REF Reference Information To specify identifying information. 477 of 514
N9 Extended Reference Information To transmit identifying information as specified by the Reference Identification Qualifier. 439 of 514

Stacksync connects EDI documents such as the X12 850 to your ERP, CRM and databases with two-way sync. Read the EDI overview, check pricing and security, or book a demo to walk through your partner guide.

Implementation guide

X12 850 mapping and validation

X12 850 Purchase Order is used when a buyer places an order. Preserve buyer purchase order, order line and trading-party identifiers so the purchase order or sales order in your business system stays connected to the original document.

Use the version and implementation guide agreed with your trading partner to confirm required fields and responses.

Map records and test the business result
Document or decisionRecord and matching IDsWhat to test
Match the business record purchase order or sales order

buyer purchase order, order line and trading-party identifiers
  • Define which combination of buyer purchase order, order line and trading-party identifiers identifies one business record, its lines and any later revision.
Update the receiving system Processing the purchase order or sales order

ID assigned by the receiving system and processing result
  • Map buyer item numbers to seller SKUs and explicitly convert case quantities to the agreed unit.
  • Resend one purchase order and confirm that only one sales order is created.
Check the processing result Processing status for the purchase order or sales order

Original document reference and matching response
  • Reconcile the purchase order or sales order with the source after a timeout before sending it again. A lost response can occur after the destination has already processed the document.

How the related documents differ

Each message represents a different business event. Use shared references to connect the records while tracking each message’s outcome separately.

Implementation steps

  1. Choose the starting event and owner

    Decide which application acts when a buyer places an order. Name the operational owner of the purchase order or sales order and the team that resolves rejected or ambiguous messages.

  2. Keep record IDs connected

    Map buyer purchase order, order line and trading-party identifiers. Confirm qualifiers, code lists, units and date/time meaning against the agreed X12 version and partner guide. Preserve the source reference alongside any new destination identifier.

  3. Test failures before launch

    Run the failure cases in the mapping table against realistic purchase order or sales order data. Check how the receiving system reports a rejection and how your team corrects it without creating a duplicate.

  4. Track every document to completion

    Record transport delivery and document validation separately from successful purchase order or sales order processing. Give unresolved errors an owner and check the receiving system before approving retries.

Go-live checklist

  • An approved 850 sample and the agreed version and partner guide are available.
  • The mapping tests pass with realistic purchase order or sales order data.
  • Each submitted document can be traced through delivery, validation and processing in the receiving system.
  • Your team knows how to investigate and recover a rejected or timed-out purchase order or sales order without processing it twice.

Document structure

X12 850 Purchase Order at the element level

The X12 850 reference contains 71 segment entries and 282 data elements; 84 are marked mandatory in this reference. Use the version and partner guide agreed for your account to confirm required fields.

Segments
71
Data elements
282
Mandatory elements
84
Segments with elements marked mandatory in this reference
Segment Elements Mandatory
BEG 5 4
CUR 5 2
REF 3 1
FOB 7 1
SAC 11 1
DTM 4 1
PID 4 1
TXI 8 1
N9 3 1
MSG 2 1
Key identifiers in 850
  • Transaction Set Purpose Code
  • Purchase Order Type Code
  • Purchase Order Number
  • Date
  • Entity Identifier Code
  • Currency Code
  • Reference Identification Qualifier
  • Shipment Method of Payment

Find your trading partner for X12 850

389 partners, 516 channels. Choose a channel to inspect its listed document reference and implementation context.

Catalog breakdown

Where X12 850 Purchase Order appears in this catalog

The largest groups of classified 850 catalog entries are in retail, grocery & food and apparel & footwear.

By industry

  • retail 92 channels
  • grocery & food 83 channels
  • apparel & footwear 68 channels
  • building & hardware 62 channels
  • furniture & home 45 channels
  • healthcare & pharma 35 channels

By network

  • SPS Commerce 92 channels
  • Epicor Eclipse 44 channels
  • TrueCommerce 27 channels
  • Rithum 25 channels
  • Logicbroker 9 channels
  • iTradeNetwork 8 channels
Partner entries with the most listed channels

FAQ

EDI 850 questions

What is an EDI 850?

EDI 850 is the electronic purchase order (PO), the X12 Purchase Order transaction set. Trading partners use it when a buyer places an order. It carries the data for the purchase order or sales order, and your system matches it on buyer purchase order, order line and trading-party identifiers.

Who sends an EDI 850 and who receives it?

The buyer (retailer, distributor, or manufacturer procurement) sends the 850 to the supplier or vendor fulfilling the order. Your trading partner agreement confirms the direction and version for your account.

When is an EDI 850 sent?

A buyer's procurement or replenishment system releases an approved order for goods to a specific supplier. Your partner guide sets any deadline or schedule for the document.

What are the key segments in an EDI 850?

Across 514 partner document references listed here, the business segments that appear most often include BEG (Beginning Segment for Purchase Order), PO1 (Baseline Item Data), N1 (Party Identification), CTT (Transaction Totals), DTM (Date/Time Reference), N3 (Party Location). Each partner guide sets which segments and elements your account must send.

What is the difference between EDI 850 and EDI 855?

The 850 is the purchase order the buyer sends. The 855 is the supplier's reply: it accepts, changes or rejects the order, often line by line, before anything ships.

What is the difference between EDI 850 and EDI 810?

The 850 is the order and the 810 is the bill for it. The supplier sends the 810 after shipping and quotes the 850's purchase order number, so the buyer can match prices and quantities to what it ordered.

What should I map for X12 850?

Start with buyer purchase order, order line and trading-party identifiers and the target purchase order or sales order. Define duplicate detection, allowed updates and response correlation before mapping individual fields. Use the partner guide to check required fields and their formats.

How should I test 850 error handling?

Map buyer item numbers to seller SKUs and explicitly convert case quantities to the agreed unit. Resend one purchase order and confirm that only one sales order is created. Also test a lost response after destination processing so that a retry cannot create an unintended duplicate or repeated adjustment.

Connect EDI to your business systems

See how Stacksync can fit your enterprise EDI workflow. Bring one partner guide and a sample exchange to plan the system mapping, exception handling and production rollout.

Book an EDI demo Explore the EDI platform