EDI sounds like a technical hurdle, and the acronym-heavy terminology doesn't help, but the underlying idea is simple: it's a standardized electronic format for exchanging routine business documents — purchase orders, invoices, shipping notices — directly between your systems and a retailer's systems, instead of a person on each side re-keying the same information from a PDF or email. Larger retailers require it because at their volume, manually processing purchase orders and invoices for hundreds or thousands of vendors would be an enormous, error-prone operation; EDI lets their systems talk to your systems (or a system acting on your behalf) automatically.

The common transaction sets

EDI transactions are identified by standardized numeric codes, and a handful come up repeatedly in a typical retail vendor relationship:

  • 850 (Purchase Order). The retailer sends this to place an order — it's the electronic equivalent of a PO document, specifying items, quantities, requested delivery dates, and the ship-to location(s).
  • 855 (PO Acknowledgment). Your response confirming you received the 850 and accepting it (in full or with changes) — many retailers require this within a set time window, and a missing or late acknowledgment can itself be a compliance issue independent of whether you actually ship the order correctly.
  • 856 (Advance Ship Notice, or ASN). Sent by you before or as the shipment leaves, telling the retailer exactly what's in the shipment — down to carton-level contents in many implementations — so their distribution center knows what to expect before it physically arrives. ASN accuracy is one of the most common sources of retail chargebacks (see Avoiding Retail Chargebacks and Vendor Compliance), because a DC that receives a shipment not matching its ASN often can't process it efficiently, or at all, without manual intervention.
  • 810 (Invoice). Your electronic invoice for the order, replacing a paper or PDF invoice, generally sent after shipment.

Some retailers also use additional transaction sets (an 846 inventory inquiry/advice, an 852 product activity report, and others), but the 850/855/856/810 set covers the core order-to-payment cycle for most vendor relationships.

Why larger retailers require it

At the volume a large chain operates, manually processing purchase orders and invoices for every vendor isn't just slower — it introduces far more opportunity for the data-entry errors, missed orders, and reconciliation problems that EDI is specifically designed to eliminate. Requiring EDI is also how a retailer enforces consistent data quality (accurate item numbers, quantities, ship dates) across every vendor into its systems, which is part of why EDI compliance itself is scored and enforced through a vendor compliance manual and scorecard rather than treated as optional infrastructure.

Integration options if you don't have in-house EDI capability

You do not need to build EDI capability from scratch, and most small and mid-sized vendors don't:

  • EDI service providers / VANs (value-added networks). A third-party service sits between you and the retailer, handling the actual EDI transmission and translation, often with a web interface or a connector into your existing order/inventory system. This is a common, practical option for a vendor with real order volume who wants the process largely automated without building in-house EDI expertise.
  • Ecommerce-platform or ERP EDI apps/integrations. If you already run your business on a common ecommerce or inventory platform, an EDI app or integration built for that platform can connect directly to your existing product and order data, reducing duplicate data entry considerably compared to a fully separate EDI system.
  • Manually-keyed web-EDI portals. For lower order volume, many retailers offer (or require through their chosen VAN) a web portal where you can view incoming 850 POs and manually key in your 855 acknowledgment, 856 ASN, and 810 invoice through a browser interface rather than a system-to-system integration. This has essentially no setup cost, but doesn't scale well — it becomes a genuine time cost and error risk once order volume or number of retail accounts using EDI grows.

The right choice generally depends on order volume and how many retail accounts you're managing this way: a single account with occasional orders may be fine on a manual web portal, while several EDI-required accounts with regular reorders usually justify the cost of a service provider or platform integration.

What happens operationally when a PO comes in

A typical cycle, once EDI is set up:

  1. The 850 PO arrives in your system or portal, specifying items, quantities, requested ship dates, and ship-to location(s) (often a specific distribution center, per the retailer's routing guide).
  2. You review and send the 855 acknowledgment, confirming you can fulfill as ordered or flagging any changes (a quantity you can't fully meet, a different available ship date) — do this within whatever window the retailer specifies, since a late or missing acknowledgment is itself a compliance issue in many vendor agreements.
  3. You pick, pack, and label the order to the retailer's specific carton-labeling and packing requirements (covered in the retailer's vendor compliance manual — see Avoiding Retail Chargebacks and Vendor Compliance), since labeling and packing-slip discrepancies are among the most common chargeback categories.
  4. You send the 856 ASN before or as the shipment departs, matching exactly what's actually in the shipment at the carton level — an ASN that doesn't match the physical shipment is a frequent, avoidable source of DC processing delays and chargebacks.
  5. You ship within the required delivery window to the correct distribution center, per the routing guide, ideally with any required delivery appointment scheduled in advance.
  6. You send the 810 invoice, and payment follows per the agreed terms (often net 30-60, sometimes longer) once the retailer's systems reconcile the PO, ASN, and invoice against what was actually received.

Every step in this sequence is also a point where a mismatch (wrong quantity acknowledged, ASN not matching the shipment, late delivery) can trigger a chargeback — which is why EDI accuracy and vendor compliance are really the same discipline viewed from two angles, not two separate concerns.

Common mistakes

  • Treating EDI as a one-time technical setup rather than an ongoing operational discipline — a system that was configured correctly at onboarding can still produce compliance issues if the people running it day-to-day don't understand why accuracy at each step matters.
  • Sending an ASN that doesn't match the actual shipment contents, because the ASN was generated before final pick-and-pack confirmed what actually shipped, rather than after.
  • Missing the 855 acknowledgment window, treating it as a formality when many retailers score it as a real compliance metric independent of on-time delivery.
  • Choosing a manual web-EDI portal and sticking with it well past the point where order volume justifies a real integration, absorbing a growing manual workload and error risk that a service provider or platform integration would have eliminated.

Best practices

  • Match your EDI integration approach to your actual order volume and number of EDI-required accounts, and revisit that choice as volume grows rather than treating the initial setup as permanent.
  • Generate the ASN from final, confirmed pack-out data, not from the original order, so it reflects what actually shipped rather than what was originally planned.
  • Build EDI transaction deadlines (855 acknowledgment windows in particular) into your standard order-fulfillment checklist, not just delivery-date tracking.
  • Work with an EDI service provider or your platform's EDI app support team when first setting up a new retailer's specific requirements — implementation details (data mapping, specific fields required) vary by retailer even within the same transaction-set standard.

FAQ

Do we need to buy dedicated EDI software before our first EDI-required retail account? Not necessarily — for a first account with modest order volume, a manually-keyed web-EDI portal (offered directly by the retailer or their VAN) can work as a starting point with no real setup investment, moving to a service provider or platform integration once volume or number of accounts makes manual keying a genuine time cost.

What's the actual cost of setting up EDI? It varies by approach and provider — a manual web portal is typically low- or no-cost to start, while a service-provider integration or platform EDI app usually involves a setup and/or ongoing subscription cost that should be weighed against the time saved and error risk reduced at your actual order volume, rather than assumed to be prohibitively expensive before checking.

What happens if we make an EDI or ASN error on an order? Depending on the retailer and the specific error, it can range from a processing delay at the distribution center to a formal chargeback — see Avoiding Retail Chargebacks and Vendor Compliance for the common chargeback categories and how to dispute one you believe is incorrect.