EDI in one paragraph
Electronic Data Interchange is a standardized way for two companies' systems to exchange business documents without anyone retyping them. In North American trucking, most EDI follows the ANSI X12 standard, in which every document type is a numbered "transaction set." A shipper's system sends a load tender as a 204, the carrier's TMS answers with a 990, sends status updates as 214s, bills with a 210, and both sides confirm receipt of each file with a 997. Each file is wrapped in envelopes (the ISA and GS headers and the ST transaction header) that identify sender, receiver, version and control numbers.
For a carrier, EDI is less a technology choice than a customer requirement. Large shippers, 3PLs and brokers often will not add a carrier to their routing guide without it. And because EDI touches order entry, dispatch, tracking and billing, a weak setup leaks money in several places at once.
The five transactions every carrier should know
| Transaction Set | Formal Name | Direction | Operational Function |
|---|---|---|---|
| 204 | Motor Carrier Load Tender | Shipper to carrier | Offers a load: stops, dates, references, equipment, weights and often the rate |
| 990 | Response to a Load Tender | Carrier to shipper | Accepts or declines the tender |
| 214 | Transportation Carrier Shipment Status Message | Carrier to shipper | Reports status events: arrivals, departures, appointments, delays, delivery |
| 210 | Motor Carrier Freight Details and Invoice | Carrier to shipper | Bills the load: linehaul, FSC, accessorials, references |
| 997 | Functional Acknowledgment | Both directions | Confirms a file was received and whether it passed structural checks |
204: Load Tender
The 204 is the order. It carries the shipper's load or shipment ID, pickup and delivery stops with addresses and appointment windows, reference numbers such as PO and BOL numbers, equipment type, weight, piece counts and frequently the agreed rate. A purpose code tells you whether this 204 is an original tender, a change to an earlier one or a cancellation. Your TMS needs to handle all three correctly: a change should update the existing order, not create a duplicate, and a cancellation should stop dispatch before a truck rolls.
990: Response to Load Tender
The 990 is your answer: accept or decline, tied back to the shipper's load ID. Shippers typically set a response window, and an unanswered tender may be treated as a decline and passed to the next carrier in the routing guide. Tender acceptance rates also show up on many shipper scorecards. Automating the 990 from your TMS, once a planner accepts the load, is one of the simplest EDI wins.
214: Shipment Status
The 214 is your tracking feed. Each message carries a status code, a date and time, a location and the shipment references. Commonly used status codes include:
- X3: arrived at pickup location
- AF: departed pickup location
- X6: en route to delivery location
- AG: estimated delivery
- X1: arrived at delivery location
- D1: completed unloading at delivery location
Partners often also require reason codes for late or missed appointments. Exact code lists and timing rules vary by partner, so always work from their implementation guide. Many shippers measure on-time status reporting as well as on-time delivery, so late or missing 214s can hurt a carrier's scorecard even when the freight arrived on time.
210: Freight Invoice
The 210 is the bill. It carries the invoice number, the shipper's references, and charge lines for linehaul, fuel surcharge and accessorials, each with partner-specific charge codes. Many shippers auto-match the 210 against the 204 rate and their own records, and reject or short-pay anything that does not match. Getting accessorials such as detention approved and coded correctly before the 210 goes out is the difference between getting paid in the normal cycle and sitting in a dispute queue.
997: Functional Acknowledgment
The 997 says "I received your file, and here is whether it was structurally valid." It reports acceptance, acceptance with errors, or rejection at the group and transaction level. It does not mean the business content was accepted. A shipper can 997 your 210 and still reject the invoice in their payables system. Track missing and rejected 997s, because they are often the first warning that something in your mapping changed.
How the transactions flow on a typical load
- Shipper sends a 204 original tender. Your system returns a 997.
- Planner reviews and accepts. TMS sends a 990 accept. Shipper returns a 997.
- Shipper sends a 204 change (new appointment). TMS updates the existing order and returns a 997.
- Driver arrives and departs pickup. TMS sends 214 messages, ideally triggered by ELD geofence or driver app events rather than manual keying.
- In transit, TMS sends estimated delivery and any delay updates as 214s.
- Driver arrives and unloads. TMS sends delivery 214s.
- Billing finalizes charges, and TMS sends a 210. Shipper returns a 997, then pays or disputes through its own process.
Some partners add other sets, such as the 211 bill of lading, 212 delivery trip manifest, 322 terminal operations (common in intermodal), 820 remittance advice or 824 application advice. Ask every new partner for its full list up front.
Common failures and how to prevent them
| Failure Symptom | Underlying Root Cause | Operational TMS Prevention Protocol |
|---|---|---|
| Duplicate orders from one tender | Change 204 processed as a new tender | Match on the shipper's load ID and handle purpose codes properly |
| Loads rolled to another carrier | 990 not sent inside the response window | Alerts on pending tenders; auto-send 990 on accept |
| Status goes dark | 214s depend on manual entry | Trigger events from ELD or driver app; monitor gaps |
| 214s rejected | Wrong status or reason codes, missing references, bad time zones | Map codes to the partner guide; send local time with time zone code where required |
| 210s rejected or short-paid | Charge codes wrong, rate mismatch with the 204, missing references | Validate 210 against the tender and partner rules before sending |
| Files silently not arriving | Expired certificates, changed credentials, full mailboxes, envelope ID errors | Monitor 997s and transmission logs daily; track certificate expiry |
| Everything breaks after a TMS upgrade | Map or export changes not regression tested | Re-test every partner's maps in a test environment before upgrading |
Watch the exception queue every day
Most EDI losses come from errors nobody looked at. Assign an owner to review failed and unacknowledged transactions daily, and give that person a simple way to see which loads, tenders and invoices are affected.
Testing with trading partners
Each trading partner publishes an implementation guide (sometimes called a companion guide or EDI spec) and usually runs a test cycle before turning on production. A smooth onboarding looks like this:
- Collect the specs. Implementation guides for every set, the X12 version, connectivity details, sender and receiver IDs, and the partner's testing contact.
- Map and configure. Map partner codes (stops, equipment, accessorials, status reasons) to your TMS codes. Set up the partner profile and envelopes.
- Connectivity test. Exchange a test file and confirm both sides receive it and return 997s.
- Scenario testing. Run original, change and cancel 204s; accepts and declines; a full set of 214 events including a late delivery with a reason code; and 210s with linehaul, FSC and at least one accessorial.
- Partner sign-off. Get written approval and an agreed go-live date.
- Go-live watch. Monitor every transaction closely for the first couple of weeks of production.
Onboarding checklist
- Partner implementation guides saved and version noted
- Sender and receiver qualifiers and IDs confirmed for test and production
- Code cross-reference tables built and reviewed by billing and dispatch
- Test environment pointed at the partner's test endpoint
- Every scenario run and saved with the partner's approval
- Monitoring and alerting turned on before production
- Internal owner named for daily exception review
Carrier EDI Trading Partner Certification & Protocol Matrix
Motor carrier EDI operations succeed or fail based on strict adherence to trading partner segment syntax and turnaround timers. Below is the comprehensive architectural breakdown of the core ANSI X12 freight transaction loop:
| Transaction | Critical X12 Segments | Standard Response SLA | Common Rejection Traps | Automated TMS Guardrail |
|---|---|---|---|---|
| EDI 204: Load Tender | B2 (Beginning Segment), B2A (Purpose Code: 00/01/04), N1 (Shipper/Consignee Name & Address), S5 (Stop-off Details), L11 (Reference Numbers) | Inbound (Instant structural 997 returned within 15 minutes) | Purpose code 04 (Change) handled as a new load, creating duplicate orders; missing equipment size qualifier (e.g. 53FT Dry Van). | Automated load ID deduplication logic that updates existing dispatch stops without erasing assigned power units. |
| EDI 990: Tender Response | B1 (Beginning Segment), N9 (Reference Number), V9 (Event Code: A=Accept, D=Decline) | Outbound (Sent within 60 to 120 minutes per shipper contract) | Sending accept after tender expiration window; mismatched shipper shipment identifier or SCAC code qualifier. | Automated countdown timers on dispatch boards triggering visual supervisor alerts at 50% of the contractual acceptance window. |
| EDI 214: Shipment Status | B10 (Beginning Segment), LX (Assigned Number), AT7 (Shipment Status: Code, Date, Time, Time Zone), MS1/MS2 (Equipment Location) | Outbound (Triggered within 15 to 30 minutes of dock event) | Sending UTC time instead of facility local time with time zone qualifier; missing reason code on appointment delay (e.g. Weather, Traffic). | ELD geofence triggers that generate AT7 arrival and departure messages automatically, validating time zone syntax against terminal postal codes. |
| EDI 210: Freight Invoice | B3 (Beginning Segment), N1 (Bill-To Party), IT1 (Item Detail), L1 (Rate & Charges), L3 (Total Weight & Freight Charges) | Outbound (Sent upon POD delivery capture and billing sign-off) | Accessorial line item codes (detention, lumper) omitted or misaligned with shipper rate matrix; FSC calculation variance. | Pre-transmission rerate audit validating billed charges against original 204 rate confirmation before releasing the 210 file to the VAN. |
| EDI 997: Functional Ack | AK1 (Functional Group Response), AK2 (Transaction Set Header), AK5 (Transaction Set Acknowledgment: A=Accepted, R=Rejected, E=Accepted with Errors) | Bi-directional (Generated within 15 minutes of file ingestion) | Treating 997 acceptance as invoice approval; ignoring AK5 'E' errors that precede downstream payables rejection. | Automated reconciliation daemon logging unmatched outbound transactions and alarming on rejected AK5 status within 2 hours. |
EDI 210 SAC Accessorial & 214 Event Status Mapping Architecture Matrix
Invoice rejections and scorecard penalties rarely stem from broken network envelopes; they occur when carrier TMS accessorial codes and tracking timestamps fail to reconcile with shipper-mandated companion guides. Below is the operational mapping specification for mission-critical invoice line items and transit telemetry:
| Charge / Event Type | Standard X12 Segment & Element | Industry Qualifiers | Rejection Risk Factor | Automated Pre-Transmission TMS Guardrail |
|---|---|---|---|---|
| Detention with Power (Loading/Unloading) | SAC Segment: SAC01=C (Charge), SAC02=DET001 / ZZ, SAC05=Amount | N9 Qualifier: TN (Transaction Reference) or OQ (Order Quantity) linking S5 Stop Number |
Shipper AP auto-rejects line item if facility arrival/departure timestamps are missing from N9 reference segments or variance exceeds 15 minutes. | TMS auto-populates SAC05 from ELD geofence duration minus contractual 2-hour free time, appending validated facility entry/exit timestamps. |
| Fuel Surcharge (FSC) Indexing | SAC Segment: SAC01=C, SAC02=FUE / FSC, SAC05=Amount | SAC08=Rate per mile ($/mi) or percentage rate; N9 Qualifier: DOE (Diesel Index Price) |
Shipper contract requires DOE Monday average published price; carrier TMS applied outdated weekly index or wrong regional PADD benchmark. | Nightly automated API pull from U.S. EIA / DOE diesel index; auto-locks active fuel bracket to the shipment order creation date. |
| Third-Party Lumper / Unloading Fee | SAC Segment: SAC01=C, SAC02=LUM / UNL, SAC05=Amount | L11 Qualifier: SE (Serial Number) or RC (Receipt Number) |
Shipper accounting holds entire 210 invoice because third-party warehouse receipt number is missing from L11 segment or scan is unlinked. | TMS forces dispatch lumper receipt indexing with OCR serial number extraction prior to permitting 210 batch invoice generation. |
| Stop-Off In-Transit Charges | SAC Segment: SAC01=C, SAC02=STO001 / SOC, SAC05=Amount | S5 Stop Sequence Number matching original 204 tender stop records | Sequence mismatch between billed intermediate stop order and shipper tender manifest triggers complete EDI 210 payables dispute. | Pre-invoice validation script verifies sequence numbers in S5/G62 against origin 204 stop payload before generating EDI 810/210 data stream. |
| En Route Milestone Telemetry (EDI 214) | AT7 Segment: AT701=X6 (En Route), AT702=Reason, AT705=Date, AT706=Time | MS1 (City, State, Country), MS2 (Equipment Number) | Manual dispatcher updates result in 8-hour tracking blackouts; shipper automated compliance engine flags carrier routing guide breach. | Carrier telematics daemon auto-transmits AT7 X6 telemetry every 2 hours or across state borders directly from cab ELD GPS coordinates. |
| Unscheduled Transit Delay / Breakdown | AT7 Segment: AT701=SD (Shipment Delayed), AT703=Reason Code (T1=Breakdown, W1=Weather, NA=Traffic) | CD Segment: Condition Description & revised ETA in G62 | Sending delay notification without mandatory standard ANSI reason code causes shipper TMS to auto-assign 100% carrier fault on scorecard. | Dispatcher incident intake screen requires mandatory reason code classification before allowing appointment ETA adjustment. |
VAN vs AS2 vs API
EDI documents need a way to travel between you and each partner. There are three common options, and many carriers end up with a mix.
| Protocol / Network | Mechanism | Primary Strengths | Operational Trade-offs |
|---|---|---|---|
| VAN (value-added network) | A third-party network acts as a mailbox; you send files to the VAN, which routes them to partners | One connection reaches many partners; tracking and support provided | Usage-based fees can grow with volume; another vendor to manage |
| AS2 | Direct point-to-point exchange over the internet using HTTP(S), with digital signatures, encryption and signed receipts (MDNs) | No per-document network fees; strong security and proof of delivery | Each partner is a separate setup; certificates must be managed and renewed |
| SFTP | Files exchanged over secure file transfer on a schedule | Simple and widely supported | Batch timing, so less suited to real-time tracking; fewer built-in receipts |
| API | Direct system-to-system calls, often JSON over HTTPS, defined by the partner or a platform | Near real-time; good fit for tracking and tendering updates | Each partner's API differs; not a universal replacement for X12 yet |
The right choice depends on what your partners require, how many you have and how much volume each sends. A carrier with a handful of large shippers may prefer AS2 for the volume partners and a VAN for the rest. A carrier whose customers are moving to real-time visibility platforms may need API connections for tracking alongside X12 for tenders and invoices.
How Strong Tower Consulting helps
Strong Tower helps carriers set up, test and stabilize EDI with the TMS and connectivity they already have. We read the partner specs, build and review code maps with your dispatch and billing teams, run scenario testing, set up exception monitoring, and troubleshoot the rejected 214s and short-paid 210s that are costing you money. We also connect EDI to ELD events so status updates send themselves.
- ELD, EDI & Back-Office Integration: trading partner setup, mapping, testing and monitoring.
- Business Process Optimization: tender response, tracking and billing workflows that support EDI.
- On-Site & Remote Support: ongoing help when files stop flowing.
Independent by design
Strong Tower Consulting never requires you to buy our software. We work with your current TMS, VAN and providers, and recommend changes only when they pay off. Read more about how we work. If billing rejections are your biggest pain, see our order-to-cash guide.
Frequently asked questions
What is the difference between a 990 and a 997?
A 997 Functional Acknowledgment only confirms that an EDI transmission was received and whether its envelope and segment syntax were structurally valid. A 990 Response to a Load Tender is a binding business decision: the carrier accepting or declining the tendered shipment. A shipper can receive a clean 997 for a tender and still be waiting on the 990 accept message.
Do all shippers use the same EDI format?
No. While North American freight shippers adhere to ANSI X12 standards, each trading partner issues a unique implementation companion guide. Shippers vary by X12 version (4010 vs 5010), mandatory custom segments, qualifier requirements, and timing windows. Two retail shippers can both transmit a 204 tender but require completely different TMS parsing maps.
Should a motor carrier use a VAN, AS2 or REST APIs?
Most enterprise carriers employ a hybrid strategy. Direct AS2 connections eliminate per-document transaction charges for high-volume anchor accounts. Value-Added Networks (VANs) provide a single mailbox connecting to hundreds of smaller freight brokers and 3PLs. Modern REST APIs complement EDI for real-time driver GPS tracking feeds and digital document retrieval.
How long does it take to onboard a new EDI trading partner?
Standard partner onboarding requires 2 to 6 weeks depending on the partner's certification protocol. Pre-configured translation maps and established staging sandboxes accelerate testing. Delays typically occur during invoice (EDI 210) rerate reconciliation and live status (EDI 214) appointment timing validation.
How does native TMS EDI integration eliminate third-party VAN mailbox costs?
Modern platforms like our sister company Exspeedite feature built-in native EDI translation engines supporting direct AS2 and FTP endpoints, bypassing intermediary VAN networks. Native processing eliminates per-kilocharacter transmission fees, reduces end-to-end latency to seconds, and provides dispatchers with instant tender visibility on the load board.
Does Strong Tower Consulting sell EDI translation software?
No. Strong Tower Consulting is an independent transportation technology advisory firm founded in Minnesota in 2008. We provide vendor-neutral EDI mapping, trading partner testing, and translation troubleshooting across Trimble Truckmate, TMWSuite, McLeod LoadMaster, and Exspeedite, without requiring proprietary software purchases.
ANSI and X12 are trademarks of their respective holders. Strong Tower Consulting is independent and not affiliated with or endorsed by any standards body or EDI provider.