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
| Set | Name | Direction | What it does |
|---|---|---|---|
| 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
| Symptom | Usual cause | Prevention |
|---|---|---|
| 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
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.
| Option | How it works | Strengths | 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 Consulting 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 a file was received and whether it was structurally valid. A 990 Response to a Load Tender is a business decision: the carrier accepting or declining the load. A shipper can receive a clean 997 for a tender and still be waiting on the 990.
Do all shippers use the same EDI format?
No. Most use ANSI X12 transaction sets, but each trading partner publishes its own implementation guide that specifies the version, required segments, code values and timing rules. Two shippers can both send a 204 and still require different handling.
Should a small carrier use a VAN, AS2 or an API?
It depends on what your trading partners require and how many you have. A VAN is simple to start and connects to many partners through one mailbox but usually carries usage fees. AS2 connects directly over the internet with signing, encryption and receipts, which suits high-volume partners. APIs are growing for real-time tracking and tendering but are partner-specific. Many carriers use a mix.
How long does it take to onboard a new EDI trading partner?
It varies widely with the partner's testing process and your TMS setup. Simple onboardings can move in a few weeks, while partners with strict certification steps can take longer. Having clean mapping, a test environment and a named owner on your side shortens the timeline.
Does Strong Tower Consulting sell EDI software?
No. Strong Tower Consulting is independent advisory. We help carriers set up, test and troubleshoot EDI with the TMS and providers they already use, and our consulting never requires buying our sister company's software.
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.