A retailer sends a supplier a purchase order. The supplier confirms it, ships the goods, submits an invoice, and later receives payment details. No one prints a form. No one retypes a product number. Ideally, no one sends an email asking whether the order arrived.
That is EDI at work.
Electronic data interchange (EDI) is the machine-to-machine exchange of structured business documents. It lets companies send purchase orders, invoices, shipping notices, remittance details, inventory reports, and other documents in formats both sides' systems process automatically. EDI predates the web, and it still carries a large share of business-to-business commerce. If you sell to a large retailer, supply a manufacturer, work with a third-party logistics provider, or bill a healthcare payer, someone has already told you they require it.
This guide explains what EDI is, what an EDI document looks like, how documents move between companies, and where the real operational work begins.
Before EDI, a purchase order was usually a paper form. A buyer's system printed it. Someone mailed or faxed it. Someone at the supplier entered the same information into another system. The process was slow, expensive, and vulnerable to mistakes: a mistyped quantity, an incorrect product code, or a form that simply disappeared.
That is manageable for a company placing a few orders a week. It is not manageable for a retailer ordering from thousands of suppliers.
EDI replaced the paper form with a structured electronic message. The buyer's system creates the purchase order and translates it into an agreed EDI format. It is transmitted to the supplier, whose system validates and imports it, and acknowledgments go back automatically.
The important part is not merely that the document is digital. A PDF attached to an email is digital, and someone still has to read it and key it in. An EDI document is structured so software acts on it without manual re-entry.
Standards make this repeatable, but they do not eliminate the need for agreement. Each trading partner publishes an implementation guide describing exactly how it uses the standard. That guide, not just the underlying specification, is what an integration has to follow.
An EDI document is a text file with a strict structure. In the X12 standard used across North America, documents are made up of segments. Each segment begins with an identifier and carries a series of data elements separated by delimiters.
A simplified purchase order might contain segments like these:
BEG*00*SA*PO123456**20260616~
N1*ST*Distribution Center 12~
PO1*1*24*EA*19.95**SK*ABC-123~
PO1*2*10*EA*7.50**SK*XYZ-789~
CTT*2~
To a person this looks cryptic. To an EDI system it is precise. BEG opens the purchase order and carries the PO number and date. N1 identifies a party or location. Each PO1 describes a line item: quantity, unit of measure, price, and product identifiers. CTT gives the transaction totals so the receiver can check the document arrived whole.
The complete document is wrapped in electronic envelopes. In X12, ISA and GS headers identify the sender and receiver and carry control numbers used to detect a missing or duplicate transmission.
X12 assigns a number to each transaction set. The purchase order is the 850, its acknowledgment the 855, the advance ship notice the 856, the invoice the 810, the payment and remittance the 820, the inventory report the 846, and the functional acknowledgment that says a transmission arrived intact is the 997.
EDIFACT, the international standard used widely in Europe and in shipping, uses names instead: ORDERS for purchase orders, INVOIC for invoices, DESADV for dispatch advice. The names differ, and the model is the same. Each business document has a defined structure that both parties' systems understand.
Two retailers can both send valid X12 850 purchase orders and still use them differently. One requires a supplier SKU on every line. Another uses a UPC. One puts store numbers in a particular N1 segment. Another requires extra references, allowances, or shipping instructions.
These differences live in each trading partner's implementation guide, and that is where much of the work in EDI lives. The standard defines what is possible; the guide defines what a particular partner expects. Every incoming document then has to be mapped into the fields and structures your ERP, warehouse system, transportation system, or accounting application uses.
The document format and the transport method are separate things. X12 and EDIFACT describe the document. AS2, SFTP, FTPS, and VANs describe how the document gets from one company to another.
Confusing the two leads companies to buy a translation tool that cannot meet a partner's connectivity requirement, or a transport service that does nothing with the document after it arrives.
AS2 is the protocol major retailers, healthcare organizations, manufacturers, and supply-chain networks mandate. It sends documents over HTTPS, encrypted and digitally signed, and the receiver returns a signed receipt called a Message Disposition Notification, or MDN.
The MDN confirms the recipient received the transmitted message and verified its integrity. That proof of delivery is the reason large trading partners require AS2. Running it brings its own responsibilities: certificate exchange, certificate renewal, partner configuration, and endpoint monitoring.
With SFTP or FTPS, a trading partner provides credentials and a directory structure. One side uploads outbound files and retrieves inbound files on a schedule. The process is familiar and the transport is encrypted, but there is no built-in signed receipt the way AS2 has one. Companies need their own controls to detect late, missing, or duplicate files.
A value-added network, or VAN, is an EDI mailbox service. Instead of connecting directly to every trading partner, each company connects to the VAN, which receives, stores, and forwards documents between subscribers, usually charging by document or data volume.
VANs remain common because they simplify connectivity across large partner networks. The trade-off is cost and, often, less direct control and visibility.
Transport is one step. Once a document reaches its destination, the receiving side verifies that the file arrived through the expected channel and passed its security checks. It validates the envelope, the syntax, the required segments, the control numbers, and the partner-specific rules. It translates the X12 or EDIFACT into a format its own systems use, such as JSON, CSV, XML, or an application-specific record. It routes the data to the right ERP, warehouse, billing, claims, or transportation workflow. And it returns acknowledgments telling the sender whether the document arrived, parsed correctly, and, where appropriate, was accepted by the business.
The sending side performs the same steps in reverse.
The standard itself is rarely the hard part. The operational burden falls into four areas.
Every partner has its own implementation guide, and every internal system has its own data model. An 850 from one retailer and an 850 from another are both valid X12 and represent product identifiers, shipping locations, dates, and allowances differently. Each has to be mapped into the order structure your ERP expects.
Historically, this required a dedicated EDI translator with partner-specific maps maintained by specialists. Those maps also change. Partners revise their guides, internal systems are replaced, new fields become mandatory, and business teams add new fulfillment models. Translation is not a one-time project.
Each partner may require a different transport or configuration, and AS2 adds certificate exchange and renewal. Someone monitors endpoints, patches gateways, rotates certificates, and coordinates testing with partners. A certificate that expires unnoticed halts order flow while every other part of the integration is working.
EDI uses several layers of confirmation, and they do not mean the same thing. An AS2 MDN confirms receipt and integrity at the transport layer. An X12 997 reports whether the document was accepted or rejected at the syntax level. An 855 carries a supplier's business response to a purchase order. An 824 reports application-level errors or status.
Good monitoring follows the whole chain. It is not enough to know a file left the sender's system. Teams need to know it arrived, passed validation, entered the receiving application, and produced the expected response.
The most expensive failure is the one that produces no error. A missing order sits unnoticed until a shipment is late.
Every new partner means a new implementation guide, a new map, new identifiers and routing rules, a new certificate exchange, new test documents, new exception procedures, and new production monitoring. That is why companies with hundreds of trading partners employ dedicated EDI teams. The challenge is not sending one document. It is managing hundreds of slightly different relationships reliably.
The transaction sets a company uses depend on how it does business.
Retail and wholesale run on the order-to-cash sequence: the 850 purchase order, the 855 acknowledgment, the 856 advance ship notice, the 810 invoice, and the 820 remittance. A retailer sends an 850 to place an order. The supplier returns an 855 to confirm what it can fulfill, sends an 856 before the shipment arrives, and submits an 810 after shipping. Retailers also send the 846 for inventory feeds and the 852 for sales data.
Warehousing and fulfillment with a third-party logistics provider adds the 940 warehouse shipping order, the 945 shipping advice, and the 943 and 944 for stock moving into the warehouse. These coordinate inventory moving into, through, and out of external warehouses.
Transportation and logistics runs on the 204 load tender, the 990 response, the 214 shipment status updates, and the 210 freight invoice. Together they automate the process from offering a load through tracking and billing.
Automotive manufacturing relies on the 830 planning schedule and the 862 shipping schedule, which let suppliers plan production against frequently changing delivery requirements.
Healthcare has its own set under HIPAA's transaction rules: the 837 claim, the 835 claim payment and remittance advice, the 270 and 271 eligibility inquiry and response, and the 276 and 277 claim status inquiry and response. Healthcare EDI follows the same principle of structured system-to-system exchange, under strict regulatory and implementation requirements.
The core documents have been around for decades. The technology needed to operate them has changed considerably. A traditional EDI environment is an AS2 gateway, a separate translation product, a VAN connection, scheduled file-transfer jobs, custom scripts, a certificate-management process, monitoring tools, and several disconnected audit logs.
A modern file-orchestration platform brings those functions together. One platform receives the AS2 message, returns the MDN, parses the EDI document, transforms it into the format an internal application expects, validates it, routes it, and records each step in one audit trail. The trading partner still sees the standards-compliant endpoint it requires. Internally, there are fewer systems and scripts to operate.
Files.com is the cloud-native File Orchestration Platform: one platform that replaces the stack of legacy tools IT teams run to move files, including the AS2 gateways, the translators, and the scripts holding an EDI exchange together. It speaks every protocol, connects 50+ cloud and on-prem systems, automates every transfer, and keeps a complete audit trail.
For EDI, that means an RFC 4130 AS2 endpoint with signed MDN receipts and certificates managed in the app, TransformScript parsing X12, EDIFACT, and HL7 natively into the JSON or CSV your systems ingest, validation and routing as workflow steps, and one place to see every transmission. Receive the document through AS2 or another supported protocol, record the transmission and return the receipt, parse and validate it, transform it, route it, and keep the trail, all as configuration on the same partner folders.
The EDI software page covers the platform in depth, and the transaction-set library under it has a reference page for each of the common X12 documents, from the 850 to the 997.
Start a free Files.com trial and turn AS2 on. No credit card required, and the endpoint is live in minutes.
EDI stands for electronic data interchange: the system-to-system exchange of standardized business documents, such as purchase orders, invoices, and shipping notices, without manual re-entry.
Both let systems exchange data, and they serve different integration models. EDI exchanges complete business documents asynchronously using established standards such as X12 or EDIFACT, and it is what a large retailer or payer will mandate from a supplier. An API provides real-time, request-and-response access to functions or data in one application. Most large organizations run both.
No. EDI is the document format and the business process. AS2 is one transport protocol used to carry those documents, alongside SFTP, FTPS, and VANs. AS2 is mandated by the largest trading partners because it adds encryption, digital signatures, and a signed receipt.
The X12 850 is the purchase order. A buyer sends it to a supplier to order goods or services, with the purchase order number, dates, buyer and shipping information, and line-item quantities, prices, and product identifiers. It begins the order-to-cash sequence that the 855, 856, 810, and 820 complete.
The X12 997 is the functional acknowledgment. It tells the sender whether the receiving system processed the document at the syntax level. It does not mean the business accepted the order; that comes on another document, such as the 855 purchase order acknowledgment.
You need three functions: secure transport, translation and validation, and monitoring with acknowledgments. Historically that meant a translator, an AS2 gateway or VAN, and custom scripts. Files.com does all three as configuration on one platform, with no server to run.
B2B file transfer is the daily plumbing between you and your trading partners — ACH files to the bank, EDI batches to a customer, daily extracts to a vendor. Here is what a real B2B file transfer solution does that email and shared FTP cannot.
From financial transactions and cloud data synchronization to real-time business communications, EDT ensures that information flows securely, efficiently, and without disruption.
How financial teams automate file transfers securely — without creating new compliance or audit risk.
4,000+ organizations trust Files.com for mission-critical file operations. Start your free trial now and build your first flow in 60 seconds.
No credit card required • 7-day free trial • Live in minutes