How to Integrate and Use Amazon EDI Effectively in 2026
Amazon EDI is a structured way for Amazon and Vendor Central suppliers to exchange order, shipment, and invoice data. A good EDI setup connects Amazon’s transaction requirements with your ERP or order system, warehouse process, mapping tools, finance team, testing process, and monitoring system.
Message rules, required fields, connection methods, and testing steps can differ by Amazon program or account. Because of this, use the latest Vendor Central documentation for your account and program as the primary source for Amazon-specific requirements.
This Amazon EDI guide explains the main work a 1P Vendor Central team needs to manage. It covers document flow, requirements, system ownership, mapping, testing, go-live steps, troubleshooting, Direct Fulfillment, and the choice between EDI and SP-API.
| Question | Quick answer |
|---|---|
| Who is this guide for? | Mainly Amazon 1P suppliers using Vendor Central. Seller Central follows a different integration process and should not be treated as the same EDI program. |
| What is the core business flow? | Purchase order received → Order acknowledged → Shipment assignment → ASN & Invoice sent, with acknowledgments and error handling around the process. |
| What makes an implementation work? | Current specifications, clean master data, correct mapping, warehouse and label alignment, proper testing, monitoring, and clear owners. |
| Where are the definitive requirements? | In the latest Vendor Central Resource Center and the integration documents available for your account or program. Public copies may become outdated. |
| What if your team does not want to manage the full setup? | Compare in-house, provider, and hybrid models. Then decide who will manage mapping, transport, testing, monitoring, and errors. |
Amazon EDI in one minute: who it is for and what it automates
Electronic Data Interchange, or EDI, is a standard way for two businesses to automatically exchange structured documents. It reduces the need to enter the same information again in different systems.
For Amazon Vendor Central teams, EDI can connect purchase orders, shipment data, and invoices with internal systems. This lets information flow through a planned system instead of being handled manually in the Vendor Central portal.
This guide is for the 1P Vendor Central model, where Amazon buys products directly from a supplier. It is not a Seller Central integration guide.
Seller Central merchants use a different marketplace integration system, including Amazon’s Selling Partner API, or SP-API. The same rules used for Vendor Central EDI should not automatically be applied to Seller Central.
Amazon Vendor Central EDI is also different from “AWS EDI.” AWS B2B Data Interchange is cloud infrastructure that can transform X12 documents and work with services such as AWS Transfer Family. You may use it as part of an EDI setup, but it is not the same as Amazon Vendor Central EDI onboarding.
If you are looking for AWS infrastructure information, see the AWS B2B Data Interchange documentation.
For a broader explanation of how EDI orders move between companies, SalesDuo’s EDI order-processing workflow explains the general process.
The rest of this guide focuses only on Amazon Vendor Central EDI.
The Amazon EDI document flow: order to acknowledgment to shipment to invoice
A good Amazon EDI setup starts with the business process, not the software.
Your team should understand what each document does, which system creates it, who owns it, and what happens if something goes wrong.
The X12 transaction-set definitions explain the general purpose of the main EDI documents.
Amazon may add its own fields, rules, timing, or packaging requirements. So, use X12 to understand what each transaction means, but use the latest Vendor Central documents for Amazon-specific rules.
Core transaction sequence
| Transaction | Direction | What starts it | Main owner | What it affects |
|---|---|---|---|---|
| 850 Purchase Order | Amazon → vendor | Amazon sends an order | Order management / vendor operations | Order intake, stock decisions, and shipping plans |
| 855 Purchase Order Acknowledgment | Vendor → Amazon | Vendor accepts, changes, backorders, or rejects PO lines | Order management / inventory owner | Tells Amazon what the supplier can fulfill |
| 856 Ship Notice/Manifest (ASN) | Vendor → Amazon | Shipment is packed and ready for shipping confirmation | Warehouse / WMS / 3PL | Receiving, carton matching, and shipment tracking |
| 810 Invoice | Vendor → Amazon | Shipped goods are ready to be billed | Finance / AR | Invoice approval, reconciliation, and payment |
Functional acknowledgments such as 997 or 999 may confirm that Amazon received an EDI file and passed basic syntax checks.
However, check the exact acknowledgment type and monitoring rules in the current Amazon specification for your program.
A technical acknowledgment does not always mean Amazon accepted the business information inside the order, shipment, or invoice.
Amazon EDI implementation control map
Think of EDI as one connected process.
A correct 856 ASN will not help if the warehouse packed the wrong quantity. Similarly, a correct invoice may still fail if the PO, shipment, and invoice use different product IDs or units of measure.
| Process | Main system | What should be checked | Main owner | Common problem |
|---|---|---|---|---|
| Receive PO | ERP / order system | PO number, vendor code, item ID, UOM, dates, quantities | Vendor operations | PO does not post, unknown item, wrong location |
| Make fulfillment decision | ERP + inventory source | Accepted, rejected, or backordered quantities match real stock | Order / inventory owner | Wrong 855 status or missing line update |
| Pick, pack, and label | WMS / 3PL | Physical cartons match system records and labels | Warehouse / 3PL | Wrong pack hierarchy or label |
| Send ASN | WMS + EDI layer | Shipment, cartons, pallets, tracking, and item quantities match what was shipped | Logistics / EDI owner | 856 rejection or receiving issue |
| Invoice | ERP / finance | PO, shipped quantity, item, price, and invoice references match | Finance / AR | Invoice rejection, mismatch, or duplicate |
| Monitor end to end | EDI platform / logs | Every expected message has a status and owner | Integration owner | Missing file, failed acknowledgement, retry loop, or stuck queue |
That is why EDI shouldn't be treated as only an IT project.
Every step needs a business owner, a system owner, and a clear process for handling errors.
Amazon EDI requirements and specifications to verify before setup
Some parts of EDI stay mostly the same, such as the basic business document flow.
Amazon-specific requirements can change based on the program, marketplace, vendor code, message version, connection method, and testing status.
Before you start mapping, separate the stable EDI process from Amazon’s current account-specific requirements.
Requirements verification matrix
| Area | Your team should confirm | Check in Amazon documentation |
|---|---|---|
| Account and program scope | Vendor codes, marketplaces, wholesale vs Direct Fulfillment | Which integration methods and transaction sets are enabled |
| Message specifications | Source and target fields for each document | Current version, required fields, valid values, and business rules |
| Product and order master data | Item IDs, UOM, case packs, prices, ship-from and ship-to data | Amazon-supported IDs and account-specific values |
| Connectivity and security | Endpoint owner, certificates, keys, credentials, network rules | Supported transport and security method |
| Warehouse and labels | Pack hierarchy, carton/pallet IDs, tracking, label generation | ASN, SSCC/barcode, carton/pallet, and label rules |
| ERP/WMS/3PL ownership | Which system controls order, inventory, shipment, and invoice data | Any Amazon fields that must come from a specific process |
| Testing | Test orders, test data, responses, and error cases | Current test cases, approval rules, and production process |
| Change control | Mapping versions, release owner, regression tests, certificate schedule | Amazon specification changes and migration dates |
Don't build your EDI setup from an old public PDF just because it has Amazon branding.
Public files can stay online even after Amazon changes the current account requirements.
For Amazon-specific rules, use the latest Vendor Central Resource Center and the integration documents available to your account.
You should also decide who owns each part before you begin setup.
For example, your ERP team may control PO logic. The warehouse may control carton information. A 3PL may print labels. Finance may control the 810 invoice. An EDI provider may manage translation and transport.
If nobody owns the handoff between these systems, the integration may pass technical testing but still fail in real operations.
For more 1P process information, see Amazon Vendor Central operations.
Choose the integration architecture
No single Amazon EDI setup works for every company.
The right structure depends on your ERP and WMS systems, internal EDI skills, transaction volume, support capacity, and how much work you want to keep in-house.
| Model | Best fit | Your team owns | Provider may own | Main question |
|---|---|---|---|---|
| In-house translator / middleware | Companies with a strong integration team and existing EDI experience | Mapping, transport, credentials, testing, monitoring, updates | Little or nothing | Can your team handle Amazon changes and problems without outside help? |
| Managed EDI provider | Companies with a smaller IT team or a need for ready-made connections | Business rules, master data, warehouse and finance process, provider management | Translation, connectivity, mappings, testing, monitoring | Does the provider give enough visibility into logs, alerts, updates, and issues? |
| Hybrid | Companies with a complex ERP/WMS/3PL setup | Main system logic and business controls | Transport, translation, selected mappings, or monitoring | Are internal and provider responsibilities clearly separated? |
In a common setup, Amazon connects to a transport and translation layer.
That layer changes the EDI document into a format your ERP, WMS, 3PL, or finance system can understand.
Monitoring should cover the entire path. It should not stop at the EDI gateway.
Step-by-step Amazon EDI setup in Vendor Central
Treat Amazon EDI setup like a proper implementation project.
Vendor Central screen names and setup steps may change, so always follow the latest integration area and Resource Center for your account.
1. Define the project scope
List everything that will be part of the setup.
This may include vendor codes, marketplaces, Amazon programs, transaction sets, ship-from locations, ERP systems, WMS or 3PL connections, and finance systems.
Decide whether the first setup covers only wholesale Vendor Central or also includes Direct Fulfillment.
Do not start by mapping every EDI message that exists.
Start with the messages your Amazon program actually uses.
2. Audit master data before mapping
Check product IDs, vendor SKUs, Amazon IDs (where needed), units of measure, case quantities, pack structure, ship-from locations, vendor codes, payment references, and any fields that must match across the PO, ASN, and invoice.
Your mapping may be technically correct, but bad source data can still create failed transactions.
Fix master-data problems before automation makes those problems move faster.
3. Confirm the transaction-set specifications
Open the latest Amazon specification for every EDI message you plan to use.
Map each Amazon field to the correct field in your system.
Also document any transformation rules, accepted values, and the person or team responsible for that field.
Pay attention to conditional fields.
A field may be optional in the general X12 standard but still required by Amazon for a certain program or shipment type.
4. Map business decisions, not only fields
An 855 is not just a converted version of an 850.
Your system needs rules to accept, change, reject, or backorder items based on what your company can actually fulfill.
The 856 ASN should come from what was actually packed and shipped, not only from what the original PO requested.
The same rule applies to the 810 invoice.
Finance should create the invoice from the actual fulfilled order and use references that match the PO and shipment.
5. Configure connectivity and security
Set up the connection method supported by your Amazon account and your system design.
Document who owns the endpoint, certificates, keys, credentials, network settings, retry rules, and the process used if the connection fails.
A successful connection test only proves that files can move.
It does not prove that the information inside those files is correct.
6. Build logging, alerts, and exception queues
Your logs should help answer four simple questions:
- Did the message leave the source system?
- Did the EDI layer translate it?
- Did Amazon receive or acknowledge it?
- Did the final system process it correctly?
Create alerts for missing messages, rejected files, repeated retries, duplicate documents, stuck queues, and failed downstream processing.
Every alert should have a clear owner.
7. Run the current Amazon test cases
Use Amazon’s latest test cases for your account.
Also create your own tests for common problems.
Test accepted, changed, rejected, and backordered order lines if your specification supports them.
Test warehouse packaging, label information, invoice matching, and 3PL handoffs.
The goal is not to pass one test order.
The goal is to prove that the full process can handle both normal orders and common errors.
8. Promote carefully and establish operating SOPs
Move to production only after all main teams approve the setup.
This includes data owners, warehouse teams, finance teams, integration teams, and operations.
During the first production period, closely compare EDI messages with the real PO, shipment, and invoice information.
If your team wants help with mapping, testing, monitoring, and managed operations, consider SalesDuo Amazon EDI automation once your internal scope is clear.
Testing and go-live checklist
A proper test plan should cover both normal transactions and failure cases.
Use this checklist before launch, along with the latest Amazon test cases from your Resource Center.
| Test | What should happen | Owner |
|---|---|---|
| Happy-path order | 850 posts correctly, 855 is created, shipment is built, and 856 and 810 complete the process | EDI + order operations |
| Rejected or changed PO line | Correct response is sent with all required line statuses | Order management |
| Item IDs and UOM | Amazon and internal systems use matching IDs, units, case quantities, and conversions | Master-data owner |
| Carton/pallet hierarchy | Physical cartons and pallets match the ASN data and labels | Warehouse / 3PL |
| Duplicate and retry behavior | Retrying does not create duplicate orders, shipments, or invoices | Engineering / integration |
| Functional acknowledgement | Required acknowledgements are received and monitored | EDI owner |
| Invoice reconciliation | Invoice references, quantities, items, and commercial information match the PO and shipment | Finance / AR |
| 3PL handoff | 3PL gets the correct order information and returns the data needed for the ASN | Logistics / 3PL owner |
| Alerting | Missing, rejected, or stuck messages create visible alerts | Integration support |
| Manual exception path | Team can safely continue or recover if automation fails | Operations lead |
| Production monitoring | First live transactions are checked from start to finish | Project owner |
Keep evidence from every test.
This can include the sample input, translated output, acknowledgment, system result, label or packing record, and final business result.
Saving this information also makes future regression testing easier after Amazon or your internal systems change.
Common Amazon EDI failures and how to diagnose them
Do not start fixing an EDI problem by immediately changing the map.
First find out which part of the process failed.
A transport issue, syntax error, mapping problem, outdated master record, warehouse issue, and invoice mismatch all need different teams and different fixes.
| Problem | Likely layer | Evidence to check | Owner | Next check |
|---|---|---|---|---|
| File never arrives | Transport / security | Transfer logs, connection status, certificates, keys, file times | Integration / network | Check endpoint, credentials, certificate, and retry queue |
| File arrives but fails syntax checks | X12 / acknowledgement | Raw EDI, translator result, 997/999 or other acknowledgement | EDI mapper | Check envelope, separators, required segments, data types, and current version |
| File is valid but business processing fails | Mapping / business rule | Translated file, Amazon error message, internal rule result | EDI + business owner | Check values, code lists, line logic, and conditional fields |
| Message has wrong quantities or product IDs | Master data | ERP item master, UOM conversions, cross-reference tables | Master-data owner | Compare PO, internal item, packed quantity, and Amazon IDs |
| ASN is accepted but receiving has problems | Warehouse / label / ASN | WMS packing records, cartons, pallets, labels, tracking, 856 | Warehouse / 3PL | Check that physical packing matches the ASN |
| Invoice fails or does not match | Finance / PO-ASN-invoice match | 850, 855, 856, 810, quantity and price data, duplicate history | Finance / AR | Compare invoice with accepted and shipped quantities |
If repeated EDI problems cause deductions or receiving issues, fix the main integration problem first.
For chargeback-specific help, see Amazon Vendor Central chargebacks.
For receiving and claim issues, see the Vendor Central shortage claims guide.
Wholesale vs Direct Fulfillment EDI
Wholesale Vendor Central and Direct Fulfillment are different Amazon programs.
Do not assume they use the same documents, fields, labels, or timing rules just because both involve Amazon purchase orders.
Amazon’s current Vendor Direct Fulfillment Workflow Guide explains an API process for receiving and acknowledging Direct Fulfillment orders, creating shipping labels, sending shipment confirmations, checking transaction status, and submitting invoices.
It also supports sandbox testing for Direct Fulfillment APIs.
This does not mean every existing EDI Direct Fulfillment setup should be replaced automatically.
The right decision depends on your current account setup, existing integration, and Amazon’s current options.
Treat Direct Fulfillment as a separate project and check its latest requirements before building or changing the integration.
EDI vs SP-API: when the technologies overlap and when they do not
EDI and SP-API are different ways to connect systems with Amazon.
The choice is not simply “old technology versus new technology.”
The right option depends on your Amazon program, account access, workflow, existing systems, and the type of support your team can manage.
Amazon’s official SP-API vendor use cases include Vendor Retail Procurement APIs for orders, shipments, invoices, and transaction status.
Amazon also has separate Direct Fulfillment APIs.
| Area | EDI | SP-API |
|---|---|---|
| Data model | Structured X12/EDI transaction sets | REST-based API resources and operations |
| Strong fit | Existing EDI systems, ERP translators, and trading-partner processes | Software-based integrations and API platforms |
| Vendor workflows | Common for wholesale Vendor Central document exchange, depending on account and program | Amazon supports retail procurement and Direct Fulfillment use cases |
| Monitoring | Transport logs, mapping status, acknowledgements, downstream posting | API responses, transaction status, and application logs |
| Change management | Mapping updates, code changes, certificates, regression tests | API updates, schema changes, authentication, rate limits, regression tests |
| Main question | Can your EDI system meet the current Amazon requirements reliably? | Does the current API support the workflow you need? |
Some businesses may use EDI for one program and SP-API for another.
For example, a company may keep its existing EDI wholesale process but use APIs for Direct Fulfillment.
Choose the setup based on the latest Amazon documentation and your real business process.
Do not assume one technology automatically replaces the other.
When to use an EDI provider or managed partner
An EDI provider can reduce the amount of technical EDI work your internal team needs to manage.
However, the provider cannot take away all business responsibility.
Your company still needs clean product information, correct inventory decisions, proper warehouse work, accurate invoices, and clear ownership of problems.
Use these points when reviewing a provider:
- Amazon mapping support: Does the provider update mappings when Amazon changes its requirements?
- Testing support: Will the provider help with Amazon testing, failure cases, and regression testing?
- ERP/WMS/3PL connectivity: Can the provider connect properly with your existing systems?
- Monitoring: Can you see files, translated data, acknowledgments, retries, errors, and message status?
- Exception handling: Who investigates a failed message, and what information will you receive?
- Change management: How do you manage mapping versions, Amazon updates, certificates, keys, and testing?
- Support model: What support hours, response times, and escalation paths are available?
- Program coverage: Does the provider support your Vendor Central programs, marketplaces, and transaction sets?
- Cost structure: Separate mapping, setup, platform, transaction, connector, support, and change-request costs.
If you are comparing outside platforms, review our guide to EDI providers for eCommerce businesses.
A simple Amazon EDI cost framework
Do not decide whether EDI is worth it based on an unsourced “average project cost.”
Build your cost estimate using real provider quotes and your own internal labor.
Year-1 EDI cost = implementation and mapping + connectivity/translator/provider fees + ERP/WMS/3PL integration work + internal project labor + testing effort + monitoring/support + change-management contingency.
Ongoing annual EDI cost = recurring platform/provider/connectivity + internal support and monitoring + regression testing + exception handling.
You can also compare this with the cost of manual work.
Estimate how many transactions your team processes each month, how many minutes each manual transaction takes, your labor cost, the number of errors, and how much time your team spends fixing those errors.
Treat any expected savings as an estimate, not a guaranteed result.
Conclusion
A good Amazon EDI implementation is more than connecting two systems.
It is a full order-to-cash process that needs current specifications, clean data, clear ownership, correct mapping, warehouse coordination, finance checks, testing, and proper monitoring.
Start by confirming your Vendor Central program and the latest Amazon requirements.
Then map the document flow, assign owners, test both normal and failure cases, and decide whether your company should manage the system internally, use a provider, or use a mix of both.
If you want help reviewing your transaction scope, ERP/WMS/3PL setup, mapping, testing, and monitoring plan, explore SalesDuo Amazon EDI automation.
You can also book your 1:1 growth call with SalesDuo.
Frequently Asked Questions about Amazon EDI
What is Amazon EDI, and who uses it?
Amazon EDI is a structured way for Amazon and a supplier’s systems to exchange business documents.
This guide is mainly for 1P suppliers using Vendor Central.
Seller Central uses a different integration model. AWS B2B Data Interchange is also different because it is infrastructure, not the Vendor Central EDI program.
Which EDI documents are most important for Amazon Vendor Central?
The common wholesale process mainly uses four X12 documents:
- 850 Purchase Order
- 855 Purchase Order Acknowledgment
- 856 Ship Notice/Manifest or ASN
- 810 Invoice
Your Amazon account may use more messages.
Always check the latest Vendor Central requirements before setting up your integration.
Where can I find Amazon’s current EDI specifications?
Use the latest Vendor Central Resource Center and the integration documents available for your account and program.
Public Amazon PDFs and third-party articles can be useful for background information, but they may be outdated.
For fields, message versions, timing, labels, transport, and testing rules, use the latest account-level Amazon documentation.
How do you test Amazon EDI before going live?
Test the full order-to-invoice process.
Also test common problems such as incorrect IDs, UOM issues, changed or rejected PO lines, duplicate messages, retries, acknowledgements, carton and pallet data, labels, invoice matching, 3PL handoffs, alerts, and manual recovery steps.
Save your test results so they can be reused later for regression testing.
What is the difference between Amazon EDI and SP-API?
EDI sends structured business documents through an EDI transport and translation system.
SP-API uses REST-based Amazon APIs.
Amazon supports vendor API use cases for retail procurement and Direct Fulfillment.
The best option depends on your Amazon program, account access, current systems, and the workflow you want to automate.
Does Direct Fulfillment use the same EDI flow as wholesale Vendor Central?
Do not assume that it does.
Direct Fulfillment has its own order, shipping-label, shipment-confirmation, payment, and transaction-status processes.
Amazon also provides separate SP-API documents for Direct Fulfillment.
Check the latest Direct Fulfillment requirements before reusing a wholesale EDI setup.
Can an EDI provider handle Amazon mapping and testing?
Yes.
Many EDI providers can manage translation, ready-made mappings, transport, testing support, monitoring, and system updates.
Before choosing one, clearly define what the provider will manage and what your ERP, WMS, 3PL, and internal teams will still need to manage.
Also check how the provider handles errors and Amazon specification changes.
How much does Amazon EDI integration cost?
The cost depends on your transaction types, vendor codes, marketplaces, ERP/WMS/3PL systems, custom mapping needs, testing, support level, and provider pricing.
Use real provider quotes and your internal labor costs to calculate first-year and ongoing costs.
Don't rely on a single general market price, because every EDI setup is different.
About the Author
Kevin Celestine is a powerhouse in eCommerce Business Operations and Customer Relationship Management, steering impressive growth across diverse categories. Outside work, Kevin fuels his passion for sports, globe-trotting adventures, and diving into the richness of new cultures.
