Definition
EDI stands for Electronic Data Interchange: the exchange of structured business documents directly between the IT systems of two trading partners. Instead of emailing a purchase order as a PDF and retyping it into an ERP, the order is transmitted as a machine-readable message in an agreed standard and posted automatically. Two standards dominate — ANSI X12, which uses numbered transactions and prevails in North America, and UN/EDIFACT, which uses named message types and prevails in Europe and internationally. Every EDI setup consists of three parts: the standard (which message format), the mapping (how the standard's fields correspond to your own ERP's fields) and the transport (how the file physically moves, for example via AS2 or SFTP). The hard part is almost never the standard — it is the mapping.
Why it matters
In an Amazon context, everything depends on which model you sell under. In the vendor model (1P), Amazon acts as the buyer and expects an EDI connection: purchase orders arrive automatically, and acknowledgements, shipping notices and invoices must go back structured and on time. Missing, late or inconsistent messages are a recurring cause of vendor chargebacks. In the seller model (3P) the merchant sells through Seller Central and there is no EDI connection — automation runs through the SP-API. A manufacturer running an ERP therefore faces an architecture decision rather than a software decision: vendor with an EDI project, seller with an API project, or a broker arrangement in which a partner acts as the seller of record and the manufacturer's ERP only has to serve one interface.
How it works
A typical Amazon vendor EDI setup covers these documents (X12 number, EDIFACT name in brackets): 850 (ORDERS) for the purchase order, 855 (ORDRSP) for the acknowledgement including rejections and quantity changes, 856 (DESADV) for the advance ship notice, 810 (INVOIC) for the invoice, 860 (ORDCHG) for order changes, 846 for inventory advice and 997 as the functional acknowledgement. In North America, collect shipments additionally involve routing request and routing instruction transactions. For transport, Amazon's preferred method is AS2; Amazon-hosted SFTP and connection through a VAN (Value Added Network) are also supported. The binding field requirements, deadlines and regional variations live in Amazon's EDI specification, which vendors receive through Vendor Central — it differs by region and category and is the only authoritative source for any concrete implementation.
Real-world examples
• A furniture manufacturer in the vendor model receives an 850 with 400 line items on Monday, acknowledges it the same day via 855 with two quantity corrections, reports the shipment via 856 with an SSCC per pallet, and invoices via 810 after receipt — without anyone typing a line. • A supplements brand selling in the seller model searches for "Amazon EDI" and finds no connection to set up: Seller Central has none, and inventory and orders run through the SP-API instead. • An automotive supplier already runs EDIFACT connections to OEM customers from its ERP and wants to reuse that logic for Amazon — the mapping is new, but the existing EDI infrastructure and in-house knowledge carry over. • A merchant searching for "AWS EDI" lands on the wrong subject entirely: AWS B2B Data Interchange is an Amazon Web Services cloud product for processing EDI with any trading partner. It has nothing to do with selling on amazon.com.
Common pitfalls
• **Confusing EDI with ERP:** the ERP is where the data lives; EDI is how it leaves the building. Neither replaces the other. • **Looking for EDI as a seller:** if you sell through Seller Central you will never get an EDI connection to Amazon. The term you want is SP-API. • **Underestimating the mapping:** the standard is documented, your own item, packaging and pricing master data usually is not. In practice this is where most of the project effort goes. • **Ignoring timing:** in the vendor model, acknowledgement and shipping-notice windows are part of the agreement. Late or missing messages are a frequent chargeback trigger. • **Stopping at the purchase order:** an EDI project does not end with the 850. Without a clean 856 carrying correct packaging units, and an 810 that reconciles against the order, you create discrepancies that someone has to resolve later by hand.
Frequently asked
What is Amazon EDI?+
Amazon EDI is the automated, standardised exchange of business documents between Amazon and its suppliers in the vendor model (1P). Amazon sends purchase orders as X12 or EDIFACT messages into the supplier's system, and the supplier returns acknowledgements, advance ship notices and invoices the same way. The goal is an order-to-cash process with no manual data entry on either side.
What is the Amazon EDI system?+
There is no single product called the Amazon EDI system. It is the set of EDI documents, transport methods and rules Amazon requires from vendors: the transactions themselves (850, 855, 856, 810 and others), the transport channel (AS2, Amazon-hosted SFTP or a VAN) and the field-level requirements and deadlines published in Amazon's EDI specification for a given account, region and category.
Which EDI documents does Amazon require?+
At minimum the 850 (purchase order), 855 (acknowledgement), 856 (advance ship notice) and 810 (invoice), with the 997 functional acknowledgement confirming receipt. Depending on region and category, the 860 (order change), 846 (inventory advice) and routing transactions may also apply. Amazon's account-specific EDI specification, provided through Vendor Central, is always the authoritative list.
Do I need EDI as an Amazon seller?+
No. EDI is the vendor model (1P) integration. If you sell through Seller Central you automate through the SP-API — there is no EDI connection to Amazon on that side. EDI only becomes relevant to a seller indirectly: when your ERP already speaks EDI to retail customers and you want to reuse that logic for the Amazon channel.
What is the difference between EDI and an API?+
EDI transmits complete business documents in a normalised format, usually batched and on a schedule — a file stream between two companies. An API exposes individual records in real time on request and is tied to one specific system. EDI is standardised across industries and therefore reusable between any two partners; an API is vendor-specific but more current and more flexible.
Is AWS EDI the same as Amazon EDI?+
No, these are two different things. AWS B2B Data Interchange is an Amazon Web Services cloud service for processing EDI messages with any trading partner. Amazon EDI means connecting to Amazon as a buyer in the vendor model. If you sell on Amazon, you need the second one, not the first.