EDI 870 Order Status Report: Codes and Example

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, 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 that often triggers it.

Authoritative references for 870 work:

• The X12 transaction set catalog defines the 870 and 869 and their segment order
• The X12 004010 870 reference shows every segment and loop in the standard, and its Shipment/Order Status Code list 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.

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, 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 against the date you committed to.

Drop ship. In a 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 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:

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~

BSR02 uses the same code list as BSI03 on the 869, so a reply normally echoes the scope of the question:

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. 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~

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:

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.

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), not an 870.

Where the 870 Sits in the Order Flow

1. 850 Purchase Order. The buyer orders.
2. 997 Functional Acknowledgment. You confirm the 850 arrived and parsed.
3. 855 PO 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. Goods ship.
7. 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

Most of these show up later as a confused buyer, a missed fill rate target or a 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 and EDI compliance guide 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 to see it parsed segment by segment with a plain-English summary, read about multi-format order processing, or book a 15-minute walkthrough to see your own orders processed.

Frequently Asked Questions