X12 transaction guide · Ordering
EDI 855 Purchase Order Acknowledgment
The X12 document a supplier sends to confirm, change or reject a buyer's purchase order before shipping.
- Sent by
- Supplier or vendor
- Received by
- Buyer
- Standard
- ANSI ASC X12
- EDIFACT equivalent
- ORDRSP
What is an EDI 855?
The EDI 855 Purchase Order Acknowledgment is the ANSI X12 transaction set a supplier sends in response to a purchase order. It tells the buyer whether the order was accepted as sent, accepted with changes, or rejected, and it can confirm or adjust individual lines, quantities, prices and expected ship dates.
The 855 is a business response, which makes it different from the 997 functional acknowledgment that only confirms a document was received and is syntactically valid. Buyers use 855 data to plan inventory and replenishment, so many retailers require it within a defined window after the purchase order.
How to read this diagram: the top row shows who sends the 855, to whom, and which documents usually come before and after it. The lower part shows what X12 release 004010 itself requires: the envelopes around the 855 and the segments and loops the standard marks as required, area by area. Optional loops are listed by the segment that starts them rather than drawn in full. This is the standard's minimum, not a trading partner's requirement: each partner's implementation guide usually makes some optional loops mandatory, restricts the codes and may use a different release.
When it is used
- Confirming that a supplier can fill a purchase order as sent
- Reporting backorders, substitutions, quantity changes or price changes on specific lines
- Rejecting lines or whole orders that cannot be fulfilled
- Providing estimated ship or delivery dates for planning
Where it fits in the document flow
Structure
Key segments in the 855
The segments most implementations use, described in plain language. The last column shows what X12 release 004010 itself requires: "Required" marks a segment the standard requires in every 855; "Optional, common" marks a segment the standard leaves optional, or that sits in an optional loop, but that implementations often use. This is the standard's requirement, not your trading partner's: each partner's implementation guide names the release it uses, makes some optional segments mandatory and restricts the values, and requirements can differ between releases. The requirement status comes from one published X12 reference listing and has not been checked against a second source.
| Segment | Name | What it carries | In X12 004010 |
|---|---|---|---|
| BAK | Beginning Segment for Purchase Order Acknowledgment | Acknowledgment type (accepted, accepted with changes, rejected), purchase order number and purchase order date. | Required |
| REF | Reference Identification | Supporting references such as vendor order number or department. | Optional, common |
| N1 loop | Party Identification | Parties such as ship-to location, echoed from the purchase order when required. | Optional, common |
| PO1 | Baseline Item Data | The original line item being acknowledged, with quantity, price and identifiers. | Optional, common |
| ACK | Line Item Acknowledgment | Line status such as accepted, backordered, changed or rejected, with quantity and scheduled date. | Optional, common |
| CTT | Transaction Totals | Number of line items, used as a control total. | Optional, common |
Example
Sample EDI 855
The supplier acknowledges purchase order PO123456 with line detail (AC). The ACK segment accepts the line for 24 units (IA) and gives a scheduled ship date.
Illustrative data only, not tied to one X12 release or trading partner. The interchange (ISA/IEA) and functional group (GS/GE) envelopes are omitted for readability.
ST*855*0001~
BAK*00*AC*PO123456*20261015~
PO1*1*24*EA*12.50**UP*012345678905~
ACK*IA*24*EA*068*20261101~
CTT*1~
SE*6*0001~The sample is the same one shown above, with a note beside each segment the first time it appears. Segment IDs are highlighted at the start of each line; the fields after them are separated by asterisks, and each segment ends with a tilde.
Avoid problems
Common 855 errors and how to prevent them
Not echoing the purchase order exactly
Buyers match the 855 to the original order by purchase order number and line identifiers. Altered or missing references cause rejections.
Sending a 997 instead of an 855
A 997 only confirms receipt. Partners that require an 855 expect a business-level confirmation of each line.
Late acknowledgments
Many retailers expect the 855 within a set window. Automating it from order entry avoids compliance issues.
Trading partners
Integration guides that include the 855
How ECOM helps
Automate the 855 with ECOM
Solution
Order-to-Cash Automation
Automate the flow from purchase order to payment across every customer channel.
Product
PRISM-SCV
Order lifecycle visibility, response monitoring, routed alerts and business-identifier search across your B2B transactions.
Solution
EDI Integration
Exchange X12 and EDIFACT documents with partners and integrate them directly with your ERP.
EDI 855 FAQs
What is the difference between an 855 and a 997?
A 997 confirms that a document was received and is syntactically valid. An 855 confirms the business details of a purchase order, such as accepted quantities, prices and dates.
Is the EDI 855 always required?
No. Requirements depend on the trading partner and program. Many retailers require it, while other buyers rely on the ship notice and invoice instead.
Can an 855 change prices or quantities?
Yes. The 855 can report line-level changes such as backorders, quantity changes, price changes or substitutions, if the buyer accepts those codes.
More general questions about EDI are answered in the EDI FAQ.
Need help with the EDI 855?
ECOM maps, tests and monitors X12 documents for your trading partners and integrates them with your ERP.