Electronic Data Interchange, or EDI, is the automated exchange of standard business documents like purchase orders, invoices, and shipping notices between two organizations’ computer systems, in a format both sides have agreed to in advance. Instead of mailing paperwork, sending PDFs by email, or keying data from one system into another, the sending company’s software formats the document to a shared standard and the receiving company’s software reads it directly. That removes the transcription step, and with it most of the errors, delays, and staff time that paper and manual entry create. EDI runs quietly behind most modern supply chains, healthcare billing, and financial reporting.
The Three Pieces That Make EDI Work
An EDI exchange needs three things in place on both sides: translation software, a communication channel, and a connection into the internal business system. Miss any one of them and the data either never leaves, never arrives, or arrives in a form nobody can use.
The translator is the engine. It pulls data out of your internal system, whether an ERP platform, accounting software, or warehouse tool, and restructures it into the standard format your trading partner expects. On the other end, the partner’s translator does the reverse, turning the incoming EDI document back into something their software can read. A purchase order in one company’s proprietary format is meaningless to another company’s system without translation on both sides.
The communication layer moves the file. Many organizations route documents through a Value Added Network, or VAN, which works like a secure mailbox: your system drops off the translated file, the VAN holds it, and your partner’s system picks it up. Smaller businesses sending a few hundred documents a month might pay under $200; mid-size operations processing thousands can see costs from $500 to several thousand dollars per month once per-document and per-kilocharacter fees stack up. The alternative is a direct connection between the two partners using a protocol like AS2, which sends encrypted documents over the internet and bypasses the VAN.
Internal integration is where implementations most often stall. The translator has to pull data from and push data into your business applications automatically, not sit in a staging folder waiting for someone to notice. Common approaches include native connectors written for specific ERP platforms, middleware that sits between the translator and your business software, custom API-based connections, and file-based transfers through shared folders or SFTP.1IBM. EDI and ERP Integration: Best Practices, Benefits and Challenges Which one fits depends on how many trading partners you have, how often documents move, and how much your IT team can maintain.
The Standards That Let Two Systems Understand Each Other
For two computers to exchange business documents, they have to agree on exactly where every piece of data sits inside the file. EDI standards define that structure, so a price field always contains currency and a quantity field always contains a number, no matter which software generated the document. Two standards cover most of the world’s EDI traffic.
ANSI X12 in the United States
In the U.S., the X12 standard dominates. It is developed and maintained by a nonprofit, ANSI-accredited standards organization established over 40 years ago.2X12. X12 – Home Every type of business document has a three-digit transaction set code. An 850 is a purchase order. An 810 is an invoice. An 856 is a ship notice. A 997 is a functional acknowledgment. Once you’re inside an EDI team, those numbers become shorthand: “send the 856” means the advance shipping notice, and everyone knows it.
X12 publishes an updated version of the standard every January, which gives organizations a predictable schedule for upgrades.3X12. X12’s Annual Release Cycle Keeps Implementation Guides Up to Date In practice, trading partner relationships often stay on a specific version for years because upgrading means rebuilding maps and retesting with every partner.
UN/EDIFACT Internationally
Cross-border transactions, particularly in Europe and Asia, more often use UN/EDIFACT. It is a set of internationally agreed rules for the electronic interchange of structured data between independent systems, approved and published by the United Nations Economic Commission for Europe.4United Nations Economic Commission for Europe. Introducing UN/EDIFACT EDIFACT uses different syntax and segment structures than X12, so companies doing both domestic and international EDI usually maintain separate maps for each standard.
Setting Up a New Trading Partner
Before a single production document moves between two companies, both sides do detailed preparation work. The heaviest piece is data mapping: connecting fields in your internal system to the corresponding positions in the EDI standard. Your database might store a customer name in a column called “CUST_NM,” but the X12 document needs that value in a specific named element within a specific segment. Every field that matters has to be mapped. Get one wrong and the receiving system either rejects the document or, worse, processes it with bad data in a critical spot.
Each partner also needs identifiers to route documents correctly. Sender and receiver IDs go into the Interchange Control Header (the ISA segment), which acts like the address block on an envelope. These identifiers commonly use a DUNS number (qualifier code 01) or a federal tax identification number (qualifier code 30 or 32), among other identifier types.5MuleSoft Documentation. X12 – ISA Identifier Values A wrong qualifier or ID value and the receiving system won’t recognize the sender.
Partners also exchange an implementation guide that spells out their specific requirements for each transaction type: which segments are mandatory versus optional, how to format fields such as decimal places on quantities or a particular date format, and any partner-specific codes.6HUD Exchange. Electronic Data Interchange Implementation Guide These guides vary by partner, so a company doing EDI with ten retailers may end up with ten slightly different maps for the same transaction type. Government agencies publish their own implementation guides that specify the transaction sets and validation requirements data must meet before it enters their systems.7Procurement Integrated Enterprise Environment (PIEE). EDI Guide – Main Document
How the Documents Actually Travel
Once a document is translated and validated, it needs a secure path to the receiver. Several protocols do that job.
AS2 (Applicability Statement 2) is the most widely used point-to-point protocol. It sends documents over HTTP or HTTPS with S/MIME encryption and digital signatures, using X.509 certificates that partners either obtain from a shared certification authority or exchange directly by fingerprint.8IETF. RFC 4130 – MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 (AS2) AS2 removes VAN fees because data moves directly between partners, but both sides need always-on infrastructure with properly configured firewalls and certificate management.
SFTP (Secure File Transfer Protocol) is a simpler option that transfers EDI files over an encrypted SSH connection. It doesn’t have the built-in receipt mechanisms of AS2, so organizations using SFTP usually add their own tracking. AS4, a newer protocol based on web services and SOAP messaging, is gaining traction in European markets and offers built-in reliability features like message retry and receipt handling. Some organizations still use the older AS1 protocol, which sends over SMTP (email infrastructure) with the same S/MIME security layer as AS2.9GS1. EDIINT AS1 and AS2 Transport Communication Guidelines
Confirming the Document Arrived and Made Sense
EDI uses a layered system of acknowledgments to confirm that a document arrived, was readable, and made business sense. The layers matter, because knowing which one failed points you at the fix.
The 997 Functional Acknowledgment is a technical receipt. When the receiver’s system takes in a transmission, it generates a 997 confirming the file arrived and the syntax was valid.10IBM. 997 – Functional Acknowledgment It doesn’t mean anyone agreed to the business terms inside, only that the translator could parse the file. If a 997 doesn’t come back inside the agreed window, someone has to check whether the transmission failed, the partner’s system is down, or the file is sitting in a VAN mailbox.
The 999 Implementation Acknowledgment goes further. It validates the document against the specific implementation guide, catching errors at the segment and element level rather than just checking basic X12 syntax.
The 824 Application Advice reports on the business logic. After the receiving system’s application processes the document and runs its own rule checks, the 824 tells the sender whether the transaction was accepted, rejected, or accepted with changes, and can pinpoint the exact segment and element that caused a problem.11Defense Logistics Agency (DLA). 824 Application Advice Put simply, the 997 says the envelope arrived intact and the 824 says whether the letter inside made sense.
Errors split cleanly along the same lines. Syntax errors, where the file breaks the X12 or EDIFACT structure, get caught immediately by the translator and rejected. Fix the map or the data and resend. Business logic errors are harder, because a document with a valid structure but the wrong unit price, the wrong quantity, or a discontinued product number passes syntax validation and only gets caught during application processing. By then you may be dealing with chargebacks, delayed payments, or stalled shipments. In retail supply chains, chargebacks for problems like missing or late advance ship notices, label errors, and quantity discrepancies typically run 1% to 5% of the gross invoice amount and add up fast for suppliers managing hundreds of purchase orders per week.
Where EDI Is Legally Required: Healthcare
EDI is a voluntary business arrangement in most industries, negotiated between trading partners. Healthcare in the United States is the notable exception. Federal HIPAA regulations require covered entities, including health plans, healthcare providers, and clearinghouses, to use specific X12 transaction sets for standard administrative transactions.12eCFR. 45 CFR Part 162 – Administrative Requirements There’s no room to negotiate a proprietary format.
The mandated transaction sets include:
- 837: Health care claims (dental, professional, and institutional)
- 270/271: Eligibility inquiries and responses
- 276/277: Claim status inquiries and responses
- 278: Referral certification and authorization
- 835: Payment and remittance advice
- 834: Enrollment and disenrollment
Each must follow the ASC X12N implementation guides specified in the regulation.12eCFR. 45 CFR Part 162 – Administrative Requirements Beyond the format requirements, CAQH CORE operating rules add federally mandated standards for connectivity, security, and error handling on eligibility, claim status, and payment transactions. They function as a floor rather than a ceiling: organizations can exceed them but cannot fall below them.13CAQH CORE. Operating Rules Healthcare EDI also requires the 999 rather than the 997, because HIPAA compliance demands validation against the full implementation guide. Organizations moving into healthcare EDI from retail or manufacturing, where the 997 is standard, frequently stumble on that difference.
What EDI Costs to Run
Costs vary widely depending on whether you build in-house, use a managed service, or run everything through a cloud platform. Traditional on-premise setups involve licensing translation software, configuring communication channels, and building maps for each partner. Setup fees from traditional vendors typically run $500 to $5,000 per trading partner, and ongoing monthly platform costs range from several hundred to several thousand dollars depending on vendor and volume. Internal build time adds up too: two to four weeks of an integration engineer’s time can mean $8,000 to $24,000 in labor before a single production document moves.
Staffing is the piece organizations most often underestimate. Someone has to monitor transmissions, chase down rejected documents, update maps when partners change requirements, and manage certificate renewals. EDI specialists in the U.S. earn a median salary around $80,800 per year, with the middle range roughly $63,000 to $88,500 depending on experience and location.
Cloud-based EDI platforms have compressed these numbers. By dropping on-premise hardware, replacing upfront licenses with monthly subscriptions, and handling VAN connectivity and map maintenance as part of the service, they can cut total cost of ownership by 40% to 60% compared with traditional setups. You give up some customization and take on more dependence on the provider, but for organizations without a dedicated EDI team, a managed cloud service is often the only realistic way to get live with dozens of partners.
Batch Processing Versus Real-Time
Traditional EDI runs in batches. Documents accumulate through the day, the communication software connects at scheduled intervals, and everything moves at once. That works well for high-volume, compliance-heavy flows where the data doesn’t need to be instantaneous: monthly reconciliations, bulk purchase order processing, after-hours posting runs. The encrypted files move in seconds once the connection is up.
API-driven integration is changing the calculus for time-sensitive transactions. Individual documents move the moment they’re ready, while still respecting EDI validation rules. Real-time inventory updates prevent overselling across marketplace channels. Shipment event notifications reach customers before the carrier scans the package. Purchase order acknowledgments can validate addresses and line items immediately instead of letting errors pile up for overnight processing.
Most organizations end up with a hybrid. Compliance-heavy flows like the full purchase-order-to-invoice cycle stay on batch, where the validation rigor and audit trail are strongest. Real-time API connections layer on top for the handful of transactions where speed directly protects revenue, such as inventory synchronization and exception alerts. Trying to move everything to real-time creates infrastructure complexity that most mid-size operations don’t need.
Connecting EDI to the Rest of Your Business
EDI only pays off when it connects cleanly into the systems your teams actually use. A translated purchase order sitting in a folder nobody checks is worse than useless, because you think it’s been processed when it hasn’t.
The most reliable integrations use native connectors or pre-built modules designed for your specific ERP platform. Vendor-maintained integrations built around the ERP’s data structure reduce custom development and make upgrades less painful. When a native connector isn’t available, middleware platforms (often called iPaaS, or integration platform as a service) can bridge the gap by sitting between the EDI translator and your business applications, routing data and handling format transformations. Organizations with development resources can go further with API-based integration, writing custom code that calls REST or SOAP APIs on both sides. That takes more upkeep as either system’s API evolves, but it allows validation and routing logic that pre-built connectors can’t always deliver.1IBM. EDI and ERP Integration: Best Practices, Benefits and Challenges
Whichever method you use, a successful delivery should trigger downstream actions on its own: an incoming purchase order creates a sales order in the ERP, an advance ship notice updates the receiving dock’s schedule, a payment remittance closes out the matching invoice in accounts payable. When that automation holds together, the EDI system becomes invisible to most employees. Orders appear, shipments confirm, and payments post, and nobody has to retype anything.