EDI 869 and 870: Order Status Inquiry and Report Explained

Every Monday a replenishment planner works down a list of open purchase orders and emails suppliers one at a time: has it shipped, when will it ship, is anything backordered? The supplier's customer service desk looks each order up in two systems and types an answer. By Wednesday half the answers are out of date, and the planner is chasing the same orders again.

The X12 869 Order Status Inquiry and 870 Order Status Report replace that loop with a question and an answer both systems can read. Paired correctly, with status codes driven by warehouse and transport events rather than typed by hand, the exchange removes most routine status calls and gives the planner a dated, line-level answer the ERP can act on.

• What this guide covers: how BSI scopes an inquiry, how BSR and PRF tie the report back to it, which ISR status codes are worth sending, the pairing rules, and how the same pattern looks in India's Beckn-based order networks.
• What it adds: a sample inquiry and report, a status mapping table, a timestamped failure trace, and a worked cost model in US ($) and India (₹) for the calls avoided.

What an 869 asks and what a matching 870 must answer

An 869 is a buyer's question about orders already placed, and an 870 is the supplier's dated, line-level answer. X12 describes the 869 as a request for information about a purchase order, selected line items or selected products, covering ordered, unshipped or shipped items. The 870 reports the current status of a forecast, purchase order, line items or requisitions.

The 870 does more than answer. X12 notes that it can also be used to update the supplier's scheduled shipment or delivery dates, and it can be sent on a prearranged schedule or unprompted rather than only in reply to an 869. That makes it the supplier's channel for saying "this line will now ship on the 21st", which a purchase order acknowledgment sent at order time cannot do weeks later.

Our guide to 214 carrier status and 210 freight invoices covers the in-transit half of the picture. This article stays on the supplier's side of the dock, where the order is still being made, picked or held.

Scoping the question with BSI order and item codes

The BSI segment decides how much the supplier must report, and a vague scope produces an 870 too large to use. BSI-01 is the inquiry reference number, BSI-02 the inquiry date and BSI-03 the mandatory Order/Item Code. BSI-06 can carry the inquiry time, which matters when the buyer sends more than one inquiry a day.

• All orders, all items (CA): asks for every open order. Useful once, during onboarding, to reconcile the buyer's open order book against the supplier's.
• All orders, changed status (AO): asks only for items whose status changed. The cheapest routine inquiry for both sides.
• All orders, unshipped (CO) or shipped (CI): narrows the answer to one side of the dock.
• Selected orders (PA, PO, PI, PP): the inquiry lists the orders in the detail area, asking for all items, unshipped items, shipped items or selected items respectively.

In the detail area, each HL loop can carry a PRF segment naming one purchase order in PRF-01, with an optional release number and change order sequence. LIN, PID and QTY in the same loop narrow the question to specific products. CTT-01 in the summary counts the HL segments, which gives the supplier a quick completeness check before it builds the answer.

Routine order status inquiries in X12 869 should use BSI-03 code AO, all orders with changed status, once or twice a day, keeping the supplier's 870 report small; a full CA inquiry is best kept for onboarding, when the buyer's open order book is reconciled against the supplier's ERP line by line.

Building the 870 report from BSR, PRF and ISR segments

The 870 header states why the report exists, and the detail gives one status per order line. BSR-01 is the Status Report Code: 1 means a response to an 869, 2 a prearranged schedule and 3 an unsolicited report. BSR-02 repeats the Order/Item Code, BSR-03 is the supplier's report number and BSR-04 the report date.

• Inquirer's reference: BSR-08 carries the status report document number assigned by the inquirer, which is where the 869's BSI-01 reference belongs.
• Order and line: inside each HL loop, PRF-01 names the purchase order and PO1 identifies the line, quantity and product.
• Status per line: the ISR loop carries ISR-01, the two-character Shipment/Order Status Code, with ISR-02 as a date and ISR-03 as an optional three-character status reason code.

The sample shows a selected-orders inquiry for two unshipped purchase orders and the matching report. The second half of the code block states the pairing test the buyer's integration runs before any status reaches the ERP.

ST*869*0001~
BSI*SQ-77120*20261110*PO***0915~
HL*1**O~
PRF*4500018832~
HL*2**O~
PRF*4500018907~
CTT*2~
SE*8*0001~

ST*870*0001~
BSR*1*PO*SR-55031*20261110***0931*SQ-77120~
HL*1**O~
PRF*4500018832~
HL*2*1*I~
PO1*1*240*EA***VN*KT-4410~
ISR*PS*20261114~
HL*3**O~
PRF*4500018907~
HL*4*3*I~
PO1*1*96*EA***VN*KT-4425~
ISR*BP*20261121~
CTT*4~
SE*14*0001~

-- pairing test, applied per inbound 870
-- paired     = (BSR01 = '1') AND (BSR08 = BSI01 of an open inquiry from this partner)
-- in_scope   = every PRF01 in the 870 was listed in that 869 (BSI03 = PA, PO, PI or PP)
-- overdue    = no paired 870 within W minutes of the 869 (W agreed per partner, e.g. 120)
-- accept the report only when paired AND in_scope; otherwise route to the EDI exception queue

Two status lines are enough to see why the codes matter. PS says the line is in process and scheduled to ship on the 14th; BP says part of the line will ship and the rest is backordered to ship on the 21st. A planner can act on both without a phone call, provided the codes mean the same thing to both systems.

Mapping warehouse and order events to ISR status codes

An ISR code is only trustworthy when an event in the supplier's systems sets it, not a person choosing from a list. The 4010 code list for element 368 holds more than a hundred values; most partners agree on fewer than fifteen. The table maps common supplier events to codes from that list and to the action the buyer's planner takes.

The 4010 segment reference adds a rule for dated codes: if ISR-01 specifies a date, ISR-02 is required. Make the translator reject an outbound PS, BP, SI or SH line with no date before it leaves the supplier, because the buyer can do nothing useful with "scheduled to ship on" and no date.

Pairing every 870 with the inquiry that prompted it

An 870 that cannot be tied to its inquiry is a status message of unknown scope, and it should not update a single receipt date. The pairing key is the inquiry reference: the buyer's BSI-01 returned in the supplier's BSR-08, together with BSR-01 = 1. The buyer then checks that every purchase order in the report was one it asked about.

• Exactly one open inquiry: the buyer marks the 869 answered on the first valid 870 and rejects a second 870 for the same reference as a duplicate, unless the partner agreement allows split reports.
• Unasked orders: a PRF-01 that was not in a selected-orders inquiry suggests the supplier answered a different question. Hold the whole report rather than apply part of it.
• Scheduled and unsolicited reports: BSR-01 values 2 and 3 have no inquiry to pair with; apply them by purchase order and line, and only from partners whose profile allows them.
• Silence: if no paired 870 arrives within the agreed window, alert the EDI analyst first, not the planner, because the cause is usually a mapping or transport failure.

Buyer-side pairing of X12 870 Order Status Reports accepts a report into the ERP purchasing module only when BSR-01 equals 1, BSR-08 matches an open 869 BSI-01 reference, and every PRF-01 purchase order was in scope; partners meeting a 120-minute reply window let planners stop most routine status calls.

The purchase order acknowledgment and the order status report are easy to confuse. The acknowledgment confirms what the supplier accepted when the order arrived. The status report describes where accepted lines stand later. A buyer that receives both should let the newer dated status override the acknowledged date, and keep both in the history for supplier scorecards.

A status report that said shipped before the trailer left

The worst 870 is a confident wrong one, because it stops the buyer from acting while there is still time. The trace below follows a single selected-orders inquiry for two purchase orders, with a map that read the wrong warehouse event.

1. 10 Nov 2026, 09:15: The buyer sends 869 SQ-77120 with BSI-03 = PO, asking about unshipped items on purchase orders 4500018832 and 4500018907. The first has an expedite open because a promotion starts on the 14th.
2. 09:31: The supplier returns 870 SR-55031. For 4500018832 line 1 it reports ISR*SH*20261110, because the map set SH when the WMS marked the load as built, not when the carrier left.
3. 09:40: The planner sees SH, closes the expedite and releases the safety stock held at the regional warehouse to another customer.
4. 11:40: A trailer audit at the supplier finds 60 of the 240 eaches unpicked. The carrier departs at 14:05 with 180, and the 856 ship notice at 14:20 confirms 180. No corrected 870 is sent.
5. 14 Nov, 07:00: The promotion opens 60 units short across 12 stores. The controlled version sets SH only from the TMS departure event, would have reported BP with the remainder's date, and sends an unsolicited 870 (BSR-01 = 3) whenever an earlier status is contradicted.

Comparing the 870 with the 856 for the same purchase order would also have caught it within minutes. A shipped status with no ship notice after an agreed interval, or a ship notice quantity below the reported line quantity, is a rule a buyer can run automatically. Our article on reconciling 940 warehouse orders with 945 shipping advice applies the same comparison inside a 3PL relationship.

Who owns each part of an order status answer

An 870 draws on several systems on the supplier side, so each element needs an owner who signs off its mapping. If nobody owns the ship-date logic, it will default to whatever the first developer chose. The table lists who supplies each element and who approves changes to how it is derived.

Status calls avoided, priced in dollars and rupees

The financial case rests on handling time saved on both sides of the relationship, not on EDI charges. The model below compares a US distributor asking about its suppliers' orders with an Indian exporter answering US customers. Volumes, minutes per query and the share of queries an 870 can answer are illustrative; replace them with a week of your own call and email logs.

The thirty percent left over is real work: disputes, quality questions and requests for an earlier date. Those should reach a person faster once the routine queries are gone. Track the remaining manual queries by reason for a month after go-live; if "where is my order" still appears, the 870 coverage or its status codes are not good enough yet.

India: X12 exporters and Beckn-style status callbacks

The 869 and 870 are US X12 transaction sets with no Indian statutory counterpart, so the India case is either an exporter using X12 or a domestic network using a different protocol. Indian manufacturers and 3PLs serving US retailers and distributors receive 869s and send 870s exactly as described above; only their labour and system costs sit in rupees.

Domestic Indian retail networks use a different but recognisable pattern. ONDC's retail specifications state that they are built on the Beckn protocol, whose transaction API defines a status call that fetches the latest order object and an on_status callback that returns it. The immediate reply is only an acknowledgment; the order data arrives in the callback, matched by a message_id that persists through the request and callback cycle.

Order status pairing works the same way in X12 and in Beckn: the X12 870 echoes the 869 inquiry reference in BSR-08, while a Beckn on_status callback carries the message_id of the status request; in both, a reply without a matching key should change zero order records.

Which status checks stay fixed and where software helps a planner

Pairing, scoping and code validity are fixed checks that run unattended; estimating new dates and explaining delays is where software can help a person. The split keeps automated suggestions out of the receipt dates the ERP plans against until a planner accepts them. Our overview of 856, 940, 945 and 214 integration shows where these messages sit among the others a distribution network exchanges.

Rolling out 869 and 870 with partners and measuring the first month

Start with three to five suppliers who already exchange 850s and 856s, agree a short status code list, and run the exchange beside the existing emails for four weeks. This piece is part of our logistics and supply chain library; for software choices in dropship flows, see the dropship ASN and invoice reconciliation buyer guide, which covers matching after shipment rather than status before it.

If you are planning order status messaging across many suppliers or customers, or want status driven by warehouse and transport events rather than typed by hand, you can describe your partners, systems and volumes through our request for proposal form.