# EDI 870 Order Status Report: Codes and Example
> EDI 870 explained: BSR, HL, PO1 and ISR segments, status codes, solicited vs unsolicited reports, backorder and drop-ship examples, and common errors.
The EDI 870 Order Status Report is the X12 transaction a supplier sends to tell a buyer where its purchase orders stand: shipped, partly shipped, backordered, delayed or canceled, line by line, with new dates. It is sent in reply to an 869 Order Status Inquiry, on an agreed schedule, or unsolicited whenever status changes.
**The EDI 870 is the supplier's answer to "where is my order?"** It sits between the order acknowledgment and the ship notice. The 855 said what you would ship. The 856 says what you did ship. The 870 covers everything in between: lines that slipped, lines on backorder, lines you canceled, and the date each one will move.
This guide covers what the 870 carries, the three reasons one gets sent (a reply to an 869, a scheduled report, or an unsolicited update), two live examples (a backorder reply and a drop-ship status feed), every segment you will map, the ISR status codes, and the errors that cause rejections.
## What Is an EDI 870?
**An EDI 870 is the Order Status Report transaction set defined by the [ASC X12 standards body](https://x12.org/products/transaction-sets), used by a seller to report the current status of one or more purchase orders, or selected lines on them, to the buyer.** It travels in the order status functional group (`GS01` = `RS`), the same group as the [869 Order Status Inquiry](/guides/edi/869-order-status-inquiry) that often triggers it.
Authoritative references for 870 work:
- The [X12 transaction set catalog](https://x12.org/products/transaction-sets) defines the 870 and 869 and their segment order
- The [X12 004010 870 reference](https://www.stedi.com/edi/x12-004010/870) shows every segment and loop in the standard, and its [Shipment/Order Status Code list](https://www.stedi.com/edi/x12-004010/element/368) holds the full set of values used in the `ISR` segment
- Each buyer's 870 implementation guide sets which of those segments and codes it accepts, and when it wants the report
**Who sends it?** The supplier (seller, vendor), from its order management or ERP system.
**Who receives it?** The buyer: a retailer, distributor or manufacturer that issued the purchase order.
**When is it sent?** In reply to an 869 inquiry, on a schedule the partners agreed (often daily for open orders), or whenever the status of an order changes.
**Why does it matter?** A buyer that cannot see a delay plans around the original date. It promises stock to stores or delivery dates to consumers that you cannot meet. The 870 is how the delay reaches its system before the date passes, not after.
## Three Reasons an 870 Gets Sent
The first element of the 870, `BSR01`, says why the report exists. Three values cover nearly every commercial use.
| `BSR01` | Meaning | Trigger | Typical use |
|---|---|---|---|
| `1` | Response to an Order Status Inquiry (869) | The buyer sent an 869 | Answering a buyer that is chasing late or open orders |
| `2` | Prearranged Schedule or Agreement | A schedule in the trading agreement | Daily or weekly status on every open PO |
| `3` | Unsolicited Report | Your own system, when status changes | Pushing a backorder, delay or cancellation as it happens |
The X12 code list for `BSR01` has more values (twelve in 004010), most of them used in government and military supply. Your partner's guide will name the one or two it expects.
**Solicited (reply to an 869).** The buyer asks, you answer. The 869 names the purchase orders and, optionally, the specific lines. Your 870 returns status for exactly that scope and carries the inquiry's reference number so the buyer can match the answer to the question. Some buyers generate the 869 automatically when no ship notice or status report has arrived by the scheduled ship date, and keep sending it until they get one, so a missing 870 can produce a steady stream of inquiries.
**Unsolicited.** You report without being asked, usually when something changes. This is the common pattern in drop ship, where the retailer has promised a delivery date to a consumer and needs to hear about a delay the same day.
**Scheduled.** You report on a fixed cadence, often every open order or every order with a change. This suits buyers that want a full picture of open orders rather than individual exceptions.
## Backorders, Delays and Drop Ship: What the 870 Is For
The 870 earns its place in three situations.
**Backorders.** You accepted a line on the 855, but stock did not arrive. The 870 tells the buyer how much shipped, how much is on [backorder](/glossary/backorder), and when the rest will ship. That lets the buyer decide whether to wait, cancel the balance, or buy elsewhere, instead of finding out at receiving.
**Late shipments and ship date changes.** The order is still coming, but not on the promised date. An 870 with a revised expected ship date moves the buyer's plan before the original date passes. That matters most for buyers that measure [on-time in-full](/glossary/otif) against the date you committed to.
**Drop ship.** In a [drop-shipping](/glossary/drop-shipping) program, the retailer takes the consumer's order and payment, and you ship from your warehouse to the consumer's door. The retailer's customer service team answers "where is my order?" from whatever you have told it. Many drop-ship programs use the [856 ship notice](/guides/edi/856-ship-notice) for shipment confirmation with tracking, and the 870 for everything that is not a shipment yet: a delay, a backorder, or a line you cannot fill and are canceling. The retailer's drop-ship guide says which status codes it accepts and how fast it expects to hear.
## Interactive Example: 870 Reply to an 869 (Backorder)
A home goods retailer sent an 869 asking about lines 1 and 3 on purchase order `4500087321`. The supplier answers with an 870. `BSR01` is `1` (a response to an 869), `BSR02` is `PP` (selected orders, selected items), and `BSR08` carries the retailer's inquiry number `INQ-20261104-0031` so the two documents tie together.
Line 1 ordered 24 lamps. Sixteen shipped and eight are on backorder to ship on November 18 (`ISR*BP`, with a shipped `QTY` and a backorder `QTY`). Line 3 is fully backordered and expected to ship by December 2 (`ISR*ED`).
Use the **Plain English** tab for a readable summary, or click any segment to break it down element by element.
## Interactive Example: Unsolicited Drop-Ship 870
The same supplier sends unsolicited status on drop-ship orders each afternoon (`BSR01` = `3`). This interchange carries two 870s, one per purchase order, because many retailers allow only one PO per 870. Each order carries the consumer's web order number in `REF*CO`.
The first order shipped on November 3 (`ISR*SH`). On the second, the lamp is late and now scheduled to ship November 9 (`ISR*SI`), and the shade line is canceled (`ISR*IC`). The retailer can tell the consumer about the delay and refund the shade the same day.
## 870 Structure at a Glance
The 004010 standard allows many optional segments (carrier details, addresses, measurements, allowances). Most retail 870s use a small subset:
| Position | Segment | Name | Usage | Notes |
|---|---|---|---|---|
| Header | **ST** | Transaction Set Header | Mandatory | `ST01` = `870` |
| Header | **BSR** | Beginning Segment for Order Status Report | Mandatory | Reason, scope, report number and date |
| Header | **DTM** | Date/Time Reference | Optional | Header-level dates some buyers require |
| Header | **N1** loop | Name | Optional | Buyer, supplier or ship-to parties |
| Detail | **HL** | Hierarchical Level | Mandatory | Usually an order level (`O`) and item levels (`I`) |
| Detail | **PRF** | Purchase Order Reference | Optional, usually required | The PO number and date being reported |
| Detail | **REF** | Reference Identification | Optional | Extra references, such as a consumer order number in drop ship |
| Detail | **DTM** | Date/Time Reference | Optional | Order-level dates |
| Detail | **PO1** loop | Baseline Item Data | Optional, usually required | The PO line being reported |
| Detail | **ISR** | Item Status Report | Mandatory in its loop | The status code and date for the line |
| Detail | **QTY** | Quantity | Optional | Shipped, backordered, canceled or other quantities |
| Summary | **CTT** | Transaction Totals | Optional | A count, usually of line items |
| Summary | **SE** | Transaction Set Trailer | Mandatory | Segment count and control number |
The `ISR` loop can appear at the order level (status for the whole PO) or inside the `PO1` loop (status for one line). Line-level status is the more common pattern in retail. Treat "optional" as "optional unless your partner's guide says otherwise".
## Key Segments Explained
### BSR: Beginning Segment for Order Status Report
```
BSR*1*PP*OSR-77120*20261104***1130*INQ-20261104-0031*20261104~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **BSR01** | Status Report Code | `1` | Why the report was sent: `1` reply to an 869, `2` prearranged schedule, `3` unsolicited |
| **BSR02** | Order/Item Code | `PP` | What the report covers (see the scope table below) |
| **BSR03** | Reference Identification | `OSR-77120` | Your status report number |
| **BSR04** | Date | `20261104` | Report date, CCYYMMDD |
| **BSR05** | Product/Date Code | | Rarely used in retail |
| **BSR06** | Location Code | | Rarely used in retail |
| **BSR07** | Time | `1130` | Report time |
| **BSR08** | Reference Identification | `INQ-20261104-0031` | The inquirer's reference: the 869 number you are answering |
| **BSR09** | Date | `20261104` | The date of that inquiry |
`BSR02` uses the same code list as `BSI03` on the 869, so a reply normally echoes the scope of the question:
| Code | Scope |
|---|---|
| `PP` | Selected orders, selected items |
| `PA` | Selected orders, all items |
| `PO` | Selected orders, unshipped items |
| `PI` | Selected orders, shipped items |
| `CA` | All orders, all items |
| `CO` | All orders, unshipped items |
| `CI` | All orders, shipped items |
| `AO` | All orders, items with changed status |
### HL: Hierarchical Level
```
HL*1**O~
HL*2*1*I~
```
`HL01` is a sequence number, `HL02` points to the parent level, and `HL03` names the level. In most 870s, `O` (order) carries the PO reference and `I` (item) carries each line. Unlike the 856, there is no shipment level at the top, because nothing has necessarily shipped.
### PRF: Purchase Order Reference
```
PRF*4500087321***20261020~
```
`PRF01` is the buyer's PO number and `PRF04` the PO date. The buyer matches your report to its open order on these two values, so send them exactly as they appeared on the [850 purchase order](/guides/edi/850-purchase-order). A PO number with an extra prefix, dropped leading zeros, or the wrong date is the most common reason an 870 lands in the buyer's error queue.
### PO1: Baseline Item Data
```
PO1*1*24*EA*42.00**UP*085519001205*VN*CL-LAMP-BRS~
```
The 870 repeats the PO line so the buyer can identify it: `PO101` is the line number from the original order, `PO102` the quantity ordered, `PO103` the unit, `PO104` the unit price, then product ID qualifier and value pairs (here a UPC and the vendor item number). Echo the line number and identifiers from the 850. Many buyers match on `PO101` first and reject a line number they did not send.
### ISR: Item Status Report
```
ISR*BP*20261118~
```
| Element | Name | Example | What it means |
|---|---|---|---|
| **ISR01** | Shipment/Order Status Code | `BP` | The status of the line or order |
| **ISR02** | Date | `20261118` | The date that goes with the status. Required when the code names a date |
| **ISR03** | Status Reason Code | | An optional reason, from a separate code list |
`ISR` is the heart of the 870. The 004010 code list has more than a hundred values. These are the ones retail and drop-ship guides use most:
| Code | Meaning | Date in `ISR02` |
|---|---|---|
| `SH` | Shipped | The ship date |
| `BP` | Shipment partial, back order to ship on (date) | When the balance ships |
| `BO` | Back ordered | Optional |
| `CP` | Partial shipment on (date), considered no backorder | The ship date |
| `ED` | Expect to ship by (date) | The expected ship date |
| `RD` | Revised expect to ship by (date) | The new expected ship date |
| `SI` | Shipment late, scheduled to ship on (date) | The new scheduled date |
| `IN` | In process | Optional |
| `IC` | Item canceled | Optional |
| `DI` | Discontinued | Optional |
| `IS` | Item represents substitution from original order | Optional |
| `CC` | Shipment complete on (date) | The completion date |
Most buyers accept only a handful of these. A code that is valid X12 but missing from the buyer's list is a common rejection, so build your status mapping from the buyer's guide, not from the full standard.
### QTY: Quantity
```
QTY*39*16*EA~
QTY*BQ*8*EA~
```
`QTY01` qualifies the quantity, `QTY02` is the number and `QTY03` the unit. Qualifiers seen on 870s include `39` (shipped quantity), `BQ` (backorder quantity), `QV` (quantity cancelled) and `01` (discrete quantity). Some buyers ask for a single `QTY` per status; others want shipped and backordered quantities side by side, as in the example. The quantities on a line should add up to `PO102`.
### CTT: Transaction Totals
```
CTT*2~
```
`CTT01` is a count the receiver checks. On the 870 it is usually the number of `PO1` line items; some guides count `HL` segments instead. Generate it from the data you are sending, never as a constant.
## EDI 870 vs 855, 856, 865 and 869
These documents are easy to mix up because they all talk about the same purchase order.
| Document | Sent by | Answers the question | When |
|---|---|---|---|
| **[855 PO Acknowledgment](/guides/edi/855-purchase-order-acknowledgment)** | Supplier | Will you fill this order, and on what terms? | Once, soon after the 850 arrives |
| **870 Order Status Report** | Supplier | Where does this order stand right now? | On request, on a schedule, or when status changes |
| **[856 Ship Notice](/guides/edi/856-ship-notice)** | Supplier | What exactly shipped, in which cartons, on which truck? | When goods leave the dock |
| **[865 PO Change Acknowledgment](/guides/edi/865-purchase-order-change-acknowledgment)** | Supplier | Do you accept the buyer's change, or propose one of your own? | In reply to an 860, or to propose a change |
| **[869 Order Status Inquiry](/guides/edi/869-order-status-inquiry)** | Buyer | Where is my order? | When the buyer wants status |
The short version: the 855 is a commitment, the 870 is a progress report against it, and the 856 is proof of shipment. An 870 does not change the order. If you need the buyer to agree to a different quantity, price or item, that is an 865 (or a buyer's [860 change](/guides/edi/860-purchase-order-change)), not an 870.
## Where the 870 Sits in the Order Flow
1. **[850 Purchase Order](/guides/edi/850-purchase-order).** The buyer orders.
2. **[997 Functional Acknowledgment](/guides/edi/997-functional-acknowledgment).** You confirm the 850 arrived and parsed.
3. **[855 PO Acknowledgment](/guides/edi/855-purchase-order-acknowledgment).** You accept, change or backorder each line.
4. **869 Order Status Inquiry (optional).** The buyer asks for status, often when a date is close or has passed.
5. **870 Order Status Report.** You report status: in reply to the 869, on schedule, or unsolicited.
6. **[856 Ship Notice](/guides/edi/856-ship-notice).** Goods ship.
7. **[810 Invoice](/guides/edi/810-invoice).** You bill for what shipped.
Steps 4 and 5 can repeat for as long as a line stays open. A backordered line might get an 870 when it goes on backorder, another when its date moves, and finally an 856 when it ships.
## Common 870 Errors and How to Prevent Them
| Error | What happens | Prevention |
|---|---|---|
| **PO number or date does not match the 850** | Report cannot be matched to an open order; rejected or ignored | Copy `PRF01` and `PRF04` from the stored 850, never from a re-keyed sales order |
| **Line number does not match** | Status applied to the wrong line, or the line is rejected | Echo `PO101` exactly as the buyer sent it |
| **Status code not in the buyer's list** | Line or whole report rejected | Map internal statuses to the buyer's accepted `ISR01` codes only |
| **Date missing on a dated status** | Rejected under X12 syntax rules | Always send `ISR02` with codes that name a date (`BP`, `ED`, `SI`, `SH`, `RD`) |
| **Reply missing the inquiry reference** | Buyer cannot tie the answer to its 869 and keeps asking | Send the 869's `BSI01` back in `BSR08` when the guide uses it |
| **Quantities do not add up** | Buyer's system flags the line, or plans for the wrong amount | Shipped plus backordered plus canceled should equal the ordered quantity |
| **Using the 870 to change the order** | Buyer ignores the change; you ship something it did not agree to | Use the 865 for changes that need the buyer's agreement |
| **No reply to an 869** | Repeated inquiries, and often a manual escalation from the buyer | Answer every 869 within the buyer's window, even when the answer is "on schedule" |
| **870 sent after the 856** | Buyer sees "backordered" after the goods arrived | Suppress status reports for lines already confirmed on an 856 |
| **`CTT01` count wrong** | Transaction rejected | Compute the count from the segments you built |
Most of these show up later as a confused buyer, a missed [fill rate](/glossary/fill-rate) target or a [retail chargeback](/glossary/retail-chargeback) rather than as an EDI error, which is why they persist.
## 870 Implementation Checklist
Before your first live 870 with a new trading partner:
- Get the partner's 870 guide and confirm whether it expects replies to 869s, scheduled reports, unsolicited reports, or a mix
- Confirm the `BSR01` and `BSR02` values it accepts
- Confirm whether it allows more than one PO per 870
- Get its list of accepted `ISR01` status codes, and map each of your internal order statuses to one of them
- Confirm which `QTY` qualifiers it wants and whether `ISR02` dates are required on every line
- Store the 850 exactly as received, so `PRF` and `PO1` can echo it
- Decide what triggers an unsolicited 870 in your system (backorder created, date changed, line canceled)
- For drop ship, agree how fast a delay must be reported and whether cancellations go on the 870 or another document
- Test a reply to an 869, a backorder, a date change and a cancellation
- Monitor 997s and any 824 application advice for rejections in the first weeks
If you are new to EDI, our [EDI document types reference](/edi-document-types) and [EDI compliance guide](/edi-compliance) show how the 870 fits alongside the documents your retailers require.
## Keeping Order Status Accurate With OrderSync
An 870 is only as good as the order data behind it. If a purchase order was keyed in late or with a wrong line number, every status report on it starts wrong. And most suppliers that send 870s to one retailer still receive orders from other customers as PDFs, emails and spreadsheets.
OrderSync reads inbound orders in any format (EDI 850 and 875, PDF, email, spreadsheets), matches customers, items and units to your catalog, and outputs valid X12 or clean data to your ERP. Your order and status data starts from the PO the buyer actually sent. Paste any 870 or 869 into the [free EDI inspector](/edi-inspector) to see it parsed segment by segment with a plain-English summary, read about [multi-format order processing](/multi-format-orders), or [book a 15-minute walkthrough](/book-call) to see your own orders processed.
## Frequently Asked Questions
### What is an EDI 870 used for?
The EDI 870 Order Status Report lets a supplier tell a buyer the current status of its purchase orders: shipped, partly shipped, backordered, delayed or canceled, usually line by line with a date. It is sent in reply to an 869 inquiry, on an agreed schedule, or unsolicited when status changes.
### What is the difference between an EDI 869 and an EDI 870?
The buyer sends the 869 Order Status Inquiry to ask about specific orders or lines. The supplier sends the 870 Order Status Report with the answer. A reply 870 sets BSR01 to 1 and normally carries the 869's reference number in BSR08 so the two can be matched.
### What is the difference between an EDI 855 and an EDI 870?
The 855 is a one-time acknowledgment of a new purchase order, accepting, changing or backordering each line. The 870 reports progress afterwards and can be sent many times while the order is open. If a line goes on backorder after you acknowledged it, the 870 is how you report that.
### Can an 870 be sent without an 869?
Yes. An unsolicited 870 (BSR01 = 3) reports status whenever it changes, and a scheduled 870 (BSR01 = 2) reports on an agreed cadence. Drop-ship programs commonly ask for unsolicited 870s so delays and cancellations reach the retailer quickly.
### What does the ISR segment mean in an EDI 870?
ISR is the Item Status Report segment. ISR01 holds the status code, such as SH (shipped), BP (partial shipment, back order to ship on a date), ED (expect to ship by a date) or IC (item canceled). ISR02 holds the date that goes with the status.
### How do you report a backorder on an EDI 870?
Send the PO line in a PO1 loop with an ISR status such as BP (partial shipment, balance on backorder to ship on a date) or BO (back ordered), the expected date in ISR02, and QTY segments for the shipped and backordered quantities, using the qualifiers your buyer's guide lists.
### Is the EDI 870 used for drop ship orders?
Often, yes. Retailers that run drop-ship programs use the 870 to hear about delays, backorders and cancellations on consumer orders before the promised date, and the 856 to confirm shipment with tracking. The retailer's drop-ship guide sets which status codes and timings apply.
### What functional group is the EDI 870 in?
The 870 is sent in the order status functional group, with GS01 set to RS. The 869 Order Status Inquiry uses the same RS group, so a buyer that sends 869s already has that group set up with you.