EDI (electronic data interchange) is the computer-to-computer exchange of business documents between companies in a standard format. Purchase orders, ship notices and invoices go straight from one company's system to the other's, instead of by paper, mail or fax. The documents follow standards such as ANSI ASC X12 and UN/EDIFACT.
This guide sits beside our guides to system integration, event-driven architecture and change data capture, and it uses dead letter queues for failures. Vendor details and prices are as published in October 2026.
Which standards define EDI, and which documents do they carry?
ASC X12, chartered by the American National Standards Institute for more than 40 years, develops the X12 standards and cites "the billions of daily transactions" across industries such as finance, health care, supply chain and transportation. UN/EDIFACT is a set of internationally agreed standards, directories and guidelines that UNECE approves and publishes in the UN Trade Data Interchange Directory (UNTDID).
X12 calls a document a transaction set and numbers it. UN/EDIFACT calls it a message and codes it, as in the D.24A directory. The table pairs X12's own description of five sets with the closest D.24A message.
| X12 transaction set | How X12 describes it | UN/EDIFACT message |
|---|---|---|
| 850 Purchase Order | The placement of purchase orders for goods and services | ORDERS, purchase order |
| 855 Purchase Order Acknowledgment | A seller's acknowledgment of a buyer's purchase order | ORDRSP, purchase order response |
| 856 Ship Notice/Manifest | Lists the contents of a shipment of goods | DESADV, despatch advice |
| 810 Invoice | Billing for goods and services provided | INVOIC, invoice |
| 824 Application Advice | Reports the results of an application system's data content edits | APERAK, application error and acknowledgement |
X12's text adds limits. The 850 "should not be used to convey purchase order changes or purchase order acknowledgment information", and the 824 "should not be used in place of a transaction set designed as a specific response to another transaction set".
Which standard you use is often set by the partner. Kroger uses both the UCS and ANSI X12 standards and makes new setups in EDI version 5010. In US health care, CMS lists ASC X12 version 5010 as "the adopted standard format for transactions", except those with retail pharmacies, which use NCPDP standards (see our guide to IT in healthcare). On the EDIFACT side, EANCOM is "a GS1 subset of the UN/EDIFACT standard".
What does an EDI file look like?
An X12 file is built from three nested envelopes. An interchange (ISA to IEA) holds one or more functional groups (GS to GE), and each group holds one or more transaction sets (ST to SE), the documents. In the Medicare 270/271 companion guide, each trailer repeats its header's control number and carries a count: IEA01 counts groups, GE01 transaction sets and SE01 segments.
The invented two-line purchase order below follows the segments and codes of the Army and Air Force Exchange Service 850 guide for version 5010. Every name, identifier and number is made up, and a real partner's guide will differ. Line breaks are added for reading.
ISA*00* *00* *ZZ*BUYER02 *ZZ*SUPPLIER01 *261009*0930*^*00501*000000101*0*P*:~
GS*PO*BUYER02*SUPPLIER01*20261009*0930*101*X*005010~
ST*850*0001~
BEG*00*SA*PO-48213**20261009~
DTM*002*20261023~
DTM*010*20261020~
N1*ST*Receiving dock 4*9*1234567890001~
PO1*1*48*EA*3.25*UM*UP*614141000012~
PO1*2*120*EA*1.10*UM*UP*614141000029~
CTT*2*168~
SE*9*0001~
GE*1*101~
IEA*1*000000101~
| Segment | What it carries here |
|---|---|
| ISA, IEA | Sender (the buyer) and receiver (the supplier) qualifiers and IDs, each ID padded to 15 characters; date, time and control number 000000101, repeated in IEA02 |
| GS, GE | Group type PO, version 005010, control number 101 in GS06 and GE02; GE01 counts transaction sets |
| ST, SE | Set 850, control number 0001 in ST02 and SE02; SE01 is 9, every segment from ST to SE including both |
| BEG, DTM, N1 | An original (00) stand-alone (SA) order with the buyer's PO number in BEG03; delivery requested (002) and requested ship (010), the two dates the guide always sends; the ship-to party (ST), identified by a D-U-N-S+4 number (9) |
| PO1, CTT | Two order lines with quantity, unit, price, price basis UM and a UPC-12 (UP); control totals: 2 lines and a hash total of 168 (48 + 120) |
The sample uses * between elements, : inside a composite element and ~ after each segment. ISA11 declares the repetition separator (^ here) and ISA16 the component separator. The ISA segment is of fixed length, with sixteen fixed-length fields, so a parser can read the delimiters from fixed positions.
UN/EDIFACT uses other service segments. UNECE's syntax rules wrap the interchange in UNB to UNZ, a conditional group in UNG to UNE and each message in UNH to UNT. Level A of those rules reserves ' to end a segment, + between data elements, : between components and ? to release the next character, and a conditional UNA segment declares the characters in use when they differ. A line like this opens a D.24A ORDERS message, where ORDERS is the type, D the version, 24A the release and UN the controlling agency:
UNH+1+ORDERS:D:24A:UN'
How do EDI files get to the partner?
The standard defines the document, not the road it travels. Partners agree on a transport: AS2, SFTP, a value-added network (VAN), AS4 or an HTTP API.
| Option | What it is | What you run and pay for |
|---|---|---|
| AS2 | EDI as MIME over HTTP, signed and encrypted with S/MIME, with a receipt returned | Certificates and keys per partner, an endpoint, and message fees on managed services |
| SFTP | A file copied to a server | Accounts, keys, scheduling and the file matching you build |
| VAN | An intermediary that validates documents and routes them between partners | Network fees, which IBM lists per volume of data |
| AS4 | An OASIS web-services profile with message pulling and a built-in receipt | An AS4-capable messaging service on both sides |
| HTTP API | A request over HTTP and a response that carries a status code | An API per partner, or a translator in front of EDI |
RFC 4130 defines AS2: structured business data, including X12 and UN/EDIFACT, sent over HTTP as MIME and secured with S/MIME. The receiver answers with a Message Disposition Notification (MDN). A synchronous MDN returns on the same TCP/IP connection as the HTTP response, and an asynchronous one goes to the address in a Receipt-Delivery-Option header. A signed MDN carries the message integrity check (MIC) the receiver calculated, and AWS describes it as verification (non-repudiation) that a message was received and successfully decrypted.
A VAN sits between partners. IBM's documentation says its VAN "acts as an intermediary" that validates each document and routes it by the recipient's EDI ID and qualifier. OASIS approved the AS4 profile of ebMS 3.0 on 24 January 2013. It was developed "to bring continuity to the principles and simplicity that made AS2 successful", with message pulling and a built-in receipt added.
What does each kind of acknowledgment prove?
One document can be confirmed at three checkpoints, and each answers a different question. The AS2 receipt says the message arrived. A TA1, 997 or 999 reports whether the envelopes and syntax were acceptable. Whether the receiving application took the content is answered by a business response, such as an 824 or 855.
| Checkpoint | Document | A positive answer means | What it leaves open |
|---|---|---|---|
| Transport | AS2 MDN | The message arrived and, if signed, its integrity check matched | RFC 4130's sample receipt says there is "no guarantee" the interchange was syntactically correct or reached the EDI application |
| Interchange | TA1 | The interchange was received and its envelope could be read | Everything inside the groups |
| Syntax | 997 or 999 | Groups and sets passed syntax checks; a 999 adds relational analysis | The standard "does not cover the semantic meaning" of the information |
| Business | 824 or 855 | An 824 reports the receiving application's edit results; an 855 is the seller's acknowledgment of an order | An 824 should not replace a transaction set designed as the specific response, such as an 855 |
Kroger's advance ship notice (ASN) program for the 856 shows the layers in one flow: a 997 for each group of ASNs, an 824 with the results of Kroger's own edits, then loading into its WIN system, where edits validate UPC/EAN case codes and purchase order numbers. Kroger notes that the 824 does not report data value errors of that type. AWS B2B Data Interchange generates TA1 interchange acknowledgments and either a 999 or a 997, "but never both".
Warning
A 997 marked accepted means the syntax passed, not that the order met the partner's application requirements. Kroger's program summary says an accepted functional acknowledgment "does not mean the transaction met application requirements". Wait for the business response, or ask the partner's contact, before you close an order as accepted.
How do you connect EDI to an ERP?
An EDI integration is a translator plus your business rules. An inbound flow can be built in six steps: verify and decrypt the transport, split the interchange into transaction sets, check syntax and send the TA1 and 997, translate each set into JSON or XML, map the fields into the ERP under your business rules, then post the document and send the business response (855 or 824). Managed services can take on much of the first four: AWS B2B Data Interchange transforms EDI to and from JSON or XML, and Azure Logic Apps can split an interchange into one document per transaction set. AWS's FAQ answers "No" to custom business logic in inbound validation, so rules about items, prices and ship-to locations stay in your own code.
Mapping is where partner-specific rules live. The AAFES guide says DTM codes 002 and 010 "will always be transmitted", and Kroger's program summary says extra segments "will not necessarily be read or interpreted". Write one mapping per partner and document, and agree each field with the people who own that data in the ERP.
| EDI element | What the AAFES guide says it is | Example ERP target |
|---|---|---|
| BEG03 | The purchase order number assigned by the purchaser | Customer PO reference |
DTM01 002, DTM02 | Delivery requested, and its date | Requested delivery date |
N101 ST, N104 | The ship-to party, here a D-U-N-S+4 number | Ship-to location, by lookup |
| PO102 to PO105 | Quantity ordered, unit of measure, unit price and its basis | Quantity and unit price, checked against your price list |
PO106 UP, PO107 | A UCC-12 product ID, also known as the UPC | Item, by UPC cross-reference |
Validate in three places. The translator checks syntax, your mapping checks the guide's required segments and codes, and your integration checks business rules against the ERP: does the item exist, is the ship-to known, is the price within tolerance. A document that fails the last check belongs in a dead letter queue with its reason, not in a blind retry loop. Duplicates happen at both layers: RFC 4130 recommends detecting them by Message-Id or by business transaction identifiers. At the business layer, use the partner plus the PO number as the idempotency key, so a resent 850 does not create a second order, and store each document's ISA13, GS06 and ST02 beside it so support can trace it.
How does EDI compare with an API, and why do both stay?
They solve the same business problem differently, and a supplier may have to support both.
| Question | EDI | HTTP API |
|---|---|---|
| Who writes the contract? | A standards body, then each partner's implementation guide | The API's owner, in its own documentation |
| Shape of an exchange | Documents in interchanges, confirmed later by acknowledgment documents | One request and one response, which carries a three-digit status code |
| Repeats | Control numbers and business identifiers detect them | PUT, DELETE and safe methods are idempotent by definition; a POST needs an idempotency key you design |
The HTTP column follows RFC 9110, which describes HTTP as "stateless, application-level, request/response protocols".
In health care both are at work. CMS's events page announces an enforcement discretion for HIPAA covered entities that implement FHIR-based Prior Authorization APIs, and records a December 10, 2025 listening session on replacing the X12 278 prior authorization transaction with HL7 FHIR.
For a supplier the question is rarely EDI or API. The partner picks the channel, so build one internal order model and an adapter for each. Our guides to enterprise API development and webhooks cover the API side.
What do managed EDI services cover, and what do they cost?
AWS's B2B Data Interchange FAQ says it "only supports the ANSI X12 EDI standard", so EDIFACT is not covered, and lists X12 versions 4010, 4030, 4050, 4060, 5010 and 5010 HIPAA. Azure Logic Apps handles AS2 and X12 through an integration account whose Free tier is "for exploratory scenarios, not production scenarios".
| Service | Published price | Notes |
|---|---|---|
| AWS Transfer Family, AS2 | $0.30 per hour per protocol enabled, plus $0.01 per message for the first 100,000 a month, $0.005 for the next 900,000 and $0.001 above 1,000,000 | US East (Ohio); MDNs included; a message up to 50 MB counts once, larger ones per 50 MB chunk |
| AWS B2B Data Interchange | $8.00 per partnership per month, plus $0.01 per transformation step | US East (Ohio); per 200 KB of input; 150 MB maximum, or 5 GB for a multi-transaction file that is split |
| IBM Sterling VAN | Starting at USD 200.00 for 2,000 kilo characters a month | Asterisked on IBM's page; read its terms |
AWS's own example, for one partnership and 1,000 inbound AS2 messages of 200 KB or less a month at US East (N. Virginia) prices, totals $254: $216 for the AS2 endpoint (24 hours times 30 days at $0.30), $10 for messages, $8 for the partnership and $20 for two transformation steps on each document. The endpoint-hour fee is most of that bill, so cost per message falls as volume grows. List prices leave out mapping, partner testing, certificate renewal and on-call time.
Which EDI errors cost the most time, and how do you fix them?
In Azure's TA1 table, TA104 gives the status (A accept, E accepted with errors, R rejected or suspended) and TA105 the error code, and its 997 table reports AK502 and AK403 codes for the set and the element. A control number reused after a counter reset, a restore or a naive resend looks like a repeat, and a receiver set to block duplicates does not process that interchange.
| Symptom | Likely cause | Fix |
|---|---|---|
| 997 rejects a set with AK502 code 3 or 4 | ST02 and SE02 differ, or SE01 does not match the segment count (SE01 includes ST and SE) | Generate SE01 from the real count and copy ST02 into SE02 |
| 997 shows AK403 code 7 or 1, or a TA1 shows codes 005 to 008 | A code or ID outside the partner's list (N103, or the qualifiers and IDs in ISA05 to ISA08), or a required element left empty | Compare with the guide's code lists, confirm each ID in writing and pad IDs to the fixed width |
| TA1 code 025 | The interchange control number was reused, for example after a counter reset or a restore | Keep the counter in durable storage, send a new number for a new interchange and dedupe resends by business key |
| TA1 code 004, 026 or 027 | The segment terminator, data element separator or component separator is not the one expected | Take every separator from one setting and check what the ISA segment declares |
| ASN rejected, or late at the dock | Required data missing, case codes or quantities wrong, or the ASN sent too late | Read the 824 and receiving exceptions; Kroger's certification conditions include ASNs consistently sent at least 90 minutes before the truck arrives |
These code meanings are Azure's. A partner's own list governs what it sends.
What breaks in year two, and when is EDI the wrong tool?
After go-live, four things expire or change and need an owner:
- Certificates. AS2 depends on them, and RFC 4130 lists an expired and a revoked certificate among the cases where a certificate is invalid. Track each partner certificate's expiry, and see our SSL certificate renewal guide for the renewal mechanics.
- Keys and TLS. AWS calls generating separate encryption and signing key pairs and exchanging the public keys the most complex part of its AS2 setup, so expect that work at each rotation. AWS also says you are responsible for TLS termination, in practice a reverse proxy or load balancer in front of the endpoint.
- Connectors. Azure says that if you need tracking, the original AS2 connector "is still available, but is being deprecated", and the AS2 (v2) connector matches it except for tracking. Plan the migration and your own monitoring.
- Runtime state. Control numbers, MICs and duplicate windows are state. Azure's Premium tier lets you bring your own storage for state such as the AS2 MIC number and X12 control numbers. Back it up wherever it lives.
If no partner requires EDI and both sides can call each other's APIs, an API or webhook avoids the translator, the partner guides and the acknowledgment layers. For one partner and a handful of documents a week, compare any fixed monthly fees with the manual work they would replace, and settle a vague partner guide first.
How do you onboard your first trading partner?
Onboarding is mostly agreement work, and the buyer's process sets the order. Kroger's ASN program runs a testing phase, an evaluation phase, certification of each ship-from location, then production, with random audits for certified vendors.
- Get the guide and the test plan. Ask for each document's implementation guide, the version (Kroger makes new setups in EDI version 5010) and the test and certification steps. Check: you can name the standard, version, transport and documents in scope.
- Agree identifiers. Settle sender and receiver IDs and qualifiers, and location identifiers such as D-U-N-S+4. Kroger collects the vendor's communications ID and qualifier and its ship-from locations. Check: the partner confirms each value in writing.
- Set up the connection. For AS2 on AWS Transfer Family, generate separate key pairs for encryption and signing and exchange the public keys. Check: a test file returns a signed MDN.
- Map each document from the guide, with item and ship-to cross-references. Check: the owners of pricing, logistics and finance data sign off the mapping.
- Run test exchanges and read every acknowledgment. Check: the TA1 and 997 are accepted, the 824 or 855 arrives, and the partner confirms the content loaded.
- Certify, go live and monitor. Kroger considers certifying a ship-from location after minimum conditions that include no new 997 or 824 errors, an ASN that is 100% accurate on license plates, case codes, quantities and dates, and ASNs consistently sent at least 90 minutes before the truck arrives. It tells vendors to call the EDI coordinator if an expected 997 or 824 has not arrived within 12 hours. Alert on a missing acknowledgment, reconcile counts daily and back up control-number counters. Check: the partner gives a written go-live and a named person owns each alert.
If a customer's EDI requirement has landed on your desk, the integrations service lists EDI (X12, EDIFACT) among the tools and platforms Computese works with. Its first step is a mapping workshop with the people who own each system, followed by a written design.
