X12 transaction guide · Ordering
EDI 870 Order Status Report
The X12 document a supplier sends to report the current status of purchase orders or order lines, such as in process, back-ordered or shipped.
- Sent by
- Supplier or vendor
- Received by
- Buyer or customer
- Standard
- ANSI ASC X12
What is an EDI 870?
The EDI 870 Order Status Report is the ANSI X12 transaction set used to report the current status of orders. It can cover a whole purchase order, selected lines or products, or all of a customer's open orders, and it can explain the reasons for a status. Suppliers can also use it to update the scheduled ship or delivery dates of orders already acknowledged.
An 870 can answer an 869 order status inquiry or follow a prearranged schedule, for example a weekly report on all open orders. Buyers use it to see back orders and delays early, without contacting the supplier, and to keep expected delivery dates in their planning systems current.
How to read this diagram: the top row shows who sends the 870, 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 870 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
- Weekly or daily status of all open purchase orders
- Reporting back orders and revised ship dates
- Answering a customer's 869 order status inquiry
- Updating scheduled delivery dates for critical lines
Where it fits in the document flow
Structure
Key segments in the 870
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 870; "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 |
|---|---|---|---|
| BSR | Beginning Segment for Order Status Report | Why the report is sent (inquiry response or schedule), which orders and items it covers, a report number and date. | Required |
| HL loop | Hierarchical Level | Builds the report structure, for example an order level with item levels beneath it. | Required |
| PRF | Purchase Order Reference | The purchase order the status applies to. | Optional, common |
| PO1 | Baseline Item Data | The order line being reported, with quantity, unit, price and product identifiers. | Optional, common |
| ISR | Item Status Report | The status code for the order or line, an associated date and a status reason. | Optional, common |
Example
Sample EDI 870
A scheduled report (BSR01 2) on selected lines of one order (PP). Line 1 is back-ordered (BO); line 2 is in process and scheduled to ship on 27 October (PS). HL levels group the item lines under the order.
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*870*0001~
BSR*2*PP*OSR5531*20261022~
HL*1**O~
PRF*PO45001~
HL*2*1*I~
PO1*1*36*EA*12.50**UP*012345678905~
ISR*BO~
HL*3*1*I~
PO1*2*12*EA*8.00**UP*012345678912~
ISR*PS*20261027~
SE*11*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 870 errors and how to prevent them
Status codes the buyer does not use
Buyers act on a small set of status codes. Agree the codes and reasons in advance, and map internal order statuses to them consistently.
Reports that contradict the ship notice
An 870 that shows an order as open after the 856 says it shipped confuses planners. Generate status from the same data that drives shipping.
Dates without status
A revised date means little without the status and reason. Send both, so the buyer knows whether a delay is a back order, a production issue or a carrier delay.
How ECOM helps
Automate the 870 with ECOM
Solution
Order-to-Cash Automation
Automate the flow from purchase order to payment across every customer channel.
Industry
Retail
Retail and eCommerce EDI for suppliers and retailers, from purchase order to payment, with compliance built in.
Solution
EDI Integration
Exchange X12 and EDIFACT documents with partners and integrate them directly with your ERP.
EDI 870 FAQs
How is the 870 different from the 855?
The 855 acknowledges a new order once. The 870 reports the status of orders over time, such as back orders or revised ship dates after the order was accepted.
What is the 869?
The 869 is the order status inquiry a buyer can send to ask for status. The supplier answers it with an 870.
Do retailers require the 870?
Some do, especially for drop-ship and special orders where the buyer must update consumers. Many others rely on the 855 and 856 alone.
More general questions about EDI are answered in the EDI FAQ.
Need help with the EDI 870?
ECOM maps, tests and monitors X12 documents for your trading partners and integrates them with your ERP.