Amazon Rejected Your Order Acknowledgement. Here's the EDI Setup They Actually Require
Amazon's EDI requirement catches suppliers off guard because it doesn't arrive as a tax law. It arrives as a vendor agreement. Miss it and you don't get a penalty notice from a tax authority you get delayed onboarding, chargebacks, and purchase orders you can't confirm.
So what does Amazon actually ask for? Below is the practical shape of the Amazon EDI requirements, and where suppliers most often get stuck.
Vendor Central vs Seller Central only one of them uses EDI
This is worth settling first, because half the confusion starts here.
If you sell to Amazon they buy your stock, they own the retail relationship you're a 1P vendor on Vendor Central. That's where EDI lives.
If you sell through Amazon as a marketplace seller, you're 3P on Seller Central, and the integration path is Amazon's SP-API rather than classic EDI documents.
The rest of this post is about the 1P vendor route.
The EDI documents Amazon requires from vendors
Amazon works in transaction sets, not spreadsheets. The exact required subset depends on your region, product category, and shipping arrangement, but the core flow looks like this.
Order and confirmation
The purchase order lands with you electronically (X12 850 in North America, ORDERS in EDIFACT territory). You then have to send back an acknowledgement (855 / ORDRSP) confirming what you can actually ship quantities, prices, availability.
That acknowledgement is where most new vendors first fail. It isn't optional courtesy. It's the document Amazon uses to plan.
Shipping and receiving
An advance ship notice (856 / DESADV) tells Amazon what's arriving, in what cartons, on which pallets, against which PO. For collect shipments, there's also a routing request and routing instruction exchange before you can ship at all.
Late or inaccurate ASNs are the single most common source of vendor chargebacks.
Invoicing and financials
Your invoice goes out as an 810 (or INVOIC), and remittance advice comes back. Mismatches between what you invoiced and what the ASN said are a standing source of deductions.
Technical acknowledgements
Functional acknowledgements (997) confirm the file was received and syntactically accepted. Not receiving one means something broke and it broke silently.
Connectivity and format requirements
Documents are only half of it. You also need a transport method Amazon accepts: typically AS2, SFTP, or a connection via a VAN. Alongside that come sender and receiver IDs, envelope qualifiers, and test versus production mailbox separation.
Get an envelope qualifier wrong and every file bounces, regardless of how good your mapping is.
The testing and certification phase
Vendors usually budget for mapping and underestimate testing. Amazon runs a structured test cycle: sample documents, validation against their spec, correction, re-test, then production enablement.
Delays here are rarely technical. They're organisational nobody internally owns the response to a failed test file.
Where it breaks for suppliers
The pattern is consistent across suppliers trading into large retailers:
Order acknowledgements sent late, or not at all
Units of measure that don't match the PO
ASNs raised after the truck has already left
Invoice values drifting from shipped quantities
Nobody watching for missing 997s
None of these are exotic failures. They're all the result of EDI sitting beside the ERP rather than inside it, with a person in the middle copying data.
Amazon EDI and e-invoicing mandates are separate obligations
This is the part that trips up European suppliers.
Your Amazon invoice flow is a commercial obligation it exists because a trading agreement says so. A national e-invoicing mandate is a legal obligation on the same invoice, and satisfying Amazon does nothing to satisfy the tax authority.
Two obligations, one invoice, two different sets of rules. If you're trading into Amazon and into markets with active or upcoming mandates, you need both which is why Peppol e-invoicing and retail EDI usually end up in the same integration project.
Getting Amazon EDI running alongside your ERP
You don't need to replace your ERP to trade with Amazon. The workable pattern is an integration layer that receives Amazon's inbound documents, converts them into whatever your finance system understands, and sends the outbound acknowledgements, ASNs, and invoices back in Amazon's required format.
That's what ERP EDI integration does Business Central, D365 F&O, SAP Business One, e-conomic, whatever you're running stays where it is. Only the document flow changes.
FAQ
Can we just use the Vendor Central portal instead of EDI? Manual portal entry works at low volume. It stops working the moment order lines and shipment counts grow, and it gives you no audit trail worth having.
Do we need a VAN? Not necessarily. Direct AS2 or SFTP is common. A VAN makes sense if you're already using one for other retail partners.
How long does onboarding take? It depends on the document set and your ERP. The mapping is usually the short part; testing and internal sign-off are the long part.
What about EU vendors is it different? Same principle, different dialect. EDIFACT rather than X12, and different regional requirements layered on top.
Does Amazon EDI cover our Peppol obligations? No. Different networks, different purposes. See the section above.
If you're working out what your Amazon EDI setup needs to look like against your existing ERP, our EDI integration team maps the document flow before anything gets built.