In this article, learn about:
What major retailers like Walmart, Target, and Amazon require from suppliers’ EDI functions
The five categories of compliance infrastructure that generic automation tools aren't built to provide
How to evaluate whether an EDI solution can actually support a major retail relationship
Somewhere in a Slack channel right now, a developer is making a confident claim: that their team can replace EDI with a custom integration built on n8n, a homegrown script, or a low-code iPaaS platform. They can point to working demos. The tool reads an EDI 850 and can generate an EDI 856. The logic seems sound: If the tool can handle the document formats, it can handle EDI.
But document parsing and compliance are two different problems. The first is a formatting challenge: Get the data into the right structure, move it from point A to point B. Generic automation tools handle that reasonably well. The second is something else entirely: a web of protocol requirements, certification processes, timing windows, and penalty systems that major retailers have built up over decades to protect the integrity of their supply chains. A tool that clears the first hurdle hasn'tnecessarily cleared anything that matters to Walmart, Target, or Amazon.
Related Reading: EDI for First-Time Suppliers: A Plain-English Guide to the Documents You'll Send
Why Document Parsing Isn’t the Same as EDI Compliance
The conversation about replacing EDI with modern low-code automation tools tends to center on a simple capability question: Can the tool read and generate the right transaction sets?
For many tools, the answer is yes. That's enough to make the pitch compelling, and enough to obscure what the pitch is leaving out.
In EDI, the X12 transaction sets are just the surface layer. Underneath them is a set of requirements that have nothing to do with whether your tool can parse a file, such as:
Which communication protocols are mandated, and how they have to be configured.
What testing and certification a supplier must complete before they're allowed to go live.
How quickly acknowledgments have to be returned and what happens when they're late.
How non-compliance gets detected, logged, and converted into a financial penalty.
Document parsing is a formatting challenge. Trading with a major retailer is a protocol, certification, timing, and penalty-management challenge. The document is just one component of that system.
What Major Retailers Actually Require
The specifics vary by retailer, but the pattern is consistent: Major retailers have built compliance systems that go well beyond document exchange. What follows are the requirements of three of the largest retailers in the United States — Walmart, Amazon, and Target — to demonstrate the variety of rules a brand would face trying to sell through them.
Walmart
Walmart's EDI requirements start with AS2, which is worth understanding in concrete terms. AS2 is a transport-layer protocol that requires a dedicated connection, digital certificates, and a real-time acknowledgment loop called a Message Disposition Notification (MDN). When Walmart sends a document, it expects a confirmation that the message was received and decrypted successfully.
Beyond the protocol, Walmart requires suppliers to complete a formal testing and certification process before going live. That means working through a defined sequence of test transactions, demonstrating that your system handles them correctly, and getting sign-off. There is no skipping this step and cleaning things up later.
Once live, the responsiveness expectations are tight. POs, ASNs, and invoices all operate on near-real-time windows. Walmart's systems are monitoring whether documents arrive and whether acknowledgments come back on schedule. When they don't, the compliance machinery starts moving.
Target
Target's approach is more direct at the start. Where some retailers allow a ramp-up period for new suppliers to work out integration issues, Target expects full compliance from day one. There is no grace period and no informal runway to get things right.
Target's Perfect Order Program tracks order accuracy across a range of fulfillment metrics, and ASN accuracy is one of the most consequential. When an ASN contains errors (wrong carton counts, missing label data, timing violations), Target issues fines on a per-carton basis. For suppliers moving meaningful volume, those fines accumulate quickly.
Amazon
Amazon's EDI compliance model is built around speed and acknowledgment integrity. Every EDI transaction Amazon sends requires a functional acknowledgment (EDI 997) returned within a strict timeframe. This isn't a courtesy; Amazon tracks FA compliance actively, and failure to return acknowledgments on time is treated as a compliance failure in its own right, separate from whatever the underlying transaction contained.
Many generic automation tools operate asynchronously: They process transactions in queues, on schedules, or in batches. That design works fine for a lot of integration problems. It does not work well for an environment where acknowledgment timing is monitored and deviations have consequences. The window Amazon expects is short enough that any meaningful processing delay becomes a liability.
What Generic Automation Tools Don’t Reliably Solve
EDI compliance at major retailers often requires capabilities that fall outside what low-code tools were designed for. These are five structural gaps: categories of requirements that don't map cleanly onto automation logic, regardless of how the tool is configured.
Protocol Compliance
AS2 requires dedicated infrastructure: digital certificates that have to be provisioned and maintained, a persistent connection that has to be managed, and a synchronous acknowledgment loop that has to respond in real time. Generic automation tools are built around moving data between systems, not around managing the protocol layer that governs how that data is transmitted and verified. Configuring an n8n workflow or an iPaaS connector to approximate AS2 behavior is not the same ashaving AS2 infrastructure.
Certification and Testing Management
Before a supplier can go live with a major retailer, they typically have to complete a formal testing cycle. This process exists outside the tool. Generic automation platforms have no mechanism for managing it, tracking it, or helping a supplier navigate what the retailer actually needs to see before they'll approve the connection. A team using a custom integration still has to run that certification process, but they just have to do it without any infrastructure built around it.
Spec Update Tracking
Retailer EDI specifications change. New transaction requirements get added, field definitions get updated, validation rules shift. When that happens, any integration built against the old spec is now out of compliance.
Dedicated EDI providers track these updates as a core function of the service. Generic automation tools don't. The responsibility falls on whoever built and maintains the integration, which means someone on the supplier's team has to be monitoringretailer communications, identifying relevant changes, updating mappings, and testing against the new spec before the deadline.
Real-Time Acknowledgment Handling
EDI documents such as a Functional Acknowledgement (EDI 997) or a Purchase Order Acknowledgment (EDI 855) are timed responses inside a monitored loop. Retailers track whether acknowledgments arrive and how quickly. When they don't arrive on time, that can trigger a non-compliance alert.
Many generic automation tools process transactions asynchronously, in queues or on schedules, which introduces latency that the retailer's monitoring system doesn't account for. The tool may eventually send the acknowledgment. But "eventually" is not the same as "within the window," and the compliance record reflects the difference.
Chargeback Prevention Infrastructure
Automated penalty systems at major retailers can issue chargebacks within days of a compliance failure, sometimes before anyone on the supplier side has visibility into what happened. Preventing chargebacks requires more than correct document generation; it requires monitoring that surfaces exceptions before they become penalties, visibility into what was sent and when and whether it was acknowledged, and often proactive exception management when something looks like it's going sideways. Generic automation tools are built to move data, not built to watch for the compliance signals that precede a financial penalty and act on them.
What the Right Infrastructure Actually Looks Like
When a team is evaluating how to handle EDI for a major retail relationship, the natural starting point is capability: Can the tool read and generate the transaction sets we need?
However, this question doesn’t capture the full picture. The evaluation framework that actually maps onto what retailers require looks more like this:
Does it handle AS2 natively with acknowledgment tracking?
Does it support retailer-specific certification and testing workflows?
Does it monitor for spec changes and flag mapping breaks?
Does it close the loop on FAs with timing visibility?
Does it provide chargeback prevention logic, not just document transmission?
EDI Compliance Built for What Retailers Require
If your team is evaluating how to handle EDI for a major retail relationship, SPS Commerce offers the compliance infrastructure that major retailers expect: AS2 connectivity, testing and certification support, spec update management, and chargeback prevention built into the platform. Learn more about SPS Commerce EDI solutions.
