The EDI 869/870, Decoded: "Where Is My Order?" Is a Question With a Standard Answer

The EDI 869 · Order Status Inquiry and the EDI 870 · Order Status Report are how a buyer asks, in data instead of email, "where is my order?" — and how a seller answers with the order's real state. The 869 asks about a specific order, line, or shipment. The 870 reports back: accepted, backordered, partially shipped, shipped, or cancelled — with dates, quantities, and reasons, not a shrug.

Most teams meet this pair through the inbox version first. A buyer emails three people asking for a status update, someone screenshots an ERP screen, and the answer is stale before it is read. Multiply that by forty open orders and a peak season, and status-chasing becomes a full-time job on both sides. The 869/870 pair exists so that question and answer can run as a scheduled, system-to-system exchange instead.

What are the EDI 869 and 870?

The 869 · Order Status Inquiry is sent by the buyer (or the buyer's system, on a schedule) to the seller. It identifies what it is asking about — a purchase order number, a line item, a date range, or all open orders — and nothing more. It carries no new commercial terms; it is a question, not a change.

The 870 · Order Status Report is the seller's answer. For each order or line asked about, it reports the current status and the facts behind it: quantity ordered, quantity shipped, quantity backordered, expected ship or delivery dates, and the carrier or shipment reference when the order has left the building.

Three ideas define the pair:

• The inquiry is scoped. An 869 can ask about one troubled line instead of forcing a full open-order dump. Scope keeps the answer small, fast, and readable.
• The report is a snapshot with a timestamp. An 870 does not promise the future — it states what was true when it was generated. Disputes get much shorter when both sides can point to the same dated snapshot.
• Status lives at the line level. An order is rarely simply "shipped." One line shipped complete, one line is backordered, and one line was cancelled — the 870 reports per line, because that is how orders actually behave.

How do the 869 and 870 fit with the 850, 855, and 856?

These messages get confused because they all describe the same order at different moments:

• The 850 · Purchase Order says what the buyer ordered.
• The 855 · Purchase Order Acknowledgment says what the seller agreed to, shortly after the order arrived.
• The 869 · Order Status Inquiry asks, later, what is true now.
• The 870 · Order Status Report answers with the current line-level state.
• The 856 · Advance Ship Notice reports the specific shipment when goods actually leave.

Seen that way, the 855 is the opening position and the 870 is every update after it. A seller who sends a clean 855 and then goes silent until the 856 forces the buyer to ask by email — the 870 is the missing middle of the conversation.

When is an 869 actually needed?

Not every partnership needs scheduled status inquiries. A buyer with a live portal feed or a seller who pushes 870s unsolicited on every status change may never send one. The inquiry earns its place when:

The buyer manages many open orders. Retail and distribution buyers with hundreds of open lines cannot chase status by email; a scheduled 869 sweep is how their system asks all at once.

An order has gone quiet. The expected ship date passed, no 856 arrived, and the buyer needs to know whether the line is backordered or lost — before their own customer asks them.

The answer feeds planning. An 870 that says "backordered to the 28th" lets the buyer reallocate, split a shipment, or warn a downstream customer while there is still time to act.

What breaks in the 869/870 exchange?

The inquiry asks, but nobody's system answers. The 869 lands in a queue no process reads, and the buyer concludes silence means bad news. An unanswered inquiry is worse than none — it erodes trust in the whole EDI flow.

The report is generated from stale data. If the 870 is built from a nightly export while the warehouse ships in real time, the report confidently states yesterday's truth. Snapshot age is part of the answer's quality.

Status codes with no reasons. "Backordered" without an expected date or a reason code forces the buyer to ask again — by email, defeating the point. A useful 870 carries the date and the reason, not just the label.

Order-level answers to line-level questions. Reporting "partially shipped" at the header when the buyer asked about line 3 sends them back to the inbox. The line is the unit of truth.

How should you run order status cleanly?

1. Answer inquiries automatically. The 870 should be generated from the order system, not hand-built in response to an email about an 869.
2. Push the big changes without waiting to be asked. A backorder or a date slip is worth an unsolicited 870 the day it is known, not at the next scheduled sweep.
3. Always carry quantity, date, and reason together. Status alone is a label; those three facts are an answer a planner can use.
4. Timestamp every report and keep them. In a dispute about who knew what when, the dated 870 sequence is the whole record.
5. Treat a rising inquiry rate as a signal. If a buyer suddenly asks more often, their trust or their information is failing somewhere upstream — fix that, not just the queue.

Frequently asked questions

Does an 870 change the order?
No. It reports status only. Changes run through the 860 · Purchase Order Change and the 865 · Purchase Order Change Acknowledgment/Request — the 870 never alters terms, quantities, or dates by itself.

Who sends the 869 — the buyer or the seller?
The buyer sends the inquiry; the seller sends the report. A seller can also send 870s unsolicited when status changes, which is usually the better pattern once volume grows.

How often should status be reported?
Often enough that the answer is still actionable — daily is typical for open retail orders, and immediately on a material change such as a backorder or a missed ship date.

Is the 869/870 pair only for retail?
Retail and distribution are the most common home, but any long-lead or multi-line ordering relationship benefits — manufacturing supply, grocery, and healthcare distribution all use order-status exchanges the same way.

"Where is my order?" is the most common question in B2B commerce, and the most expensive one to answer by hand. The 869/870 pair turns it into what it should have been all along: a small, standard, automatic exchange that runs before anyone has to ask twice.

I build SignalEDI to help SMB teams handle exactly this layer — status reported from the order record itself, at line level, with the dates and reasons attached, instead of screenshots chased through an inbox.

— Chris, founder of SignalEDI