Skip to content

James Allman / JA Technology Solutions LLC

2026-04-07

EDI 101: What Business Leaders Need to Know

A plain-language guide to Electronic Data Interchange — what it is, why it matters, and how to tell when it's not working the way it should.

What Is EDI, Exactly?

EDI stands for Electronic Data Interchange, but that name does not tell you much. In plain terms, EDI is a standardized way for companies to send business documents to each other electronically — without anyone printing, faxing, emailing, or re-keying information.

Think of it like this: when you place an order with a supplier, you send a purchase order. When they ship the goods, they send a ship notice. When it is time to pay, an invoice goes out. EDI is the system that lets all of those documents flow between your company's software and your trading partner's software automatically, in a format both sides understand.

The key word is "standardized." EDI is not just sending a PDF by email. It is a structured, machine-readable format that lets computer systems on both ends process documents without human intervention.

Why EDI Exists

If your business is small enough, manual processes work fine. Someone receives an email, types the order into your system, prints a packing slip, and mails an invoice. But the moment you are processing dozens or hundreds of transactions a day — or working with large retailers — manual processes break down fast.

EDI exists because large organizations realized decades ago that standardizing electronic document exchange would reduce errors, speed up transactions, and cut costs. Today, many retailers and distributors do not just prefer EDI — they require it. If you want to do business with Walmart, Kroger, Amazon, or most major grocery and retail chains, EDI compliance is not optional.

The Documents You'll Hear About Most

EDI uses numbered document types, which can feel intimidating at first. But the numbers just correspond to familiar business documents you already work with.

An 850 is a Purchase Order — your trading partner telling you what they want to buy. An 810 is an Invoice — you telling them what they owe. An 856 is an Advance Ship Notice (ASN) — a detailed heads-up that a shipment is on its way, including what is in each carton or pallet. An 820 is a Payment Order or Remittance Advice — confirmation that money has been sent. And a 997 is a Functional Acknowledgment — essentially a receipt that says "we got your document and it was formatted correctly."

There are hundreds of other document types, but these five make up the backbone of most trading relationships.

How EDI Works in Practice

Here is what actually happens when an EDI document moves between two companies. Your customer's system generates the order data and passes it to an EDI translator — software that converts the data into the standardized EDI format. That formatted document then travels to you through a communication channel, typically a VAN (Value Added Network) or a direct AS2 connection.

A VAN is like a postal service for EDI documents — you drop your outbound documents in one mailbox, and your trading partner picks them up from theirs. AS2 is a more direct approach — a secure, point-to-point internet connection between you and your trading partner.

Once the document arrives on your end, your own EDI translator converts it from the standard format into whatever your business system needs. The purchase order appears in your system as if someone had keyed it in manually — except no one did, and it happened in seconds.

Do You Need a VAN?

One of the most common questions in EDI — and one where the answer is often more nuanced than what you have been told — is whether your organization needs a Value Added Network.

A VAN is a third-party service that routes EDI documents between trading partners. You drop your outbound documents in a mailbox, your partner picks them up from theirs, and the VAN handles delivery, tracking, and protocol translation. Major VAN providers include SPS Commerce, TrueCommerce, OpenText, and others.

VANs made perfect sense in the 1980s and 1990s when direct internet connectivity between businesses was rare. Today, many of the problems VANs solve can be handled with direct connections — and the cost difference is significant.

AS2 (Applicability Statement 2) is a secure, encrypted, point-to-point protocol for sending EDI documents directly over the internet. No middleman, no per-document fees. SFTP is another common option — many trading partners accept EDI files via secure file transfer. Some modern partners even offer REST APIs for document exchange.

The per-document fees that VANs charge — often ranging from a few cents to over a dollar per transaction — add up quickly at volume. A company processing thousands of documents per month might be spending tens of thousands of dollars annually on VAN fees that could be partially or fully eliminated with direct connections.

That said, VANs are genuinely useful in certain situations. If your trading partners require VAN connectivity — and some large retailers do mandate it — you may not have a choice. If you have dozens or hundreds of trading partners and lack the IT staff to manage individual connections, a VAN simplifies operations. And if you are onboarding new partners frequently, VANs handle the connectivity negotiation for you.

The practical answer for most organizations is a hybrid approach: direct AS2 or SFTP connections for your highest-volume trading partners (where the cost savings are greatest), and a VAN for the long tail of smaller or less flexible partners. An independent assessment of your current EDI connectivity — separate from any VAN provider's sales pitch — can identify where you are overpaying and where direct connections make sense. Learn more about EDI services including VAN assessment.

Why EDI Looks Like Gibberish

If you have ever glanced at a raw EDI file, you probably saw something that looked like a wall of tildes, asterisks, and cryptic codes. That is the X12 standard — the dominant EDI format in North America.

An X12 document is built from segments (lines of data), each containing elements (individual fields) separated by delimiters — usually asterisks between elements and tildes between segments. The document is wrapped in a series of envelopes: an ISA/IEA envelope identifies the sender and receiver, a GS/GE envelope groups related documents, and an ST/SE envelope wraps each individual transaction.

You do not need to read raw EDI yourself — that is what translators and mapping software are for. But understanding the structure helps when someone says a document was "rejected at the ISA level" or a "segment is missing." If you want to inspect an EDI file yourself, the free EDI Parser on this site will break it down into readable, labeled segments.

EDI in Grocery, Retail, and Warehousing

EDI is everywhere in business-to-business commerce, but it is especially central in grocery retail, distribution, and warehousing — industries where high volumes, tight margins, and strict compliance requirements make manual processes untenable.

In grocery retail, a single distribution center might receive thousands of purchase orders a week from hundreds of stores. Each order needs an accurate ASN before the truck arrives. Each shipment needs an invoice that matches the PO and the ASN exactly, or the payment gets held.

These are industries where I have spent years building and maintaining EDI integrations — connecting ERP systems, warehouse management platforms, and trading partner networks.

Common EDI Problems

When EDI works, it is invisible — documents flow and business happens. When it breaks, the problems tend to fall into a few familiar categories.

Mapping errors are the most common. A map is the set of rules that tells your translator how to convert data between your system and the EDI format. If a field is mapped incorrectly, documents get rejected. Trading partners update their requirements periodically, and if your maps do not get updated to match, things start failing.

Rejected documents can pile up quickly if no one is actively monitoring the EDI system. A single rejected 997 might mean your partner never confirmed receipt of your invoice, which means payment does not process on schedule.

Perhaps the most common problem of all: institutional knowledge walks out the door. The person who built the EDI maps five years ago has moved on, and no one left on the team fully understands how the integrations work.

The Real Cost of EDI Problems

EDI issues rarely stay contained within the IT department. They ripple out into operations, finance, and customer relationships.

Chargebacks are the most visible cost. Major retailers impose financial penalties for EDI non-compliance — a missing ASN, a late invoice, an incorrectly formatted document. For a supplier doing millions in revenue with a large retailer, chargebacks can quietly erode margins by tens or hundreds of thousands of dollars a year.

Delayed payments are another direct hit. If your invoice does not match the purchase order and ASN, many systems will automatically hold payment until the discrepancy is resolved.

Then there is the hidden cost of manual intervention. When EDI breaks, someone has to step in and handle transactions by hand. That labor cost does not show up on a line item labeled "EDI problems," but it is real.

DIY, Managed Service, or Consultant?

When it comes to handling EDI, organizations generally have three options. A do-it-yourself approach means your team manages the translator, builds the maps, monitors transmissions, and handles troubleshooting. This works well if you have dedicated, knowledgeable staff.

A managed EDI service handles everything — translation, mapping, transmission, monitoring, and trading partner onboarding. You pay a monthly fee and they take care of the technical details.

A consultant fills the middle ground. You maintain ownership of your EDI infrastructure, but you bring in specialized expertise when you need it — for new trading partner setups, troubleshooting, upgrading systems, or training your team. This is often the most cost-effective approach.

Tools to Help You Understand What You're Looking At

One of the most frustrating aspects of EDI for non-technical stakeholders is the opacity of it all. That is why I built two free tools available on this site. The EDI Parser lets you paste in a raw EDI document and instantly see it broken down into labeled, readable segments. The X12 Reference is a searchable guide to X12 transaction sets, segments, and elements.

Neither tool stores or transmits your data. They are designed to make EDI less mysterious, whether you are a business leader trying to understand a compliance issue or a developer working through a mapping problem.

When to Get Help

If any of the following sound familiar, it might be time to bring in someone with deep EDI experience: you are onboarding a new trading partner and the requirements document reads like a foreign language. Your chargebacks are climbing and no one can pinpoint why. A key person who understood your EDI system has left. You are migrating to a new ERP and need to reconnect all your integrations.

I have been building, fixing, and optimizing EDI integrations for over 35 years — across grocery retail, warehousing, distribution, and manufacturing. You can learn more about my EDI integration services or get in touch directly.

Try the free EDI Parser and X12 Reference — inspect EDI files and look up segment definitions in your browser. Browse free tools →