Transportation EDI Guide: 204, 990, 214, and 210 Explained
(Written by the EDI Support LLC team with 100+ years of EDI implementation experience)
Published July 2026
Transportation EDI Guide: 204, 990, 214, and 210 Explained
(Written by the EDI Support LLC team with 100+ years of EDI implementation experience)
Published July 2026
Key Takeaways
- Four documents carry a truckload move: the 204 tenders the load, the 990 accepts or declines it, the 214 reports status along the way, and the 210 invoices for it.
- Direction depends on your role. For a carrier the 204 comes in and the rest go out; for a shipper or broker it reverses.
- Two documents cause most of the trouble. The 990 is time-sensitive because tenders expire, and the 210 gets rejected when it doesn’t match the original 204.
- Every partner is a little different. X12 is the foundation, but codes, qualifiers, and required fields vary by partner, which is why mapping is the real work.
What is Transportation EDI?
Transportation EDI is the electronic exchange of shipment documents between shippers, brokers, and motor carriers using standardized ANSI X12 formats. Rather than tendering loads by email and chasing status by phone, the parties exchange structured documents that each system can read the same way: a 204 to offer a load, a 990 to answer, a 214 to report status, and a 210 to invoice.
Most large shippers and brokers require EDI before they will tender freight to a carrier at volume. It is the entry condition for dedicated lanes and steady freight, not an optional efficiency upgrade. The documents themselves are well established and moving them between systems is largely a solved problem. The harder question is what happens to each document after it arrives. Whether a load tender becomes a load your team can act on, or just a file sitting in a folder. That gap between moving data and managing it, is where most of the real cost and risk in transportation EDI lives.
The rest of this guide walks the four documents in the order a load actually moves, shows what each one carries, and points out where things go wrong.
The Transportation EDI Load Lifecycle
A single truckload move generates a predictable sequence of documents. Each one has a direction and a trigger.
|
Step |
Document |
Direction |
What it does |
|
1 |
EDI 204 Load Tender |
Inbound |
Shipper or broker offers a specific load |
|
2 |
EDI 990 Response to a Load Tender |
Outbound |
Carrier accepts or declines the offer |
|
3 |
EDI 214 Shipment Status Message |
Outbound |
Carrier reports pickup, transit, and delivery events |
|
4 |
EDI 210 Freight Details and Invoice |
Outbound |
Carrier bills for the completed load |
|
5 |
EDI 997 Functional Acknowledgment |
Both |
Confirms technical receipt of each document |
The flow reads: 204 → 990 → 214 (repeats) → 210, with a 997 shadowing each transmission to confirm it arrived intact. EDI 214 is the only one that repeats; a carrier sends several across the life of a load as the shipment hits each milestone.
The direction column matters more than it first appears. The same four documents reverse direction depending on your role, and a setup built only for the carrier’s side cannot serve a shipper or broker without rework. A carrier receives the 204 and sends the rest. A shipper sends the 204 and receives the rest. A broker does both at once. Any honest assessment of a transportation EDI setup starts with which directions it supports, not just which document numbers.
A Load From Tender to Payment: The Full Sequence
Transportation EDI Document Flow Example
The fastest way to understand how these documents fit together is to follow one load through all four. Here is a single truckload move, Atlanta to Miami, from the moment it is offered to the moment it is paid.
- The shipper tenders the load (204):
A shipper needs 20 pallets moved from a warehouse in Atlanta on Friday to a distribution center in Miami by Monday. Their system sends an EDI 204 to the carrier: pickup location and window, delivery location and window, 20 pallets at roughly 15,000 lbs, a 53-foot van required, and a linehaul rate of $1,200. The 204 carries a shipment ID the two parties will use to reference this load in every document that follows. - The carrier answers (990):
The carrier’s system receives the 204. A dispatcher reviews the lane, the rate, and available equipment, and accepts. The carrier sends back an EDI 990 with response code A and the same shipment ID, confirming they will haul the load as tendered. Had the dispatcher declined, the 990 would carry code D, and the shipper’s system would tender the load to the next carrier. Because the shipper’s tender was time-boxed, the value of that 990 depended on it going out before the window closed. - The carrier reports status as it moves (214).
The load now generates a series of EDI 214 messages, each carrying an AT7 status code:
Truck arrives in Atlanta to load → 214 with X3 (arrived at pickup)
Loaded and departing → 214 with AF (departed pickup)
On the road → 214 with X6 (en route), often with an estimated delivery
Arrives in Miami → 214 with X1 (arrival)
Freight delivered → 214 with D1 (delivery)
Each EDI 214 references the same shipment ID and carries the reference numbers the shipper requires to match it, typically the BOL and the carrier’s PRO number. The shipper’s system uses this sequence to track the load without a single phone call. If the truck were delayed, an exception 214 with SD would report it.
- The carrier bills the load (210).
With the load delivered, the carrier sends an EDI 210 invoice (that includes the $1,200 linehaul along with any accessorials say $150 in detention because the truck waited three hours at pickup). EDI 210 carries the same shipment ID, the BOL, and the PRO number, so the shipper can match the invoice against the original 204 and the delivery status. If the billed rate matches the tendered rate and the references line up, the invoice clears. If the 210 billed $1,400 with no supporting detail for the difference, it would stall for review. - Acknowledgments confirm receipt throughout (997).
Underneath all of this, each transmission is confirmed by a 997 in the opposite direction, so both sides know every document arrived intact — independent of whether the load was accepted or the invoice approved.
The whole cycle, tender to payment, can run without a phone call when every document carries the right references and each one is matched to the same load on both sides. When it breaks, it is almost always because one document lost the thread — a reference that did not carry through, a status that never arrived, a rate that did not match the tender. That is the practical case for treating these four not as separate files but as one connected record.
EDI 204: Motor Carrier Load Tender
An EDI 204 is a load tender: a shipper or broker offering a specific shipment to a carrier. It is the document that starts the relationship for a given load, and it carries everything the carrier needs to decide whether to haul it.
Direction: Shipper or broker to carrier (inbound for the carrier). In shipper and broker workflows the 204 is outbound.
What EDI 204 carries
A complete 204 describes the load in enough detail to accept or reject it without a phone call:
- Stops — pickup and delivery locations, in sequence, including multi-stop routes
- Dates and windows — when the freight is ready and when it is due
- Equipment — trailer type and size, such as a 53-foot van or a reefer
- Commodity and weight — what is shipping and how heavy it is
- References — the load or shipment ID, PO numbers, and other identifiers the parties will use to track the load
- Rate — in most cases the offered linehaul, though some tender models leave rate to negotiation
Key segments
The 204 is built from X12 segments. The ones that carry the load’s substance:
| Segment | Purpose |
| B2 | Beginning segment; carries the SCAC and the shipment identification number |
| B2A | Purpose of the transaction: original, update, or cancellation |
| L11 | Reference numbers such as PO, BOL, or load ID |
| N1 / N3 / N4 | Party name, street address, and city/state/ZIP for each stop |
| S5 | Stop-off details, sequenced, with weight and quantity per stop |
| N7 | Equipment description, including length and type |
| G62 | Dates and times for pickup and delivery |
Sample 204 (annotated)
A simplified 204 load tender. Each segment is labeled with what it carries.
ST*204*0001~ Transaction set header: this is a 204
B2**SCAC**12345**123456~ Shipment ID 12345, carrier SCAC
B2A*00*LT~ Purpose 00 = original tender (LT = load tender)
L11*PO98765*PO~ Reference: PO number 98765
N7**5300*6000*G*******TV~ Equipment: 53 ft trailer van (TV)
S5*1*CL*15000*L~ Stop 1, complete load, 15,000 lbs
N1*SF*WAREHOUSE A~ Ship-from party
N3*123 INDUSTRIAL WAY~ Ship-from street address
N4*ATLANTA*GA*30303~ Ship-from city, state, ZIP
G62*10*20250117~ Pickup date 2025-01-17
S5*2*CU~ Stop 2, unload
N1*ST*DC MIAMI~ Ship-to party
N4*MIAMI*FL*33101~ Ship-to city, state, ZIP
G62*11*20250120~ Delivery date 2025-01-20
SE*15*0001~ Transaction set trailer: 15 segments
The B2A*00 is the segment to watch. A 00 marks an original tender; other purpose codes mark updates and cancellations, and a setup that ignores them will process a cancellation as though nothing changed.
Original, update, and cancellation
The B2A segment carries a purpose code that tells the receiver whether the 204 is an original tender, an update to a load already tendered, or a cancellation. This matters more than it looks. A setup configured only for original tenders can miss an update or cancellation, which is how a truck ends up dispatched to a load that was pulled. Purpose-code handling should be configured and tested per partner rather than assumed.
Where EDI 204 goes wrong
The most common problems are incomplete tenders and unhandled updates. A 204 missing a load number, a pickup, or a delivery cannot become a usable load, and the right behavior is to raise it for review rather than create a broken record and move on. Conflicting tenders like an update that clashes with an existing load should be caught and flagged, not silently written over the top of what was there. The distinction sounds academic until a silently overwritten tender puts a truck at the wrong dock; catching these at the point of import is what separates a system that manages loads from one that just parses files.
EDI 990: Response to a Load Tender
An EDI 990 is the carrier’s answer to a 204: accept or decline the tendered load. It is the shortest document in the set and the most time-sensitive, because the offer it answers usually has a deadline.
Direction: Carrier to shipper or broker (outbound for the carrier). In shipper and broker workflows the 990 is inbound.
Accept, decline, or conditionally accept
The 990 communicates the carrier’s decision through a response code in its beginning segment. The core outcomes:
|
Response |
Meaning |
|
A |
Accept — the carrier will haul the load as tendered |
|
D |
Decline — the carrier will not take the load |
|
Conditional / counter |
Where the partner supports it, the carrier proposes a change to terms |
Not every partner supports conditional responses; many treat the 990 as a straight accept or decline and handle changes with a fresh 204.
Key segments
|
Segment |
Purpose |
|
B1 |
Beginning segment; carries the SCAC, shipment ID, and the response code |
|
N9 / L11 |
Reference numbers linking the response back to the original tender |
|
G62 |
Confirmed or modified pickup and delivery dates |
Sample 990 (annotated)
The carrier’s response to the tender above. The 990 is short by design.
ST*990*0001~ Transaction set header: this is a 990
B1*SCAC*12345*20250116*A~ Shipment 12345, response A = accept
N9*PO*PO98765~ Reference back to the tender’s PO
SE*4*0001~ Transaction set trailer: 4 segments
The entire business meaning sits in one character: the A in the B1 segment. Change it to D and the same document declines the load. The N9 ties the response to the original 204 so the shipper’s system knows which tender was answered.
Why response time is the whole game
Response windows on load tenders are set by each shipper or broker and can be short. When a window closes, many tendering systems withdraw the offer and route the load to the next carrier automatically, often with no notification. This makes the 990 unlike most EDI documents: it cannot be a batch job you process when your workflow gets to it, because the offer is being measured against someone else’s clock. A system that polls for new documents infrequently can burn the entire window before anyone sees the tender, and the load is gone before a decision is ever made. How quickly a received 204 turns into a sent EDI 990 is the single most important thing to get right in a carrier setup.
EDI 990 is not EDI 997
This trips up a lot of new implementers. An EDI 997 is a functional acknowledgment that confirms a document arrived and parsed correctly; it says nothing about the business decision. An EDI 990 is the business response: yes or no to the load. A carrier receiving a 204 might send a 997 to confirm receipt and then a 990 to decline the load. Best practice is to use both, the 997 for technical receipt of every inbound document and EDI 990 specifically for the load-tender decision.
Rates flow from EDI 990 to EDI 210
Whatever rate and terms are agreed at the 990 stage should carry through to EDI 210 invoice at the end. When the invoice disagrees with what was accepted, it creates a dispute. This is the practical argument for keeping the tender, the response, and the invoice attached to one load record rather than scattered across three separate files: the mismatch is visible before it becomes a payment delay, because the agreed rate and the billed rate live in the same place.
EDI 214: Transportation Carrier Shipment Status Messa
An EDI 214 reports where a shipment is and what has happened to it. A carrier sends a series of 214s across the life of a load, each carrying a status code that tells the shipper the latest milestone or exception.
Direction: Carrier to shipper or broker (outbound for the carrier). In shipper and broker workflows the 214 is inbound.
The AT7 status code
The heart of the 214 is the AT7 segment, which carries the status code. The X12 standard defines dozens of them. In practice a small set does most of the work, and the exact meaning of each code is trading-partner specific — this is the single most important caveat on the whole document. Treat the table below as the common usage and confirm each code against the partner’s implementation guide.
|
Code |
Common usage |
|
X3 |
Arrived at pickup location |
|
AF |
Departed pickup location |
|
X6 |
En route |
|
AG |
Estimated delivery, or delivery-related status depending on partner |
|
X1 |
Arrival status; pickup or delivery depending on partner |
|
D1 |
At or completed delivery |
|
CD |
Carrier departed delivery / delivery complete |
|
AA |
Pickup or delivery appointment status |
|
A9 |
Shipment damaged (exception) |
|
A3 |
Shipment returned to shipper (exception) |
|
AH |
Attempted delivery (exception) |
|
SD |
Shipment delayed (exception) |
Partners do not read these identically: some use X1 for pickup arrival, others for delivery; AG and D1 vary in where they sit relative to actual delivery. An EDI 214 carrying the right code with the wrong meaning for that partner will misreport the shipment even though nothing technically failed. Confirm the codes and the required sequence per implementation guide.
Key segments
|
Segment |
Purpose |
|
B10 |
Beginning segment; shipment ID, SCAC, and reference |
|
LX |
Groups the status detail that follows |
|
AT7 |
The status code, reason, date, and time |
|
MS1 / MS2 |
Location: city, state, and equipment or carrier detail |
Reference qualifiers
An EDI 214 carries the reference numbers the receiver uses to match the right shipment. The common qualifiers:
- BM — bill of lading number
- CN — the carrier’s PRO number
- SI — shipper identification
- PO — purchase order number
Partners differ on which they require, and a 214 carrying the wrong reference may not match anything on the receiving side.
Sample 214 (annotated)
One 214 reporting departure from pickup. A real load produces several of these.
ST*214*0001~ Transaction set header: this is a 214
B10*12345*LOAD123*SCAC~ Shipment 12345, carrier reference, SCAC
LX*1~ Detail loop
AT7*AF***NS*20250117*0800*LT~ Status AF = departed pickup, 2025-01-17 08:00
MS1*ATLANTA*GA~ Location: Atlanta, GA
MS2*SCAC*TRAILER123~ Equipment: carrier and trailer number
SE*6*0001~ Transaction set trailer: 6 segments
The AT7 segment is the payload. The AF here is the status code; swap it for X3, X1, D1, or an exception code and the same structure reports a different milestone. The date and time in the AT7 are what the shipper uses to judge whether status was reported on time.
Completeness is graded, not just accuracy
Shippers judge status reporting on how complete and timely it is, and many track it on a carrier scorecard. Sending a delivered status with no pickup or in-transit events means the shipper had no visibility for the entire move, and that gap shows up on the scorecard even though every individual message was valid. The practical rule is to send the sequence of events the partner requires, not only the milestones that seem important. Status reporting is one place were doing the minimum and doing it correctly are not the same thing.
EDI 210: Motor Carrier Freight Details and Invoice
EDI 210 is the carrier’s freight invoice. It bills the linehaul plus any accessorial charges for the completed load, and it is the document that determines how fast the carrier gets paid.
Direction: Carrier to shipper or broker (outbound for the carrier). In shipper and broker workflows the 210 is inbound, and the party receiving it processes and matches it against the load.
What an EDI 210 carries
- Linehaul — the base freight charge for the move
- Accessorials — detention, layover, lumper, fuel surcharge, stop-off charges, and similar
- References — the load ID, BOL, and PRO numbers that tie the invoice back to the shipment and the original 204
- Weight and quantity — the billed shipment detail
Key segments
|
Segment |
Purpose |
|
B3 |
Beginning segment; invoice number, shipment ID, and net amount |
|
N1 |
Parties to the invoice |
|
L0 / L1 |
Line-item detail and the freight charge/rate breakdown |
|
L3 |
Total weight, charges, and summary |
EDI 210 must agree with EDI 204
The recurring theme of invoice problems is mismatch against the original tender. When an invoice is matched against the load it bills, by load number and available references, the failures cluster into a handful of causes:
|
Cause |
What is happening |
|
Rate mismatch |
The invoiced amount does not match the rate agreed at tender |
|
Missing references |
BOL, PRO, or shipment ID is absent or formatted differently than on the 204 |
|
Unauthorized accessorials |
Detention or layover billed without the required supporting detail |
|
Weight discrepancy |
Billed weight is outside tolerance against the tendered or scaled weight |
|
Duplicate invoice |
The same invoice number is submitted again after a correction |
|
Timing |
The invoice arrives before the delivery status, so there is nothing to match against yet |
Sample 210 (annotated)
The freight invoice for the delivered load.
ST*210*0001~ Transaction set header: this is a 210
B3**INV5001*12345**PP*1350***20250120~ Invoice 5001, shipment 12345, $1,350 prepaid
N1*SF*WAREHOUSE A~ Ship-from party
N1*ST*DC MIAMI~ Ship-to party
L11*PO98765*PO~ Reference: PO number, ties to the 204
L0*1***15000*N***1*PLT~ Line item: 15,000 lbs, 1 pallet group
L1*1***120000*****LNH~ Linehaul charge $1,200.00
L1*2***15000*****DET~ Detention charge $150.00
L3*15000*N***135000~ Totals: 15,000 lbs, $1,350.00
SE*10*0001~ Transaction set trailer: 10 segments
Note the L11 carrying the same PO that appeared on the 204 and the 990. That reference is what lets the shipper match this invoice back to the load it bills. The two L1 segments separate linehaul from the detention accessorial — when a 210 is rejected for an unsupported accessorial, it is usually because a charge like this arrived without the detail to justify it.
The pattern under all of these is the same: EDI 210 has to agree with EDI 204, and every mismatch is easier to catch when the invoice and the tender live on the same record instead of in two separate files. Some partner systems delay or reject an invoice without sending a detailed reason, so the ability to investigate from your own side to see the tender, the delivery status, and the invoice together is often what turns a stalled payment into a resolved one.
EDI 997: Functional Acknowledgment
An EDI 997 confirms that an EDI document arrived and parsed correctly. It is not a business response; it does not say a load was accepted or an invoice approved. It says only that the transmission was received intact and was structurally valid.
Direction: Both. Each party sends a 997 to confirm receipt of the documents it gets.
EDI 997 matters because most trading partners require it for every transmission and use it to reconcile what they sent against what you received. If a shipper sends a 204 and never gets a 997 back, they know the document did not land, independent of whether you later accept or decline the load. A common partner practice is to require 997s in both directions across all four documents and to use them to catch dropped transmissions early. Treat EDI 997 as the technical receipt layer underneath the business documents, not as a substitute for the 990.
Sample 997 (annotated)
A 997 acknowledging the 204 tender from earlier. It reports that the document was received and structurally valid.
ST*997*0001~ Transaction set header: this is a 997
AK1*SM*123456~ Acknowledging a 204 (SM = motor carrier load tender group)
AK2*204*0001~ The specific transaction being acknowledged
AK5*A~ Transaction accepted (A = accepted)
AK9*A*1*1*1~ Group accepted: 1 received, 1 accepted
SE*6*0001~ Transaction set trailer: 6 segments
The AK5 and AK9 segments carry the verdict. An A means the document was accepted at the syntax level; an R would mean rejected, with error codes identifying what failed. Note what the 997 does not say: nothing about whether the load was accepted. That decision belongs to the 990. The 997 only confirms the 204 arrived and parsed.
Connectivity: AS2, SFTP, VAN, and API
The four documents have to travel between systems, and transportation uses the same connectivity options as the rest of EDI. Which one a given relationship uses is set by the partner.
|
Method |
Common with |
Notes |
|
AS2 |
Large shippers, major brokers |
Direct and encrypted, certificate based. Certificates expire and must be renewed on a cycle |
|
SFTP |
Brokers, 3PLs, mid-size shippers |
The most common setup in transportation; simpler than AS2 and widely accepted |
|
VAN |
Legacy shipper relationships |
Still in use; a value-added network routes documents and can add per-character cost |
|
API |
Newer digital brokers |
Growing but inconsistent; many brokers run API and EDI in parallel rather than replacing one with the other |
One reality worth naming: a meaningful share of brokers still expect small carriers to accept tenders in a web portal rather than over EDI. That works at low volume and becomes a bottleneck as load count grows, because every tender is a manual login instead of a document your system can act on.
Testing and Go-Live: What to Expect
Every trading partner requires testing before they will send you live freight, and testing is where most onboarding time actually goes. The documents can be mapped correctly and still fail testing, because the partner is checking their specific requirements against a live exchange, not just valid X12.
Testing runs the full sequence, not one document at a time. A typical cycle with a shipper or broker:
|
Stage |
What happens |
|
Connectivity check |
Confirm documents can move both ways over the agreed AS2, SFTP, or VAN connection |
|
Inbound test |
The partner sends a test 204; you confirm it lands and creates a usable load |
|
Response test |
You return a 990 accepting or declining, in the format and timing they expect |
|
Status test |
You send 214 status events in the sequence the partner requires |
|
Invoice test |
You submit a 210 that matches the test tender’s rate and references |
|
Corrections and retests |
Failures are fixed and the affected documents are re-sent until they pass |
|
Sign-off |
The partner formally approves the setup and enables production |
The pattern that catches carriers off guard is that testing is gated by the partner, not by you. You can have every document ready and still wait days for the partner’s EDI team to review a test round. The technical work is rarely the bottleneck; partner review schedules are. This is why a single partner can take a couple of weeks and why onboarding several at once takes longer than the sum of the technical effort.
A few things that keep testing moving:
- Read the implementation guide before building, not during testing. Most failed test rounds trace back to a requirement that was in the guide all along — a qualifier, a required segment, a code the partner expects.
- Test the exceptions, not just the happy path. A setup that passes a clean load can still fail on a multi-stop tender, a cancellation, or an accessorial. Partners often test these deliberately.
- Keep one person accountable for the exchange. Testing stalls when nobody owns following up with the partner. The work is coordination as much as configuration.
What “go-live” means in transportation EDI
Go-live is not “the files worked once.” It means the partner has signed off, production credentials are active, and the first live loads are being watched closely. The first few live transactions are where problems that testing missed tend to surface, so the early days of production deserve more attention than steady-state operation. Confirm the first live 204 creates a correct load, the first 990 goes out in the window, the first 214 sequence is accepted, and the first 210 clears — then you are genuinely live with that partner.
Each new partner is its own testing cycle. Passing certification with one shipper does not carry over to the next, because the requirements are partner-specific. The upside is that a clean, repeatable process makes each additional partner faster than the last.
Other Transportation EDI Documents
The four core documents along with EDI 997 cover most truckload moves, but the X12 transportation set is larger. Depending on the trading partner and the type of freight, you may encounter:
|
Document |
Name |
Purpose |
|
EDI 211 |
Motor Carrier Bill of Lading |
The electronic bill of lading a shipper sends to a carrier |
|
EDI 212 |
Motor Carrier Delivery Trailer Manifest |
Details the contents of a trailer for delivery |
|
EDI 213 |
Motor Carrier Shipment Status Inquiry |
A request for status, the pull-based counterpart to the 214 |
|
EDI 214 |
Transportation Carrier Shipment Status Message |
Covered above; the push-based status report |
|
EDI 215 |
Motor Carrier Pickup Manifest |
Lists shipments to be picked up |
|
EDI 217 |
Motor Carrier Loading and Route Guide |
Loading and routing instructions |
|
EDI 990 |
Response to a Load Tender |
Covered above |
Most carriers start with the core 204, 990, 214, and 210, and add others only when a specific partner requires them. The requirement almost always comes from the partner’s implementation guide rather than from the carrier’s own choice.
From Files to Records: What Separates Transportation EDI Setups
Most providers can move all four documents. The difference that shows up in daily operations is whether each document becomes an operational record or stays a file. It is worth stating plainly because it is the part buyers discover only after they have signed.
A translator receives a document and archives a copy. Connecting that document to the actual load (the dispatch, the shipment, the invoice) is left to you. The alternative is a system where the 204 becomes a load, the 990 becomes a recorded decision with its history, each 214 becomes a status event on that load, and the 210 becomes an invoice matched back to the tender. When the documents become records, you can see what happened, act on it, and trace any record back to the EDI that produced it.
Be honest about what automates
There is a persistent claim in transportation EDI marketing that the whole cycle “runs itself.” In practice, the durable automation is narrower and worth stating accurately: a system can generate an outbound 990 after a dispatcher records a decision or queue an EDI 214 after someone enters a status event, but the decision and the entry are still human. Good tooling removes duplicate keying and surfaces what needs attention. It does not remove the operator from the loop, and setups sold as fully hands-off tend to hide the manual steps rather than eliminate them. A buyer is better served knowing exactly which steps are automatic and which are not.
Exceptions should be actions, not log lines
Documents fail. A tender arrives malformed, an invoice will not match, a status code does not map. The question that separates setups is what happens next: a log entry someone has to go find, or a review item attached to the load it belongs to. When an exception surfaces as an action against a specific record like this invoice, this tender, this load, the person who has to fix it knows what broke and where. That visibility is worth more than it sounds, because in transportation the cost of a missed exception is a chargeback, a stalled payment, or a truck in the wrong place.
This is the difference between a translator and a platform built around records
See how Elevate handles transportation EDI →
Chargebacks and Scorecards: Why Accuracy Pays
For carriers, transportation EDI is not only about moving documents, it is about avoiding the penalties that come from moving them wrong. Large shippers track carrier performance on scorecards and enforce it through chargebacks, and both are driven directly by the EDI you send.
A scorecard is the shipper’s running grade of your performance. It measures things from the 214 and 210 report: whether status events arrived, whether they arrived on time, whether shipments were tendered and delivered as promised, whether invoices matched. A carrier with a poor scorecard gets less freight, because shippers route loads to carriers who score well. The scorecard is quiet, nobody calls to tell you it slipped but it shows up as declining tender volume.
A chargeback is a direct financial penalty, deducted from what the shipper owes you, for a specific compliance failure. In transportation these commonly trace back to EDI:
|
Failure |
How it happens over EDI |
|
Late or missing status |
Required 214 events not sent, or sent after the deadline |
|
Missing ASN-level detail |
Shipment information the partner requires never transmitted |
|
Invoice discrepancies |
A 210 that does not match the tendered rate or references |
|
Tender non-compliance |
Loads accepted and then not covered, or 990s sent late |
The important point for a small carrier: these penalties are usually process failures, not mistakes on any single load. A recurring chargeback for late status does not mean one truck was late; it means status is not being reported the way the partner requires, every time. Retailers and large shippers will not call to explain. They deduct, and the pattern continues until the underlying process is fixed.
This is where the difference between moving files and keeping records becomes money. When the load, its status history, and its invoice live on one record, a chargeback can be investigated: you can see which status event was missing, whether the 210 matched the 204, when each document went out. When the documents are scattered files, the same investigation means reconstructing what happened from raw EDI after the deduction has already landed. Catching the gap before the shipper does is the entire value of good status and invoice discipline.
Who Sends What: Carrier, Shipper, Broker and 3PL
The same four documents serve different parties in different directions.
|
Role |
Sends |
Receives |
|
Carrier |
990, 214, 210 |
204 |
|
Shipper |
204 |
990, 214, 210 |
|
Broker |
204 to carriers; 990/214/210 up to shippers |
990/214/210 from carriers; 204 from shippers |
|
3PL |
Varies by role on each lane |
Varies by role on each lane |
Brokers and 3PLs are interesting cases because they sit in the middle and often act as both shipper and carrier depending on the relationship. A broker receives a 204 from a shipper, turns around and tenders a 204 to a carrier, collects the carrier’s 990, 214, and 210, and passes status and billing back up to the shipper. That double-sided role is why brokers and 3PLs cannot use a carrier-only setup: they need both directions of all four documents, and a system that only handles the carrier side leaves half their business unsupported.
What Does Transportation EDI Cost?
There is no single price for transportation EDI, and any number quoted without context is close to meaningless. What you pay depends on how many trading partners you run, how many documents each requires, your transaction volume, and how much integration you need. Understanding the structure of the cost matters more than any headline figure, because the structure is what determines your bill as you grow.
Most transportation EDI pricing is built from some combination of these components:
|
Cost component |
What it covers |
What drives it |
|
Setup / implementation |
Configuring and testing each trading partner |
Number of partners; complexity of their requirements |
|
Per-partner fees |
Ongoing cost for each active trading relationship |
How many shippers, brokers, or carriers you connect |
|
Document / transaction fees |
Per-document or per-kilocharacter charges |
Your monthly volume of tenders, statuses, and invoices |
|
Mapping |
Building and maintaining partner-specific maps |
Whether changes are included or billed each time |
|
Connectivity |
AS2, SFTP, or VAN transport |
Sometimes bundled, sometimes a separate line |
|
Integration |
Connecting EDI to your TMS or accounting system |
Depth of integration and the interface involved |
|
Support |
Help when something breaks |
Whether real support is included or a paid tier |
The costs that surprise people
The headline monthly fee is rarely where the real cost lives. The charges that catch small carriers and brokers off guard tend to be the ones buried below it:
- Per-partner fees that scale with growth. Adding a trading partner should be routine, but some pricing makes each new partner a meaningful recurring cost, so a growing network gets steadily more expensive.
- Mapping changes billed as new work. When a partner updates their spec (which they do often) a map has to change. Whether that is included or invoiced each time makes a large difference over a year.
- Transaction overages. Seasonal freight spikes can push volume past a plan tier. Whether pricing resets afterward or ratchets permanently upward is worth knowing before peak season, not during.
- Change requests and re-testing. Some providers treat every partner-driven change as billable, so a compliance update you did not ask for becomes a line item.
Questions that reveal the real number
Because the structure varies so much, the honest way to compare providers is to ask what the total looks like over a full year, not what the monthly fee is. Useful questions:
- What is the all-in cost for my first 12 months, including setup, per-partner, and transaction fees?
- Is adding a new trading partner a one-time fee, a recurring one, or both?
- Are mapping changes and partner spec updates included, or billed each time?
- What happens to my pricing when volume spikes and then drops back down?
- Is integration with my TMS or accounting system included or separate?
- Is support included, or is real support a paid tier?
The pattern worth looking for is pricing you can predict as you grow. A setup that is cheap for one partner but expensive to expand can cost more over two years than one with a higher starting point and no per-partner penalties. The clearest signal of a provider worth working with is a straight answer to “what will this cost me at scale” in writing, before you sign.
How much does Elevate charge for Transportation EDI?
Elevate uses one transparent structure across retail and transportation — a one-time setup per trading partner, a flat monthly platform fee, and per-document pricing that steps down as volume grows, with 997 acknowledgments free. For example, a carrier moving 2,000 documents a month pays the platform fee plus a per-document rate at the entry tier. Because transportation runs document-heavy, most carriers reach the lower per-document tiers quickly.
Transportation EDI Glossary
Transportation EDI carries its own vocabulary, much of it borrowed from freight operations rather than EDI itself. The terms that come up most in this guide:
|
Term |
What it means |
|
Accessorial |
A charge beyond the base linehaul — detention, layover, lumper, fuel surcharge, and similar. Billed on the 210. |
|
AT7 |
The segment in a 214 that carries the shipment status code and its date and time. |
|
BOL (Bill of Lading) |
The legal document listing the freight being shipped. Its number is a common reference across the 204, 214, and 210. |
|
Broker |
A middleman who arranges freight between shippers and carriers, receiving a 204 from a shipper and tendering its own 204 to a carrier. |
|
Carrier |
The motor carrier that hauls the freight. Receives the 204, sends the 990, 214, and 210. |
|
Detention |
A charge for time a truck waits at a pickup or delivery beyond an agreed window. A common accessorial on the 210. |
|
Implementation guide |
A trading partner’s document specifying exactly how they expect each EDI document formatted — segments, qualifiers, codes, and required fields. |
|
Linehaul |
The base freight charge for moving a load from origin to destination, before accessorials. |
|
Load tender |
An offer of a specific load from a shipper or broker to a carrier, sent as a 204. |
|
Lumper |
A third party paid to load or unload freight, typically at a warehouse. The fee often appears as an accessorial. |
|
PRO number |
The carrier’s own tracking number for a shipment. Referenced with the CN qualifier and used to match the 214 and 210 to a load. |
|
Qualifier |
A code that tells the receiver what a value represents — for example, whether a reference number is a PO, a BOL, or a PRO. |
|
Reefer |
A refrigerated trailer, used for temperature-controlled freight. |
|
SCAC |
Standard Carrier Alpha Code — a unique two-to-four-letter code identifying a motor carrier. Appears in the 204, 990, 214, and 210. |
|
Tender window |
The time limit a shipper or broker sets for a carrier to respond to a 204 before the load routes elsewhere. |
|
TMS (Transportation Management System) |
The software a carrier or broker uses to manage loads, dispatch, and billing. What transportation EDI integrates with. |
|
VAN (Value-Added Network) |
A third-party network that routes EDI documents between trading partners, an alternative to a direct AS2 or SFTP connection. |
FAQs
If a shipper or broker has asked you to be EDI capable, then yes. For most large shippers it is a condition of tendering freight at volume, not a preference. Below a few loads a week, a broker’s web portal can work. Past that, logging in to accept each tender by hand starts costing you loads through missed response windows, and manual status updates start showing up as gaps on your scorecard. The point where EDI becomes worth it is usually the point where manual handling starts costing you freight. Elevate handles the mapping, testing, monitoring, and partner coordination, so you focus on moving freight rather than managing documents.
The standard motor carrier lifecycle runs on four: EDI 204 load tender, EDI 990 tender response, EDI 214 shipment status and EDI 210 freight invoice. Most partners also require EDI 997 functional acknowledgment for technical receipt. Some add documents such as EDI 211 motor carrier bill of lading or EDI 213 status inquiry. The required set is decided by each trading partner.
EDI 204 is the offer and EDI 990 is the answer. A shipper or broker sends a 204 to tender a specific load. The carrier returns a 990 to accept or decline it. They are two halves of one exchange and reference the same shipment ID.
An EDI 997 is a technical acknowledgment confirming a document was received and parsed correctly. An EDI 990 is a business response confirming whether the carrier accepts the load. A carrier can send EDI 997 to confirm it received an EDI 204, then send an EDI 990 to decline the load. They answer different questions.
It depends on the partner, the documents involved, and how quickly they schedule you. Testing usually covers the full sequence that includes the partner sends a test 204, you return a 990, send 214 status events, and submit a 210 with corrections and retests along the way until each document matches their implementation guide and they sign off. The technical work is rarely the constraint; how fast the partner’s EDI team reviews each round is what typically drives the timeline.
Response windows are defined by each trading partner and vary, sometimes considerably. Confirm the deadline in each implementation guide. The practical point is that the offer often expires on the partner’s clock and the load routes elsewhere automatically, so the response path needs to be quick and reliable rather than a batch job.
Common ones include X3 for arrived at pickup, AF for departed pickup, X6 for en route, X1 for an arrival status, D1 for delivery, and exception codes such as A9 for damage and SD for delay. The exact meaning of each code is trading-partner specific, so confirm them against the implementation guide rather than assuming.
Most rejections trace back to a mismatch against the original 204: a rate that does not agree, a missing or reformatted BOL or PRO number, accessorials billed without supporting detail, or a weight outside tolerance. Invoices sent before the delivery status can also fail because there is nothing to match against yet.
It confirms that an EDI transmission arrived and was structurally valid. Partners use it to reconcile what they sent against what you received and to catch dropped documents. It does not indicate any business decision.
Yes. The same four documents run in the opposite direction for shippers and brokers. A shipper sends EDI 204 and receives EDI 990, 214, and 210. A broker sits in the middle, receiving an EDI 204 from a shipper and tendering its own EDI 204 to a carrier, which is why brokers need both directions supported.
AS2, SFTP, and VAN are all common, with SFTP the most widespread in transportation. Some newer brokers offer API connections, often alongside EDI rather than instead of it. The partner determines which method the relationship uses.
No, but it helps. Without a connected system, someone re-keys each load and triggers each response by hand. With integration, tenders can create load records, a recorded acceptance can generate EDI 990, entered status events can queue EDI 214s, and billing can generate EDI 210. All that can be integrated depends on the specific system and the agreed interface.
A carrier scorecard is a shipper’s running grade of how well a carrier performs, used to decide who gets freight. It measures things your EDI reports directly: whether 214 status events arrived and arrived on time, whether shipments were tendered and delivered as promised, and whether invoices matched the original tender. A carrier who scores well gets more loads; a carrier who scores poorly gets fewer, often without being told why. The scorecard is quiet, nobody calls when it slips so it usually shows up as declining tender volume rather than a direct complaint.
Yes, and they are one of the most common causes. Large shippers enforce compliance through chargebacks direct deductions from what they owe you and many trace straight back to EDI: late or missing 214 status events, invoices that do not match the tendered rate, or shipment detail that was never transmitted. The important part is that these are usually process failures rather than one-off mistakes. A recurring chargeback for late status does not mean one truck was late; it means status is not being reported the way the partner requires. Shippers rarely call to explain, they deduct, so the pattern continues until the underlying process is fixed.