Electronic Data Interchange (Edi)
What Is Electronic Data Interchange (EDI)?
Electronic data interchange (EDI) is the computer-to-computer exchange of structured business documents between organizations using agreed standards. In logistics, ecommerce, and international trade, it allows systems operated by buyers, suppliers, warehouses, carriers, and other trading partners to exchange information such as purchase orders, shipment notices, transport instructions, and invoices without requiring people to retype each document.
The defining feature of EDI is not simply that information is sent electronically. The information is organized into fields, segments, and messages that receiving software can interpret according to an agreed specification. An invoice attached to an email as a PDF is therefore not, by itself, an EDI invoice: a person or document-processing tool may still need to extract its contents before a business system can use them.
EDI describes a method of exchanging business information rather than one software product, network, or file format. A working arrangement depends on compatible document definitions, communication methods, identifiers, and business rules.
EDI in Logistics and Ecommerce
EDI connects activities that cross organizational boundaries. A retailer's purchasing system may generate an order, a supplier's system may confirm it, and a warehouse may receive instructions to prepare the goods. Shipment information and invoices can then move between the relevant systems as separate messages.
In ecommerce, EDI can support the business-to-business processes behind a consumer-facing storefront. For example, an online retailer may use it to order inventory from a supplier or exchange fulfillment information with a warehouse. The consumer's checkout transaction and the retailer's subsequent EDI messages are related business events, but they are not necessarily the same transaction or use the same technical interface.
In cross-border trade, EDI can carry information needed for international transport and commercial documentation. Customs administrations may also use structured electronic messages under their own specifications. However, exchanging an EDI message with a supplier or carrier does not itself constitute a customs declaration, establish regulatory compliance, or authorize the release of goods.
Common Business Documents
The following examples illustrate document functions rather than a mandatory sequence. The messages used depend on the trading relationship and the applicable implementation guide.
| Document or message | Business purpose | Logistics or ecommerce example |
|---|---|---|
| Purchase order | Communicates a buyer's order for goods or services. | A retailer orders replenishment inventory from a supplier. |
| Order response or acknowledgment | Communicates the supplier's response to an order. | A supplier confirms quantities or proposes changes, where the agreed message supports them. |
| Advance ship notice or despatch advice | Describes a shipment before it arrives. | A warehouse receives information about expected cartons, items, and quantities. |
| Transport instruction | Communicates instructions for a transport service. | A shipper sends agreed movement details to a transport partner. |
| Shipment status message | Communicates a transport event or status. | A carrier reports an event associated with a shipment. |
| Invoice | Communicates billing information. | A supplier bills a retailer for goods supplied. |
An advance ship notice, often abbreviated ASN, describes an expected shipment; it does not prove that the goods have arrived. Likewise, a shipment status message is not automatically proof of delivery. Its meaning depends on the event reported and the supporting information.
Standards, Formats, and Communication Methods
EDI standards define how business messages are structured and what their data elements mean. Two established standards families are X12 and United Nations rules for Electronic Data Interchange for Administration, Commerce and Transport, known as UN/EDIFACT. GS1 also maintains EDI standards, including EANCOM, which is based on UN/EDIFACT, and GS1 XML.
Within X12, examples include the 850 Purchase Order, 856 Ship Notice/Manifest, and 810 Invoice. UN/EDIFACT provides messages such as ORDERS for purchase orders, DESADV for despatch advice, and INVOIC for invoices. These examples have related business purposes across standards, but their structures and implementation requirements are not interchangeable.
A standard alone does not define every detail of a trading relationship. Partners must also agree on the applicable version and implementation guide, required fields, permitted codes, identifiers, and validation rules. Two organizations can support the same standards family and still need mapping work before their systems can exchange usable messages.
| Component | What it determines | Example |
|---|---|---|
| Message standard | The structure and meaning of a business message. | An X12 invoice or UN/EDIFACT despatch advice. |
| Implementation guide | How a particular message is used in a trading relationship. | Required shipment identifiers and allowed quantity units. |
| Communication method | How a message is transferred between systems. | AS2 or an agreed secure file-transfer arrangement. |
| Translation and mapping | How external message fields correspond to internal application data. | Mapping an incoming order line to an order-management record. |
AS2 is a communication specification for exchanging business data over HTTP, with mechanisms for security and receipts. It is not a purchase-order or invoice format. A value-added network, or VAN, can provide intermediary message exchange services; it is likewise distinct from the business-document standard.
How an EDI Exchange Works
- A business event creates data. A buyer approves a purchase order, for example, in an enterprise resource planning or order-management system.
- The data is mapped into a message. Translation software converts internal fields into the structure required by the agreed standard and implementation guide.
- The outgoing message is checked. Validation may check syntax, required fields, code values, and partner-specific requirements.
- The message is transmitted. It travels through the agreed communication channel to the recipient or an intermediary.
- The recipient validates and translates it. The receiving system checks the message and maps accepted information into its internal application format.
- Business processing follows. The receiving application may create an order, record an expected receipt, or route an exception for review.
- Responses are reconciled. Technical receipts, acknowledgments, and business responses help the sender determine what happened to the exchange.
These steps do not guarantee that every transaction is processed automatically. An unknown product identifier, invalid delivery location, duplicate document number, or unsupported unit of measure can require intervention even when the message is structurally valid.
Receipt, Validation, and Business Acceptance
EDI acknowledgments operate at different levels. A transport receipt can indicate that a message reached a communication endpoint. A functional or implementation acknowledgment can report results of structural checks. A business response can communicate whether an order or another request was accepted, rejected, or changed.
These signals should not be treated as equivalent. Successful transmission does not necessarily mean that an order has been accepted or that goods will be shipped. The specific meaning of an acknowledgment must be interpreted under the relevant specification and trading-partner agreement.
Illustrative Order-to-Shipment Example
A retailer may send a purchase order to an overseas supplier through EDI. The supplier's system checks product identifiers, quantities, and requested delivery information. If the trading arrangement includes an order response, the supplier can communicate its acceptance or proposed changes through a separate message.
When the goods are prepared, the supplier may issue an advance ship notice identifying the shipment and its contents. The receiving warehouse can use that information to prepare for receipt and compare expected quantities with goods actually received. The supplier may also send an invoice for processing in the retailer's finance system.
This example shows how EDI connects records across organizations. It does not imply that every party uses the same software, that each message is delivered in real time, or that the commercial documents replace transport and customs requirements. Matching purchase orders, shipment references, and invoices still requires consistent identifiers and agreed business logic.
EDI and Related Technologies
| Related concept | Relationship to EDI | Important distinction |
|---|---|---|
| Application programming interface (API) | An interface through which software exchanges requests and data. | EDI emphasizes standardized business messages; an API defines interaction with a software service. The two can coexist. |
| XML | A markup language used to structure data. | XML syntax alone does not establish an agreed business-message standard. |
| Electronic invoicing | The electronic issuance and exchange of invoices. | EDI can support electronic invoicing, but legal and technical requirements vary by jurisdiction. |
| ERP or warehouse management system | An application that creates or consumes business information. | These systems manage operations; EDI provides a way to exchange information with other organizations. |
| Shipment tracking | The reporting and interpretation of shipment events. | EDI may carry status information, but it is not itself a tracking website or a complete tracking service. |
EDI and APIs are not mutually exclusive alternatives in every architecture. An organization may use EDI messages for partner transactions and APIs to connect those transactions to internal applications. The appropriate arrangement depends on document requirements, partner capabilities, timing needs, and operational controls rather than the technology label alone.
Implementation Considerations and Limitations
EDI can reduce repeated manual data entry when systems successfully exchange and process compatible messages. It does not correct inaccurate source data, resolve commercial disagreements, or eliminate the need for exception handling. Automation depends on both technical compatibility and the quality of the business information exchanged.
Before establishing an EDI connection, trading partners should clarify the following operational points:
- Document scope: Which messages are required, and which business events trigger them?
- Identifiers: How will products, locations, parties, orders, and shipments be identified and matched?
- Message requirements: Which versions, mandatory fields, code lists, and mapping rules apply?
- Communication and security: Which connection method, authentication arrangements, and access controls are required?
- Acknowledgments: Which responses indicate delivery, validation, and business acceptance?
- Exception handling: Who investigates rejected messages, missing responses, and inconsistent data?
- Duplicate prevention: How will retransmissions be distinguished from new business transactions?
- Testing and change control: How will mappings and partner requirements be tested before changes enter production?
Operational monitoring should distinguish communication failures from data-validation failures and business exceptions. Resending a message may address a failed transfer, but it will not fix an invalid product code. Without duplicate controls, resending a successfully processed order could also create an unintended second transaction.
QA
What does EDI mean in logistics?
EDI means electronic data interchange: the structured exchange of business documents between systems. In logistics, those documents can include shipment notices, transport instructions, invoices, and shipment status messages.
Is an emailed PDF an EDI document?
Not by itself. A PDF can present a business document electronically, but EDI requires structured information that receiving systems can interpret under an agreed specification.
Is EDI the same as an API?
No. EDI concerns standardized business-document exchange, while an API defines how software interacts with another service. An integration can use both.
Does an EDI acknowledgment mean an order was accepted?
Not necessarily. Acknowledgments may confirm transmission or structural validation rather than business acceptance. The message type and trading-partner agreement determine its meaning.
Sources
- UNECE: UN/EDIFACT — Official framework for structured electronic interchange of administrative, commercial, and transport data.
- X12: Transaction Sets — Official descriptions of business transaction sets, including purchase orders, invoices, shipment notices, and acknowledgments.
- GS1: Electronic Data Interchange — Business-message standards and the relationship between GS1 EDI, EANCOM, and GS1 XML.
- RFC 4130: MIME-Based Secure Peer-to-Peer Business Data Interchange Using HTTP, Applicability Statement 2 — AS2 transport, security mechanisms, and receipt notifications.
