You've just signed a deal with a major retailer. The excitement lasts about six minutes, until their compliance team sends you a 47-page specification document. You open it. It's full of four-digit numbers. 850. 997. 856. 810. The cover email says you have 90 days to be "fully EDI compliant" or the first order gets cancelled and the second one comes with a chargeback.
If you've been here, you know the feeling. If you haven't, here's the shortcut: the numbers are transaction codes from a standard called ANSI X12, maintained by the Accredited Standards Committee X12. Each code represents a specific document type in a B2B conversation — a purchase order, an invoice, a shipping notice. There are more than 300 of them. In practice, five matter for most ops managers selling into retail.
This is the guide you'll want to bookmark.
The Conversation Between You and Your Retailer
Before the codes make sense, it helps to understand the sequence. An EDI conversation between a retailer and a supplier looks like this:
- The retailer sends you a purchase order (EDI 850)
- You confirm you received it with a functional acknowledgement (EDI 997)
- You confirm whether you can actually fulfil it with a purchase order acknowledgement (EDI 855)
- When the goods ship, you send an advance ship notice (EDI 856)
- After delivery, you send an invoice (EDI 810)
Every step can trigger a chargeback if you get it wrong. Let's go through each one.
EDI 850 — Purchase Order
This is the one most people recognise. An EDI 850 is an electronic purchase order. The retailer generates it in their ERP or order management system and sends it to you. It contains:
- Buyer and seller identifiers
- Purchase order number
- Ship-to address(es) — often a distribution centre, not a store
- Line items with SKU/UPC, quantity, unit price, and sometimes retailer-specific product codes
- Delivery date window (earliest and latest)
- Payment and shipping terms
- Any special instructions
The 850 is the thing that kicks everything else off. When it lands in your system, the clock starts ticking. For most retailers you have a window — often 24 to 48 hours — to acknowledge it and confirm you can deliver.
Common mistake: Treating an 850 as final the moment it arrives. Retailers frequently send updated 850s that replace or modify earlier ones. If your system doesn't handle replacements cleanly, you'll end up shipping against stale data.
EDI 997 — Functional Acknowledgement
The 997 is the smallest and most overlooked of the five. It's not a business document — it's a machine-to-machine receipt. When you receive an 850, your EDI system is expected to send back a 997 within a specified time window (often one hour, sometimes 24 hours). The 997 simply says: "I received your message, and it's structurally valid" (or "it's not, and here's why").
A 997 does NOT mean you accept the order. It does NOT mean you can fulfil it. It just confirms the technical handshake worked.
Common mistake: Treating the 997 as optional. Many retailer compliance programs specifically require a 997 response within a tight window, and missing them triggers automatic chargebacks even when everything else works. The 997 is the easiest compliance item to get right and the easiest one to forget.
(In the EDIFACT world, which is more common in Europe, the equivalent is called a CONTRL message. Same purpose, different standard.)
EDI 855 — Purchase Order Acknowledgement
This is where the real business conversation happens. After receiving the 850 and sending a 997 to confirm the handshake, you then send an 855 to tell the retailer whether you can actually fulfil the order.
An 855 can be one of three things:
- Full acceptance — yes, we'll ship the whole order as-is
- Partial acceptance — we'll ship some of these lines, but not all
- Rejection — we can't fulfil this order (with a reason code)
Partial acceptances are common. You might have five line items but be out of stock on two. Your 855 tells the retailer exactly which lines you'll ship, in what quantities, at what price, with what delivery date. This is where pricing discrepancies get surfaced. If the 850 said £12 per unit and your system says £12.50, the 855 is where you flag it.
Common mistake: Not sending an 855 at all. Some suppliers assume that if they just ship the goods, the retailer will figure it out. They won't. Missing 855s are one of the most common sources of retail chargebacks because they break the retailer's planning systems.
EDI 856 — Advance Ship Notice (ASN)
The 856 is the one that causes the most grief. It's the electronic version of a packing slip — but with a twist. It has to be sent before the goods arrive. Hence the name: advance ship notice.
A complete 856 describes the entire shipment hierarchy:
- Shipment — total weight, carrier, tracking, expected delivery date
- Orders — which purchase orders are in this shipment
- Packs/cartons — how the items are physically packaged
- Items — SKU, quantity, and which carton each item is in
Big retailers use the 856 to pre-receive the shipment in their warehouse management system. When the truck arrives at the DC, a scanner reads the GS1-128 barcode on each carton, matches it against the 856 you sent, and the goods are received automatically without manual counting. This is how modern DCs process hundreds of inbound trucks a day.
If your 856 is wrong — missing cartons, mismatched SKUs, incorrect quantities — the automated receiving process fails and the DC workers have to count by hand. Retailers charge you for that. Heavily.
Common mistake: Sending the 856 too late. Retailers usually require the ASN to arrive before the physical shipment does — sometimes hours before. If the goods show up at the DC without a valid 856 already on file, the truck might be turned away.
EDI 810 — Invoice
Finally, after the goods have been delivered and received, you send an invoice. The 810 is straightforward on the surface: it's an electronic invoice. But it has to match two other documents exactly — the 850 (what was ordered) and the 856 (what was shipped).
If the quantities, unit prices, or totals on your 810 don't reconcile with the 850 and 856, the retailer's automated matching system flags it as a discrepancy and holds payment until a human resolves it. In retail, "hold payment" can mean 60, 90, or 120 days added to your cash cycle.
Common mistake: Invoicing for the ordered quantity when the shipped quantity was different. Your 810 has to match what you actually shipped, not what was originally ordered. If you shipped 98 cases instead of 100, invoice 98.
The Full Picture — A Comparison Table
| Code | Name | Who sends it | What it does | Typical response window |
|---|---|---|---|---|
| 850 | Purchase Order | Retailer → Supplier | Orders goods | Arrives at any time |
| 997 | Functional Ack | Either direction | Confirms technical receipt of any EDI message | 1 to 24 hours |
| 855 | PO Acknowledgement | Supplier → Retailer | Confirms or rejects the order (in whole or part) | 24 to 48 hours after 850 |
| 856 | Advance Ship Notice | Supplier → Retailer | Describes the physical shipment before it arrives | Before the goods arrive at the DC |
| 810 | Invoice | Supplier → Retailer | Bills for delivered goods | After delivery, per payment terms |
The EDIFACT Equivalents (For Europe)
If you're dealing with European retailers, they'll likely use EDIFACT instead of X12. The concepts are identical; only the names change. Here's the mapping:
| X12 (US) | EDIFACT (International) | Purpose |
|---|---|---|
| 850 | ORDERS | Purchase Order |
| 997 | CONTRL | Functional Acknowledgement |
| 855 | ORDRSP | Order Response |
| 856 | DESADV | Despatch Advice |
| 810 | INVOIC | Invoice |
EDIFACT is maintained by UN/CEFACT, a United Nations body. If you're selling into multiple regions, you'll end up dealing with both standards — and the same purchase order might arrive as an 850 from one retailer and an ORDERS from another.
Why This Is Harder Than It Looks
Reading this guide, it seems manageable. Five codes, a few rules per code, send the right ones at the right time. In practice, most suppliers struggle with EDI for three reasons that have nothing to do with the codes themselves:
Every retailer has their own flavour. Walmart's 850 looks different from Target's 850 looks different from Tesco's ORDERS. The standard defines what's possible; each retailer specifies what's required, which segments to use, and in what order. That spec document you were sent? It's their interpretation of the standard. You need a new mapping for every retailer.
The specs change. Retailers update their requirements. A new field appears. An optional segment becomes mandatory. If your system was mapped a year ago and hasn't been touched since, it's probably slightly out of compliance already. Nobody tells you until a chargeback lands.
The failure modes are silent. A missing 997, a late 856, an 810 that doesn't match the 856 — none of these produce a loud error. They produce a chargeback three weeks later, in a deduction line on an invoice nobody reads. By the time you notice, it's already cost you money.
The Alternative: Making the Standard Invisible
For thirty years, the standard solution to EDI complexity has been to hire an EDI specialist or outsource to an EDI managed service. Someone who knows what an 856 looks like, knows which retailers require what, and hand-maps each new trading partner over 60 to 90 days. It works. It's also expensive, slow, and dependent on scarce expertise.
Aduno takes a different approach. Drop in a sample 850 from any retailer and the AI reads it, identifies the format, understands which segments are mandatory, and generates the mapping to your ERP — automatically. Same for the 855, 856, 810. It knows the difference between a Walmart 856 and a Target 856 without you explaining it. When a retailer updates their spec, the system detects the drift and re-maps itself.
You don't stop caring about the 850/855/856/810/997 sequence — you still need to know what these codes do, which is why you read this guide. But you stop manually translating between them. The AI handles the format-level detail, and you get to focus on the things that actually matter: shipping the goods, running the business, growing the account.
B2B integration is broken. Aduno fixes that.
Sources
- Accredited Standards Committee X12 (ANSI ASC X12) — the official body responsible for the X12 EDI standard, including transaction sets 850, 855, 856, 810, and 997
- UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) — the international body responsible for the UN/EDIFACT standard used across Europe and globally
- GS1: Barcode standards (EAN/UPC and GS1-128) — the global standards organisation whose barcodes are used on cartons referenced in 856 advance ship notices