EDI & Data Exchange in Logistics
Modern logistics depends on the rapid, accurate exchange of structured data between trading partners — shippers, carriers, freight forwarders, customs authorities, warehouses, and financial institutions. Electronic Data Interchange (EDI) is the foundational technology that makes this possible, replacing paper documents and manual data entry with standardized electronic messages transmitted between computer systems.
Understanding EDI is essential for anyone working in freight forwarding, carrier operations, or supply chain management. Even as newer technologies like REST APIs gain traction, EDI remains the dominant method for business-to-business data exchange in transportation and logistics worldwide.
What Is EDI?
Electronic Data Interchange (EDI) is the computer-to-computer exchange of business documents in a standardized electronic format. Unlike email or PDF attachments — which still require human interpretation — EDI messages are structured so that the receiving system can automatically parse, validate, and process them without manual intervention.
EDI replaces paper-based documents (purchase orders, invoices, bills of lading, shipping notices) with standardized electronic messages that flow directly between trading partners' systems, enabling straight-through processing with no human re-keying.
Core Characteristics of EDI
| Characteristic | Description |
|---|---|
| Structured format | Messages follow rigid, predefined schemas — every field has a specific position, length, and meaning |
| Computer-to-computer | Designed for system-to-system processing, not human reading |
| Standardized | Governed by international standards (X12, EDIFACT) so any compliant system can interpret the data |
| Batch-oriented | Traditionally sent in batches on a schedule (e.g., every 15 minutes, hourly, or daily) |
| Document-centric | Each message type corresponds to a traditional paper document (invoice, bill of lading, etc.) |
How EDI Works
A typical EDI exchange involves several components:
- Business system (TMS, WMS, ERP) generates the data — a shipment tender, invoice, or status update.
- EDI translator converts the internal data into the appropriate EDI standard format (X12 or EDIFACT).
- Communication layer transmits the formatted message via a Value-Added Network (VAN), AS2 (Applicability Statement 2), SFTP, or other protocol.
- Receiving translator parses the incoming EDI message and maps it into the receiver's business system.
- Acknowledgment — the receiver sends back a functional acknowledgment (e.g., X12 997) confirming receipt and syntactic validity.
The Two Major EDI Standards
Two standards dominate logistics EDI worldwide: ANSI X12 (primarily North America) and UN/EDIFACT (primarily international and European trade).
ANSI X12
ANSI X12 was developed by the Accredited Standards Committee X12, chartered by the American National Standards Institute (ANSI). It is the dominant EDI standard in North America, used extensively in transportation, retail, healthcare, and government.
Each document type is identified by a three-digit transaction set number. A group of related transaction sets is called a functional group, and one or more functional groups are wrapped in an interchange envelope for transmission.
X12 message structure:
ISA (Interchange Control Header)
GS (Functional Group Header)
ST (Transaction Set Header)
... segments (data content) ...
SE (Transaction Set Trailer)
GE (Functional Group Trailer)
IEA (Interchange Control Trailer)
UN/EDIFACT
UN/EDIFACT (United Nations Electronic Data Interchange for Administration, Commerce and Transport) is the international standard maintained by the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT). It is widely used in international shipping, air freight, customs, and European logistics.
EDIFACT messages are identified by six-character codes (e.g., IFTMIN, CUSCAR, INVOIC). The structure uses a similar envelope approach:
EDIFACT message structure:
UNB (Interchange Header)
UNH (Message Header)
... segments (data content) ...
UNT (Message Trailer)
UNZ (Interchange Trailer)
X12 vs. EDIFACT Comparison
| Feature | ANSI X12 | UN/EDIFACT |
|---|---|---|
| Origin | United States (ANSI) | United Nations (UN/CEFACT) |
| Primary region | North America | International, Europe, Asia |
| Document identifier | Three-digit number (e.g., 204, 856) | Six-character code (e.g., IFTMIN, DESADV) |
| Delimiter style | Configurable (typically * segment, ~ terminator) | Fixed (+ data, : component, ' segment) |
| Industry focus | Transportation, retail, healthcare, government | International trade, shipping, customs, automotive |
| Governance | ASC X12 committee | UN/CEFACT working groups |
| Versions | Release numbers (e.g., 004010, 005010) | Directory versions (e.g., D.96A, D.01B) |
Many global freight forwarders and carriers must support both standards — X12 for North American domestic operations and EDIFACT for international and cross-border trade. EDI translation platforms typically handle mapping between the two.
Key EDI Transaction Sets in Logistics
ANSI X12 — Transportation Transaction Sets
The 004010 and 005010 releases are the most widely used versions in North American transportation.
| Transaction Set | Name | Purpose | Sent By → To |
|---|---|---|---|
| 204 | Motor Carrier Load Tender | Offer a shipment to a carrier with pickup/delivery details, equipment needs, and rates | Shipper/Broker → Carrier |
| 210 | Motor Carrier Freight Details and Invoice | Carrier's freight bill for services rendered | Carrier → Shipper/Broker |
| 211 | Motor Carrier Bill of Lading | Electronic bill of lading for motor freight | Shipper → Carrier |
| 214 | Transportation Carrier Shipment Status | Real-time shipment tracking updates (pickup, in-transit, delivered) | Carrier → Shipper/Broker |
| 301 | Ocean Booking Confirmation | Confirm an ocean freight booking | Carrier → Forwarder/Shipper |
| 310 | Freight Receipt and Invoice (Ocean) | Ocean carrier freight invoice | Ocean Carrier → Forwarder |
| 315 | Status Details (Ocean) | Ocean container and vessel status updates | Ocean Carrier → Forwarder |
| 322 | Terminal Operations and Intermodal Ramp Activity | Container availability and terminal gate activity | Terminal → Carrier/Forwarder |
| 404 | Rail Carrier Shipment Information | Shipment details for rail transport | Shipper → Railroad |
| 417 | Rail Carrier Waybill Interchange | Rail waybill for interline settlements | Railroad → Railroad |
| 810 | Invoice | General-purpose commercial invoice | Seller → Buyer |
| 850 | Purchase Order | Buyer places an order with a supplier | Buyer → Seller |
| 856 | Advance Ship Notice (ASN) | Detailed shipment contents notification before delivery | Shipper → Receiver/Warehouse |
| 990 | Response to a Load Tender | Accept or reject a 204 load tender | Carrier → Shipper/Broker |
| 997 | Functional Acknowledgment | Confirm receipt and syntactic validity of any transaction set | Receiver → Sender |
The 204 → 990 → 214 → 210 Cycle
The most common EDI workflow in trucking follows a four-step cycle:
- 204 Load Tender — the shipper or broker electronically offers a load to a carrier with all shipment details.
- 990 Response — the carrier accepts or declines the tender. If declined, the shipper tenders to the next carrier.
- 214 Status Updates — the carrier sends status milestones as the shipment progresses (picked up, departed, arrived, delivered).
- 210 Invoice — after delivery, the carrier submits the freight invoice electronically for payment.
UN/EDIFACT — Logistics Messages
| Message Code | Name | Purpose | Common Use |
|---|---|---|---|
| IFTMIN | Instruction Message | Shipping instructions from shipper to forwarder/carrier | Booking and shipment instructions |
| IFTMBF | Firm Booking Message | Request or confirm a firm booking | Ocean/air freight booking |
| IFTMBC | Booking Confirmation | Carrier confirms a booking request | Response to IFTMBF |
| IFTSTA | Multimodal Status Report | Shipment tracking and status updates across modes | Milestone tracking |
| IFTMAN | Arrival Notice | Notify consignee of cargo arrival | Import cargo notification |
| CUSCAR | Customs Cargo Report | Report cargo details to customs authorities | Pre-arrival manifest filing |
| CUSDEC | Customs Declaration | Submit import/export customs declaration | Customs clearance |
| CUSRES | Customs Response | Customs authority response to a declaration | Clearance status |
| INVOIC | Invoice | Commercial or freight invoice | Billing |
| DESADV | Despatch Advice | Notification of goods shipped (equivalent to ASN) | Warehouse receiving |
| COPARN | Container Pre-Announcement | Announce container pickup or return to terminal | Terminal gate planning |
| BAPLIE | Bayplan/Stowage Plan | Container positions on a vessel | Vessel loading/planning |
EDIFACT customs messages (CUSCAR, CUSDEC, CUSRES) are covered in detail in the Import/Export Documentation article. The Documentation Flow article explains how these messages fit into the end-to-end forwarding process.
Communication Protocols
EDI messages must be transmitted between trading partners using a communication protocol. Several methods are in common use:
| Protocol | Description | Characteristics |
|---|---|---|
| VAN (Value-Added Network) | Third-party intermediary that routes EDI messages between partners | Managed service, store-and-forward, built-in compliance tracking; higher cost |
| AS2 (Applicability Statement 2) | Point-to-point HTTPS-based protocol with digital certificates and encryption | Direct connection, real-time, receipt confirmation (MDN); lower per-message cost |
| SFTP (Secure File Transfer Protocol) | Encrypted file transfer over SSH | Simple setup, batch file transfer; no built-in acknowledgment mechanism |
| AS4 | Web services-based messaging protocol (successor to AS2) | Modern, supports cloud architectures, push/pull models |
| OFTP2 (Odette File Transfer Protocol) | Protocol used primarily in European automotive supply chains | Specifically designed for large file transfers with restart capability |
Value-Added Networks (VANs) have historically been the most common method. Major logistics VANs include OpenText (GXS), SPS Commerce, Cleo, and TrueCommerce. The VAN acts as a mailbox service — the sender deposits the EDI message, and the VAN routes it to the correct recipient's mailbox for retrieval.
AS2 has grown significantly as companies seek to reduce VAN transaction fees. It provides point-to-point encrypted communication with Message Disposition Notifications (MDNs) that confirm delivery — a feature that VANs provide but basic SFTP does not.
EDI vs. API: Complementary Technologies
The logistics industry increasingly uses Application Programming Interfaces (APIs) — particularly RESTful web services — alongside traditional EDI. Understanding the differences helps organizations choose the right approach for each integration need.
| Dimension | EDI | API (REST) |
|---|---|---|
| Data format | Fixed-position or delimited (X12, EDIFACT) | JSON or XML |
| Communication | Batch, store-and-forward | Real-time, request-response |
| Connection model | Point-to-point or via VAN | Client-server over HTTPS |
| Setup complexity | High (mapping, testing, VAN enrollment) | Moderate (API keys, endpoint configuration) |
| Speed | Minutes to hours (batch schedules) | Milliseconds to seconds |
| Error handling | Functional acknowledgments (997) | HTTP status codes, immediate error response |
| Ideal for | High-volume, recurring B2B transactions | Real-time queries, tracking, rate shopping |
| Industry adoption | Deeply embedded, especially large enterprises | Growing rapidly, especially mid-market and startups |
| Standards governance | ASC X12, UN/CEFACT | Varies by provider; some industry standards (DCSA, IATA ONE Record) |
APIs are not replacing EDI. The two technologies serve different purposes and often coexist. Large carriers and retailers have decades of EDI investment and will continue requiring EDI from trading partners. APIs excel at real-time interactions where EDI's batch model falls short.
When to Use Each
Use EDI when:
- Trading partners require it (most large carriers, retailers, and 3PLs)
- Exchanging high volumes of the same document types repeatedly
- Working with established transaction sets (load tenders, invoices, ASNs)
- Regulatory compliance mandates structured data formats (customs filings)
Use APIs when:
- Real-time data is needed (live tracking, instant rate quotes)
- Integrating with modern platforms and SaaS applications
- Building custom workflows that don't map to standard EDI transaction sets
- Lower transaction volumes where VAN costs are disproportionate
The Hybrid Approach
Most modern logistics operations use a hybrid model: EDI for core transactional flows (tendering, invoicing, customs) and APIs for real-time visibility, rate shopping, and ad-hoc queries.
Emerging API standards in logistics:
| Standard | Organization | Scope |
|---|---|---|
| DCSA standards | Digital Container Shipping Association | Ocean container tracking, electronic B/L, event standards |
| ONE Record | IATA | Air cargo data sharing via linked data and REST APIs |
| EPCIS 2.0 | GS1 | Supply chain visibility events (what, where, when, why) |
| OpenFreight | Linux Foundation | Open-source freight data exchange |
EDI Implementation Considerations
Mapping and Translation
Every EDI integration requires mapping — defining how fields in one system correspond to segments and elements in the EDI standard. This is one of the most time-consuming aspects of EDI implementation.
Example: Mapping a Load Tender (204)
| EDI 204 Segment | Element | Maps To (TMS Field) |
|---|---|---|
| B2 | Standard Carrier Alpha Code (SCAC) | Carrier ID |
| B2 | Shipment Identification Number | Load/Order Number |
| S5 (Stop-Off, Type "CL") | Address segments | Pickup Location |
| S5 (Stop-Off, Type "CU") | Address segments | Delivery Location |
| L5 | Commodity Description | Commodity |
| L0 | Weight | Total Weight |
| L0 | Volume | Total Volume |
| G62 | Date/Time | Pickup/Delivery Windows |
Testing and Certification
Before going live with a trading partner, EDI connections go through a structured testing process:
- Internal testing — validate that the EDI translator correctly generates and parses messages.
- Connectivity testing — confirm that messages transmit successfully between systems (VAN mailbox, AS2 endpoint, or SFTP directory).
- Compliance testing — verify that messages meet the trading partner's specific implementation guide, which may require or restrict certain optional fields.
- End-to-end testing — send test transactions through the full workflow (e.g., 204 → 990 → 214 → 210) and confirm that business systems process them correctly.
- Certification — some large trading partners (e.g., Walmart, major carriers) formally certify EDI connections before activating them.
Common EDI Challenges
| Challenge | Description | Mitigation |
|---|---|---|
| Trading partner variability | Each partner may use different versions, segments, or optional fields | Maintain partner-specific maps; use flexible translators |
| Error resolution | Rejected transactions may lack clear error descriptions | Implement robust 997/CONTRL acknowledgment processing |
| Onboarding time | New partner setup can take weeks to months | Use EDI-managed services or VAN-provided templates |
| Version management | Standards evolve; partners upgrade at different times | Support multiple versions simultaneously |
| Data quality | Garbage-in, garbage-out — upstream data errors propagate through EDI | Validate data before translation; implement business rules |
Resources
| Resource | Description | Link |
|---|---|---|
| ASC X12 Standards | Official ANSI X12 transaction set library and implementation guides | x12.org |
| UN/EDIFACT Directory | Official UN/CEFACT EDIFACT message directory and specifications | unece.org/trade/untdid |
| DCSA Standards | Digital Container Shipping Association — open API standards for ocean shipping | dcsa.org |
| IATA ONE Record | IATA's vision for end-to-end digital air cargo data sharing | iata.org/one-record |
| GS1 EPCIS Standard | Supply chain event data standard for visibility and traceability | gs1.org/standards/epcis |
Related Topics
- Documentation Flow — how shipping documents move between parties in freight forwarding
- Booking Process — end-to-end booking workflow that EDI automates
- Tracking & Visibility — shipment tracking technologies including EDI 214 and IFTSTA
- Import/Export Documentation — customs filings often transmitted via EDIFACT (CUSCAR, CUSDEC)
- Labels & Barcoding — GS1 standards that complement EDI data exchange