Electronic Data Interchange (EDI) remains the backbone of shipper–carrier communication in North American freight. A TMS that treats EDI as a one-time import script will fail in production when partners send duplicate tenders, non-standard qualifiers or status updates at 2 AM. This guide explains the three most common transportation transactions — 204, 214 and 210 — and the integration patterns Kode Builder implements for carriers and brokers on AWS.
EDI Basics in Transportation
X12 EDI defines structured messages exchanged via VAN (Value Added Network), AS2, SFTP or API gateways. Each trading partner publishes an implementation guide specifying segment usage, mandatory fields and code lists. Your TMS EDI layer must parse inbound files, map to internal load/shipment models, generate outbound acknowledgments and archive raw payloads for audit.
EDI 204 — Motor Carrier Load Tender
The 204 is a shipper-to-carrier (or broker) request to move freight. Key data: shipment ID, stops (pickup/delivery with windows), weight, equipment type, references and rate information when included.
TMS handling:
- Parse 204 → create or update load record idempotently (same shipment ID must not duplicate)
- Respond with 990 (Response to a Load Tender) — accept, decline or accept with changes
- Surface validation errors to ops when required segments missing
- Support cancellation and update 204 variants that modify open loads
Partner-specific quirks are normal — one shipper's "stop sequence" rules may differ from another. Maintain per-partner mapping profiles, not one global transform.
EDI 214 — Transportation Carrier Shipment Status
The 214 reports shipment milestones: en route, arrived at pickup, departed, delivered, exception codes. Carriers and brokers send 214s to shippers; shippers expect them aligned with internal tracking portals.
TMS handling:
- Generate 214 from dispatch events, driver app scans or telematics geofences
- Map internal status codes to partner-specific EDI reason codes
- Queue and retry failed transmissions; never lose status history locally even if EDI send fails
- Throttle high-frequency GPS-derived events to meaningful business milestones
EDI 210 — Motor Carrier Freight Details and Invoice
The 210 is the electronic freight invoice sent to the shipper or factor. It includes charges, accessorials, references tying back to the original tender and delivery proof references when required.
TMS handling:
- Generate 210 from approved billing records — not draft invoices
- Reconcile line haul, fuel surcharge and accessorial codes with contract rate tables
- Support corrections (210 with adjustment purpose) and duplicate detection
- Archive 210 payload with invoice PDF and POD documents
EDI Service Architecture
Separate EDI processing from core TMS API:
- Inbound pipeline: Receive file → validate envelope → parse X12 → map → persist load → emit domain event
- Outbound pipeline: Business event → build X12 → validate against partner spec → transmit → log interchange control numbers
- Dead-letter queue: Failed maps go to ops review UI with raw segment highlighted
- Idempotency keys: Shipment ID + transaction type + control number prevent double processing
- Monitoring: Alerts on partner SLA breaches (no 214 within expected window post-pickup)
Store raw EDI in S3 with retention aligned to dispute timelines. Use SQS for async processing so API latency stays independent of file size.
Testing and Partner Onboarding
Onboarding a new EDI partner typically requires:
Common Production Failures
- Duplicate load creation when idempotency ignored
- Status code mismatches causing shipper chargebacks
- Invoice 210 totals not matching tendered rate expectations
- Silent failures when VAN mailbox polling stops
- Timezone mishandling on appointment windows
Design admin tools so dispatchers can see EDI state per load — last sent 214, pending 210, last error message — without asking engineering.