How do you send or receive an EDI 850?
An EDI 850 moves between trading partners over a secure transport protocol—AS2, SFTP, a VAN, or increasingly an API-mediated connection—after being translated between the partner’s X12 format and the internal format your ERP understands. The transport is usually the easy part; the real work is the translation map and the connection into your business systems, which is why most organizations run this through a data integration tool rather than building point-to-point connections for each partner.
- A trading partner agreement and companion guide. The buyer’s spec defines the X12 version, which segments are mandatory versus optional, qualifier values, and any partner-specific conventions. This document governs the build.
- Trading partner identifiers. Sender and receiver IDs with qualifiers (DUNS, mutually defined, or phone-based) for the ISA/GS envelope.
- A transport method. AS2 for direct point-to-point with encryption and signed MDN receipts; SFTP for scheduled file drops; a VAN for mailbox-based routing across many partners; or an API for partners who’ve moved to modern connectivity.
- Security credentials. Digital certificates for AS2, SSH keys for SFTP, and a plan for renewal before expiry — expired certificates are a common cause of sudden connection failure.
- An EDI translator or integration platform. Software that parses inbound X12 into structured data and serializes outbound data back into X12. Cleo Integration Cloud is a common choice for mid-market organizations.
- A data map. The field-by-field translation between the 850 and your ERP’s sales order structure, including cross-references for part numbers, units of measure, and customer/location codes.
- Cross-reference tables. Buyer part number to your SKU, buyer location codes to your ship-to records, and UOM conversions. Mismatches here are the leading cause of failed orders.
- ERP or order management integration. A path for the translated order to land in your system — API, database write, or flat file import — plus error handling when it doesn’t.
- Acknowledgment capability. The ability to return a 997 automatically and an 855 as a business response. Most partners require both and measure your response time.
- Testing and certification. A structured test cycle with the partner, moving from connectivity test to sample transactions to production approval. Larger retailers may require certification through a third-party portal.
- Monitoring and exception handling. Alerting on failed transmissions, unacknowledged files, and mapping errors, with someone accountable for clearing the queue. Silent failures become chargebacks.
- Archival and audit retention. Storage of raw transactions and acknowledgments to resolve disputes and satisfy audit requirements.
How is an 850 transmitted?
An EDI 850 is transmitted over a secure, agreed-upon transport protocol rather than a single universal channel. The trading partner’s requirements dictate the method.
- AS2 sends the file directly point-to-point over HTTPS with encryption, digital signatures, and a signed MDN receipt confirming delivery.
- SFTP moves files into a scheduled directory drop, favored for its simplicity and low cost.
- A VAN acts as a mailbox service that routes transactions on your behalf, which is efficient when you’re managing dozens of partners with differing requirements.
- REST APIs are increasingly exposed by partners for real-time order exchange.
Whichever protocol carries the file, the 850 itself remains a standard X12 document, and delivery is confirmed at the transport layer separately from the 997 acknowledgment that confirms the transaction actually parsed.
Can an 850 flow straight into our ERP?
Yes, a properly configured EDI 850 can post directly into your ERP as a sales order with no manual keying, and that straight-through processing is the point of the investment in EDI. But “straight into” is conditional: the X12 document must be translated into your ERP’s order structure, and every identifier that the buyer uses—their part numbers, their location codes, their units of measure—must resolve to a record that already exists in your system.
Where those cross-references are incomplete, orders fail validation and drop into an exception queue for someone to clear by hand. The gap between 60% and 98% touchless order entry is almost always data quality, not integration architecture.
| Requirement | What it involves | Why it matters |
| Translation layer | An EDI translator or integration platform (e.g., Cleo Integration Cloud) that parses X12 into structured data | Your ERP can’t read raw X12; something has to sit between the transport and the application |
| ERP integration method | API, web service, staging database table, or supported flat-file import into the sales order module | Determines how the translated order actually lands and whether it posts in real time or in batch |
| Item cross-reference | Mapping of buyer part numbers, UPC/GTIN, and vendor SKUs to your internal item master | The single most common cause of failed 850s; an unrecognized part number stops the order |
| Customer and ship-to cross-reference | Buyer location and DC codes mapped to your customer and ship-to address records | Multi-location retailers send store-level ship-tos that must resolve to real records |
| Unit of measure conversion | Rules translating the buyer’s UOM (cases, eaches, pallets) to your ERP’s stocking UOM | Quantity errors here ship the wrong volume and trigger chargebacks |
| Price validation logic | Comparison of the PO unit price against your contract or price list, with tolerance thresholds | Catches pricing discrepancies before fulfillment rather than at invoice reconciliation |
| Business rule validation | Checks for credit hold, minimum order quantity, duplicate PO numbers, item status, and requested date feasibility | Prevents unfulfillable orders from entering the queue as if they were clean |
| Exception handling workflow | A defined queue, ownership, and SLA for orders that fail any validation above | Silent failures are the real risk — an order that never posts and never alerts becomes a missed ship window |
| Automated acknowledgment | Automatic 997 on receipt and 855 generated from the ERP’s acceptance or rejection of each line | Most partners measure acknowledgment turnaround as a compliance metric |
| Order status writeback | A path for the ERP’s response — accepted, rejected, quantity changed — to feed the outbound 855 and later the 856 and 810 | Closes the loop so downstream documents inherit accurate data instead of being rekeyed |
| Logging and audit trail | Retention of the raw 850, the translated payload, and the resulting ERP order ID | Needed for dispute resolution and to trace where a bad order went wrong |
| Monitoring and alerting | Notifications on transmission failures, unacknowledged files, and mapping errors | Turns a failure into a same-day fix rather than a partner escalation |
What’s an example of an EDI 850 document?
An EDI 850 is the standard X12 transaction set for a Purchase Order. It’s a plain-text format made up of segments (one per line, usually ending in ~), each starting with a 2–3 character identifier, with data elements separated by *. Here’s a simplified but realistic example:
Raw EDI 850 code example
ISA*00* *00* *ZZ*SENDERID *ZZ*RECEIVERID *260903*1015*U*00401*000000101*0*P*>~
GS*PO*SENDERID*RECEIVERID*20260903*1015*101*X*004010~
ST*850*0001~
BEG*00*SA*PO123456**20260903~
REF*DP*038~
PER*BD*John Smith*TE*555-555-1234~
DTM*002*20260915~
N1*ST*Acme Distribution Center*92*DC001~
N3*1500 Industrial Parkway~
N4*Chicago*IL*60601*US~
PO1*1*24*EA*15.50**VN*WIDGET-100*UP*012345678905~
PID*F****Blue Widget, Standard Size~
PO1*2*10*CS*89.99**VN*GADGET-200*UP*012345678912~
PID*F****Gadget Assembly Kit, Case of 12~
CTT*2*34~
SE*14*0001~
GE*1*101~
IEA*1*000000101~
Human-legible EDI 850 example
The purchase order above renders as follows in a human-readable format.
PURCHASE ORDER
PO Number: PO123456
PO Date: September 3, 2026
Order Type: Original / Stand-alone
Department: 038
Buyer Contact: John Smith — Tel: 555-555-1234
Requested Delivery Date: September 15, 2026
Ship To:
Acme Distribution Center (Location ID: DC001)
1500 Industrial Parkway
Chicago, IL, 60601, US
Line Items
| Line | Vendor Part # | UPC | Description | Qty | UOM | Unit Price | Ext. Price |
| 1 | WIDGET-100 | 012345678905 | Blue Widget, Standard Size | 24 | Each | $15.50 | $372.00 |
| 2 | GADGET-200 | 012345678912 | Gadget Assembly Kit, Case of 12 | 10 | Case | $89.99 | $899.90 |
Total Line Items: 2
Total Quantity: 34
Order Total: $1,271.90
What’s the difference between an 850 and an 875?
Both 850 and 875 are X12 purchase order transactions, but they serve different industries: the 850 is the general-purpose Purchase Order used across most sectors (retail, manufacturing, distribution), while the 875 is the Grocery Products Purchase Order, designed specifically for the grocery/food industry.
The 875 is structured around grocery conventions. It uses different segments (like G50 for order identification instead of BEG, and G68 for line items instead of PO1). It also supports industry-specific identifiers such as GTIN/case codes common in food distribution, and it pairs with its own grocery counterpart documents (875/876/880) rather than the standard 850/855/810 flow.
Functionally, both 850 and 8975 accomplish the same thing, communicating an order from buyer to seller. However, a trading partner will mandate one or the other based on their industry ecosystem.
EDI 850 vs. 875 comparison table
| | EDI 850 | EDI 875 |
| Name | Purchase Order | Grocery Products Purchase Order |
| Industry | General (retail, manufacturing, distribution, etc.) | Grocery / food and beverage |
| Header segment | BEG | G50 |
| Line item segment | PO1 | G68 |
| Typical response doc | 855 (PO Acknowledgment) | 876 (Grocery PO Change) / 880 (Grocery Invoice) |
| Invoice counterpart | 810 (Invoice) | 880 (Grocery Products Invoice) |
| Common users | Big-box retail, B2B manufacturing, e-commerce | Grocery chains, food distributors, CPG suppliers |
In practice, if you’re trading with a grocery retailer or a food distributor, you’ll likely be asked for the 875 family. Nearly everyone else uses the 850 family.
What EDI document comes after an 850?
After an 850 Purchase Order, the typical next document is the 855 Purchase Order Acknowledgment. The seller sends back the 855 to confirm receipt of the order and indicate whether it’s accepted, rejected, or accepted with changes (price differences, backorders, substitutions, etc.).
Many trading partners also require a 997 Functional Acknowledgment immediately upon receipt—a technical “we got the file” receipt that precedes any business response. From there, the standard order-to-cash flow continues: the 856 Advance Ship Notice (ASN) is issued when goods ship, and the 810 Invoice is issued for billing.
Therefore, the full sequence usually looks like: 850 → 997 → 855 → 856 → 810, though the exact documents required vary by trading partner agreement.
What’s the difference between a 997 and an 855?
The key difference is technical versus business acknowledgment. A 997 Functional Acknowledgment only confirms that an EDI file was received and could be parsed. It says, “Your 850 arrived and the syntax was valid,” but it doesn’t say anything about whether the seller will actually fulfill the order.
An 855 Purchase Order Acknowledgment is a business-level response where the seller commits to (or modifies) the order itself, confirming items, quantities, prices, and ship dates, or flagging rejections, backorders, and substitutions.
A 997 is generated automatically by the EDI translator within minutes, while an 855 comes from the seller’s order management system after the order has been reviewed. Many trading partners require both: the 997 first as a receipt, then the 855 as the real answer.
EDI 997 vs. 855 comparison table
| | EDI 997 | EDI 855 |
| Name | Functional Acknowledgment | Purchase Order Acknowledgment |
| Purpose | Confirms EDI file was received and syntactically valid | Confirms seller’s business response to the order |
| Level | Technical / transport | Business / commercial |
| Answers the question | “Did the file arrive intact?” | “Will you fulfill my order, and how?” |
| Generated by | EDI translator (automatic) | Order management / ERP system |
| Timing | Minutes after receipt | Hours to a day, after order review |
| Content | Control numbers, accept/reject status of the transmission | Line-level detail: quantities, prices, ship dates, changes |
| Can reject an order? | No — only rejects malformed EDI | Yes — can reject or modify line items |
| Responds to | Any EDI document (850, 856, 810, etc.) | Specifically the 850 |
Here’s a useful way to remember it: a 997 is like a read receipt on an email, while an 855 is the actual reply.
Can I send a PO change as another 850?
Technically, the standard answer is no. Purchase order changes should be sent as an 860 Purchase Order Change Request, which is specifically designed to communicate modifications to an already-transmitted 850. The seller responds to this with an 865 PO Change Acknowledgment.
That said, in practice, some trading partners do handle changes by reissuing an 850, using the BEG segment’s purpose code to signal intent: BEG01 code “00” means original, while codes like “05” (Replace) or “01” (Cancellation) indicate the document supersedes a prior order. Whether that’s acceptable depends entirely on the trading partner agreement. 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.
How long does an EDI 850 implementation take?
An EDI 850 implementation typically takes anywhere from 2 to 12 weeks, depending heavily on your starting point and the trading partner’s requirements.
- If you already have EDI infrastructure and the partner uses a common implementation guide, mapping and testing an 850 can be done in 2–4 weeks.
- If you’re starting from scratch, i.e. selecting a provider, setting up connectivity (AS2, SFTP, or VAN), building maps, and integrating with your ERP, expect more like 2–3 months.
The biggest time drivers are usually the trading partner’s testing/certification process, ERP integration complexity, and how quickly each side turns around test files. Onboarding additional partners after the first one goes much faster, since the infrastructure and core mapping are already in place.
