Amazon EDI Requirements: What Vendors Keep Getting Wrong
Most vendors pass Amazon's EDI onboarding without much drama. Testing goes fine, the connection goes live, and everyone moves on.
Then the deductions start showing up on the remittance.
The Amazon EDI requirements themselves aren't the hard part. Staying compliant transaction after transaction, across every marketplace and every ERP change, is where suppliers lose margin. Here's where it usually goes wrong.
What Amazon actually requires from an EDI vendor
The transaction sets in scope
A typical Amazon Vendor Central flow runs on a handful of documents: the purchase order, the PO acknowledgement, the advance ship notice, the invoice, and a functional acknowledgement for each one. Depending on your agreement you may also exchange inventory advice and PO change requests.
Which sets apply to you is defined in your vendor agreement and Amazon's EDI specification for your region not by a generic list. Check yours before you scope anything.
Vendor Central and Seller Central are not the same obligation
People say "Amazon EDI requirements" as if there's one rulebook. There isn't.
Vendor Central is a wholesale relationship: Amazon buys from you, and the EDI flow looks like classic retail EDI. Seller Central is a marketplace relationship where you sell direct, and the integration leans more on APIs and reports than on traditional transaction sets. Direct Fulfilment adds its own timing rules on top.
Scope the wrong model and you build the wrong integration.
Mistake 1: Treating the functional acknowledgement as optional
The acknowledgement is not paperwork. It's the only signal Amazon has that your system received and parsed the document.
Skip it, send it late, or send it without checking whether it reported errors, and you get a silent failure: Amazon thinks the PO landed, your ERP never processed it, and nobody notices until the delivery window has passed.
Mistake 2: An ASN that doesn't match the physical carton
This is where deductions concentrate.
The advance ship notice tells Amazon what's arriving, in what packaging hierarchy, with which labels. If the carton content, quantities, or pack structure in the file don't match what turns up at the fulfilment centre, receiving flags it and the cost lands on you.
The usual cause isn't the EDI setup. It's a warehouse process that packs first and generates the ASN afterwards, from data that has already drifted.
Mistake 3: Invoices that don't reconcile to the PO
Invoice disputes almost always trace back to the same few fields: unit of measure, price, quantity, and the item identifier.
If your ERP invoices in one UOM and Amazon ordered in another, or if a price change was applied in your system but not on the open PO, the invoice will not match. Validation before sending catches this. Reconciliation after the fact costs your finance team a week per period.
Mistake 4: Rekeying between Amazon and the ERP
Plenty of vendors run "EDI" with a person in the middle downloading files and typing them into the ERP.
That works at low volume. Add a second marketplace, a peak season, or a staff absence, and error rates climb exactly when you can least afford them. Automated EDI integration removes the manual hop and gives you an audit trail per document.
Mistake 5: Confusing Amazon's rules with government e-invoicing mandates
This one catches out otherwise well-run vendors.
Amazon's EDI requirements are contractual they come from your trading agreement. National e-invoicing mandates are legal, and they come from tax authorities. Both apply to the same invoice, and meeting one does not satisfy the other.
If you sell across the EU, your Amazon invoice flow may also need to clear a national mandate or route through Peppol. A certified Peppol Access Point handles the second obligation alongside the first, in the same setup.
What good looks like
Treat EDI as a validation and routing layer that sits between Amazon and your ERP not as a second system your team has to run.
That layer should map Amazon's formats to whatever your ERP speaks, validate every document against format and business rules before it leaves, and surface exceptions to a human while there's still time to fix them. Your ERP stays the source of truth. Amazon sees clean documents. Nobody rebuilds anything.
Frequently asked questions
Which transaction sets do I need for Amazon? It depends on your vendor agreement, region, and fulfilment model. Your Amazon EDI specification lists the required sets treat that document as authoritative.
Do I need EDI to sell on Amazon? Not always. Vendor Central relationships typically require it. Seller Central often runs on API-based integration instead.
What causes most Amazon EDI deductions? ASN accuracy and delivery-window compliance, in most cases followed by invoice-to-PO mismatches.
Can Amazon EDI connect to my existing ERP? Yes. Amazon EDI integration is designed to sit on top of your current ERP rather than replace it.
Does meeting Amazon's EDI requirements cover my e-invoicing mandate obligations? No. They are separate obligations on the same invoice.
Working through your Amazon EDI requirements and not sure where the gaps are? Get in touch we'll walk through your current flow with you.