EDI transactions are standardized electronic documents that businesses exchange with each other automatically, replacing paper forms like purchase orders, invoices, and shipping notices. Instead of emailing a PDF or mailing a paper invoice, a company’s software sends a structured data file that the receiving company’s software can read and process without human intervention. EDI handles billions of these exchanges every year across industries like retail, healthcare, manufacturing, logistics, and banking.
How EDI Transactions Work
At its core, an EDI transaction takes information that lives in one company’s business system (like an ERP or accounting platform) and converts it into a standardized format that another company’s system can understand. Think of it like two people who speak different languages agreeing to communicate through a shared code.
The process has a few key stages. First, one company’s system generates the business data, say a purchase order with item numbers, quantities, and prices. Mapping software then translates that internal data into a standardized EDI format, following specific rules about where each piece of information goes. The formatted file gets transmitted to the trading partner, whose own mapping software translates it back into a format their internal system can read. The purchase order data flows directly into their order management system, ready to be fulfilled, with no one retyping numbers from a PDF.
Setting up this translation layer, called EDI mapping, requires both trading partners to agree on which data fields correspond to each other, how dates and currencies should be formatted, and what validation rules apply. Once configured and tested, the process runs automatically for every future transaction of that type.
Common EDI Transaction Types
Each type of business document has its own transaction set number. The most widely used ones follow a logical flow through a typical order cycle:
- EDI 850 (Purchase Order): A buyer sends this to a supplier to order goods or services, specifying items, quantities, and pricing.
- EDI 855 (Purchase Order Acknowledgement): The supplier confirms receipt of the order and indicates whether they can fulfill it as requested.
- EDI 856 (Advance Shipping Notice): The supplier sends this before a shipment arrives, detailing what’s in the shipment, how it’s packed, and when it should arrive. Retailers rely heavily on this to prepare their warehouses.
- EDI 810 (Invoice): The supplier’s billing document, requesting payment for goods or services delivered.
- EDI 820 (Payment Order/Remittance Advice): The buyer sends payment information, telling the supplier which invoices are being paid.
- EDI 846 (Inventory Inquiry/Advice): Used to share current inventory levels between partners.
- EDI 214 (Shipment Status): A transportation carrier sends updates on where a shipment is in transit.
- EDI 940 (Warehouse Shipping Order): Instructs a warehouse to ship goods on behalf of the sender.
These numbers come from the ANSI X12 standard, which is the dominant format in North America. A large retailer might exchange thousands of 850s, 856s, and 810s with its suppliers every single day.
EDI Standards and Formats
Two major standards govern how EDI files are structured. Which one you’ll encounter depends largely on where your trading partners are located.
ANSI X12 is the standard used primarily in North America. It identifies documents by number (850 for a purchase order, 810 for an invoice) and uses an asterisk (*) to separate individual data elements and a tilde (~) to mark the end of each line, called a segment. Each segment represents one piece of structured information, like an address line, a date, or an item description. X12 also includes industry-specific versions: HIPAA for healthcare, UCS for grocery and retail, and AIAG for automotive. These subsets follow the same core X12 rules but add requirements about which fields are mandatory and which codes to use for that particular industry.
UN/EDIFACT is the international standard, widely used in Europe and global trade. It uses different separators (plus signs and colons instead of asterisks and tildes) and identifies documents by name rather than number. A purchase order is called ORDERS, for instance. EDIFACT files can also include optional security features like identity verification and encryption built into the standard itself.
Both standards accomplish the same goal. They just structure the data differently, so a company trading with both domestic and international partners may need to support both formats.
How EDI Files Get Transmitted
Creating a properly formatted EDI file is only half the job. It also needs to reach the trading partner securely. Four main transmission methods handle this.
A Value-Added Network (VAN) is the traditional approach and still one of the most common. A VAN acts like a secure postal service for EDI files. Each company gets a mailbox on the network, drops off outgoing documents, and picks up incoming ones. The VAN handles routing, format validation, and delivery tracking. This simplicity makes VANs popular, though they charge per transaction or per kilocharacter of data transmitted, which adds up at high volumes.
AS2 (Applicability Statement 2) sends EDI files directly between trading partners over the internet using encryption and digital signatures. When a file is delivered successfully, the receiving system sends back an automatic receipt called a Message Disposition Notification. AS2 requires both parties to exchange digital certificates beforehand and to be online simultaneously during the transfer. Many large retailers require their suppliers to connect via AS2.
SFTP (Secure File Transfer Protocol) offers encrypted file transfers using public or private key authentication. It’s simpler to set up than AS2 because trading partners don’t need to exchange digital certificates in advance. Companies that want secure transmission without the overhead of AS2 infrastructure often choose SFTP.
Basic FTP (File Transfer Protocol) transfers files between two computers using username and password authentication, but the data travels unencrypted. It’s the least secure option and has largely fallen out of favor for EDI transactions that contain sensitive business data.
Who Needs EDI and Why
EDI isn’t something most businesses adopt voluntarily at first. Typically, a large trading partner requires it. Major retailers, automotive manufacturers, healthcare payers, and government agencies mandate that their suppliers and partners communicate via EDI. If you want to sell products to a large retail chain, for example, you’ll almost certainly need to send and receive specific EDI transaction sets as a condition of doing business.
The benefits explain why these requirements exist. Manual document processing is slow and error-prone. Someone reading a faxed purchase order and typing it into a system might transpose a digit, misread a quantity, or simply take hours to process what EDI handles in seconds. EDI eliminates those delays and errors by letting systems talk directly to each other. For companies processing hundreds or thousands of transactions daily, the efficiency gains are enormous. Orders get fulfilled faster, invoices get paid sooner, and inventory data stays current.
Getting Started With EDI
Implementing EDI involves several practical decisions. You’ll need EDI translation software (or a cloud-based EDI service) that can map your internal data to the required EDI formats and back. You’ll need to choose a transmission method, often dictated by your trading partner’s requirements. And you’ll need to go through a testing phase with each partner, running sample transactions to verify that data translates correctly before going live.
Companies generally choose between three implementation approaches. On-premise EDI software gives you full control but requires technical staff to maintain the system and manage connections with each trading partner. A cloud-based EDI service handles the translation and transmission infrastructure for you, charging monthly or per-transaction fees. A managed EDI service goes further, with a provider handling the entire process including partner onboarding, mapping, and troubleshooting.
The cost varies widely depending on transaction volume, number of trading partners, and complexity. Small businesses exchanging a few document types with one or two partners might spend a few hundred dollars per month on a cloud service. Large enterprises with hundreds of trading partners and complex integrations can spend significantly more on infrastructure and staff.
Where APIs Fit In
APIs (Application Programming Interfaces) enable real-time data sharing between systems and are increasingly common in supply chain operations. Where EDI excels at processing high-volume batches of structured documents like purchase orders and invoices, APIs are better suited for dynamic, on-demand tasks like checking live inventory levels or tracking a shipment in real time.
The industry trend is toward using both rather than choosing one over the other. EDI remains the backbone for bulk transaction processing between established trading partners, while APIs layer on top to handle the real-time visibility and flexibility that modern supply chains demand. Companies building out their data exchange capabilities today typically integrate EDI with APIs and cloud platforms rather than treating them as competing approaches.