Electronic data interchange (EDI): how it works and why enterprises still rely on it

• EDI is the automated, standardized exchange of business documents like purchase orders and invoices directly between computer systems, with no manual re-entry
• In North America, ANSI ASC X12 is the dominant standard; EDIFACT and XML matter mainly for international trading partners
• Direct connections and value-added networks (VANs) are the two ways EDI documents move, using protocols such as AS2 and SFTP
• HIPAA transaction sets (837, 835, 270/271) apply EDI specifically to healthcare claims and eligibility checks
• Receiving an EDI file is only step one. What happens next, mapping, matching, and posting into your ERP, is where most of the manual work still hides

Electronic data interchange (EDI) is the automated exchange of business documents, such as purchase orders, invoices, and shipping notices, between two organizations' computer systems in a standardized electronic format. It replaces paper, email, and manual data entry with a direct system-to-system transaction that requires no human intervention to send, receive, or process.

An EDI transaction moves through four stages, regardless of which standard or protocol carries it:

1. Creation. An internal system, usually an ERP like SAP, generates the source document: a purchase order, an invoice, an advance ship notice. It exists in whatever format your ERP produces natively.
2. Translation. An EDI translator converts the document into the agreed standard, most often X12 in the US. Fields such as part number, quantity, and price get mapped into the exact positions the receiving system expects.
3. Transmission. The file moves to the trading partner, either over a direct connection or through a value-added network (VAN).
4. Integration. The receiving system's own translator reads the file and posts the data into its ERP or accounting system automatically, with no manual entry on either side.

Get step 2 wrong and the transaction fails outright, which is exactly why EDI is trusted at high volumes.

For a US enterprise, the practical rule holds: default to X12 for domestic partners, expect EDIFACT from anyone trading internationally, and treat XML as the exception. Your trading partner agreements will almost always specify X12 first, since most US retailers, automotive OEMs, and healthcare payers run on it. XML trades consistency for flexibility, which is why industries with less rigid, more frequently changing document structures sometimes prefer it for custom message formats.

Two connection types carry EDI documents:

Picture a mid-size manufacturer buying components from a supplier. Here's how the transaction chain plays out:

1. 850 Purchase Order. The buyer's ERP generates the order and transmits it via AS2.
2. 855 Purchase Order Acknowledgment. The supplier's EDI translator reads the 850, confirms stock, and sends this back.
3. 856 Advance Ship Notice. Once goods ship, the supplier sends tracking details and expected delivery date, so the buyer's warehouse knows exactly what to expect before the truck arrives.
4. 810 Invoice. After delivery, the supplier transmits the invoice. On the buyer's side, it needs to match the original 850 on price, quantity, and terms before anyone approves payment.

Every step in that chain references the previous document by number, so the entire order-to-cash cycle stays traceable end to end, which matters as much for an audit as it does for day-to-day operations.

EDI concentrates in three areas of enterprise operations.

Procurement and supply chain management

EDI carries purchase orders, inventory data, and delivery scheduling between buyers and suppliers, most often through procurement and supply chain workflows:

• Large retailers built entire vendor compliance programs around it: Walmart, Target, and Amazon all require suppliers to transact via EDI
• Vendor scorecards penalize late or malformed transmissions
• Miss the AS2 requirement or send a malformed 856, and you risk a chargeback before the shipment even arrives

Invoicing and payment processing

EDI moves electronic invoices, payment remittances, and reminders, cutting the days-long float that paper invoices create.

Logistics and transport

EDI carries shipping orders, customs documentation, and transport status updates. The 856 Advance Ship Notice earns its place here as one of the most valuable single documents in the entire standard.

Healthcare EDI runs on a distinct set of X12 transactions, defined under HIPAA:

Four properties make EDI worth the setup effort at enterprise scale:

• Speed: a transaction that takes days by mail or email completes in minutes, and a delayed shipment notice arrives before the truck does
• Accuracy: standardized field structures catch formatting errors at the moment a transaction is validated, the exact point where a re-keyed value would otherwise let a typo slip into your ERP
• Cost reduction: every manual re-key eliminated is a re-key that cannot introduce an error, freeing up hours for exceptions that actually need a human decision
• Compliance: a standardized, auditable transaction trail gives you exactly what a SOX or HIPAA audit asks for, proof of who sent what, when, and how it was validated

None of this arrives automatically. Three things take real engineering effort before your first transaction goes live:

• Trading partner agreements (TPAs): you and each trading partner need a TPA that defines the exact standard, version, protocol, and business rules both sides will follow. Skip this and you'll find out the hard way when a supplier's 850 uses a segment your system does not expect
• Mapping: your internal document formats rarely line up field for field with X12 or EDIFACT, so a mapping layer has to translate between them, and that layer needs updating every time a trading partner changes their specification
• Batch enveloping and de-enveloping: high-volume trading partners bundle multiple transactions into a single envelope for efficient transmission, then unpack and route each one to the right internal destination on arrival. Get the routing logic wrong and a valid transaction lands in the wrong queue, invisible until someone goes looking for it

Budget real implementation time for all three. None of them is a plug-and-play checkbox.

EDI and APIs both move business data between systems, but they solve different problems.

If you exchange thousands of purchase orders a month with the same set of retail or automotive partners, EDI is still the right tool: the standard is fixed, the cost per transaction is close to zero, and every partner already speaks it. If you need to sync inventory levels with a marketplace in real time, an API fits better. Most large enterprises run both side by side: EDI for the high-volume trading partner backbone, APIs for the integrations that need to be fast and flexible.

Getting an EDI file to arrive is the easy half of the problem. What happens after it lands in your inbox, or your mailbox on the VAN, decides whether that transaction actually saves anyone time.

Invoices

Doxis Invoice for SAP receives EDI invoices as a first-class document type alongside PDF, TIFF, and XML. Rather than relying on a fixed EDIFACT or X12 parser, it maps each trading partner's specific format to the right invoice fields, then transfers the converted data, along with a record of the original EDI format, straight into SAP.

• The file is read and its fields mapped to the exact structure your accounts payable process expects
• The result is handed to SAP for posting, without anyone re-typing a single line
• If a mapping needs a second look, it can be triggered again manually from the Doxis Invoice for SAP Center, so a partner's format change never becomes a dead end

Order confirmations

Order confirmations work differently: they get checked against an existing SAP purchase order before anything posts.

Doxis Order Confirmation for SAP accepts confirmations through several channels, including EDI, and automatically compares each one against the original purchase order on price, quantity, and delivery date.

Confirmations within tolerance post automatically; anything outside tolerance gets flagged for a person to review before it writes back to the SAP purchase order.

If your team is still manually reconciling EDI invoices or order confirmations against SAP, the bottleneck is not EDI itself. It is the missing layer between the EDI transmission and the posting screen. Doxis Invoice for SAP and Doxis Order Confirmation for SAP close that gap, receiving EDI alongside every other inbound format, mapping it automatically, and posting it directly into SAP ERP or S/4HANA with a full audit trail.

Both modules run on Doxis's broader Intelligent Content Automation platform, which handles the rest of the document lifecycle around your EDI transactions too: compliant archiving, contract management for the trading partner agreements that govern your EDI relationships, and records retention that keeps every posted transaction audit-ready long after it clears SAP.

• Receives EDI as a first-class format alongside PDF, XML, and scanned documents, with no separate system to maintain
• Maps customer-specific EDI formats automatically, with manual remapping available when a partner's specification changes
• Matches order confirmations against SAP purchase orders on price, quantity, and delivery date, flagging discrepancies before they cause a problem
• Posts approved invoices and confirmations directly into SAP ERP or S/4HANA, no manual re-entry
• Extends beyond EDI to your full document lifecycle: archiving, contract management, and retention on one platform
• Fully GDPR and ISO 27001 compliant, built for enterprise-scale trading partner volumes

Doxis is recognized as a Leader in the Gartner® Magic Quadrant™ for Document Management 2026. Request a free demo to see how your own EDI transactions would flow through it.

FAQs for electronic data interchange (EDI)