The EDI 214 · Transportation Carrier Shipment Status Message is how a carrier reports what is happening to a load after it has been accepted: picked up, departed, arrived, delayed, delivered. It is the narration in the freight chain — the 204 · Motor Carrier Load Tender asks, the 990 · Response to a Load Tender decides, the 214 narrates, and the 210 · Motor Carrier Freight Details and Invoice bills.
A 214 that arrives late is not a status. It is history. The value of every event in a 214 is set by whether the receiver can still do something with it — reroute, warn the dock, tell the customer, reschedule the appointment — and that window closes fast. Teams that treat status messages as a log to file, rather than a feed to act on, end up with perfect records of failures nobody prevented.
What is the EDI 214 · Transportation Carrier Shipment Status Message?
The 214 is an X12 transaction set a motor carrier sends while a shipment it accepted is in progress, and at its end. Each message carries a status event: the pickup happened, the truck departed a stop, it arrived at a stop, it is delayed, or the delivery is complete. Events normally reference the shipment from the accepted 204, identify which stop they describe, and carry the date and time the event actually occurred — which is not always the date and time the message was sent.
Three ideas define it:
- It only exists against an accepted tender. A 214 narrates a commitment. If the load was never accepted with a 990, status events have nothing true to attach to.
- An event has two times, and both matter. The occurrence time says when the pickup, arrival, or delay happened in the real world. The transmission time says when you learned it. A delivery that happened at 09:00 and was reported at 16:00 was invisible for seven hours, and planning made in those hours was made blind.
- Sequence is meaning. Picked up, departed, arrived, delivered is a story in order. The same events arriving out of order — delivered reported before arrived, a delay reported after the delivery — are not just untidy; applied naively, they move a shipment's state backwards.
A 214 is usually generated from the carrier's dispatch and driver systems, increasingly from telematics, which is why its events can be frequent, automated, and — when nobody has defined which events matter — overwhelming.
How is the 214 different from the 204, the 990, and the 210?
These four documents form one freight chain, and the 214 is its running commentary:
- The 204 · Motor Carrier Load Tender opens the chain: the shipper or broker offers the load, with stops, windows, equipment, and commodity detail.
- The 990 · Response to a Load Tender is the carrier's answer — accept or decline — and the moment capacity is actually committed.
- The 214 · Transportation Carrier Shipment Status Message flows during the trip: pickup, departure, arrival, delay, and delivery events against the accepted tender.
- The 210 · Motor Carrier Freight Details and Invoice closes the money side after delivery, and it is audited against what the accepted tender promised and what the 214 says actually happened.
A useful shorthand: the 204 asks, the 990 decides, the 214 narrates, and the 210 bills. If the narration is late, out of order, or attached to the wrong load, the bill inherits the confusion.
Why does timing matter more than completeness in a 214?
Because freight decisions expire. Knowing a truck will miss a 14:00 appointment is valuable at 11:00 and almost worthless at 13:55. A status feed that eventually contains every event, in perfect detail, but delivers delay events after the window to act has closed will still produce missed appointments, idle dock crews, and surprised customers.
That changes what "good" means for a 214 flow. Completeness is a record-keeping virtue. Timeliness is the operational one. The flows worth trusting are measured on the gap between when something happened and when the receiver's system reflected it — not on how many event types they support.
Where do 214 flows usually break?
The first break is the late delay. The carrier knew the truck was behind — the driver reported it, dispatch saw it — but the delay event reaches the shipper after the appointment is already missed. Nothing in the document was wrong; it simply arrived when it could no longer change anything. The fix is to monitor the occurrence-to-receipt gap on exception events specifically, not average message latency.
The second break is out-of-order application. A delivered event is applied, then a late arrived event arrives and the system moves the shipment back to "arrived." State should only move forward: an event older than the state it would replace is information for the record, not an instruction to rewind the present.
The third break is the orphan status. The 214 references a shipment identifier the receiver cannot match — a tender that changed versions, a reference typed differently, an accepted load recorded under another number. The event is real and now useless, because narration attached to the wrong load, or to no load, misleads everyone who reads it.
The fourth break is silence mistaken for "on track." No event has arrived, so the dashboard shows the load progressing as planned. In freight, absence of a status is itself a status — a checkpoint that should have reported by now and has not is an exception worth raising before the appointment does it for you.
The fifth break is noise drowning signal. Automated location pings and routine checkpoints flood the feed until the one delay event that matters is the 400th row nobody reads. Exception events need a different path from routine ones: surfaced, timed, and owned.
What should you check in a 214 flow?
Five checks keep a status feed honest:
First, latency on exceptions: how long between a delay occurring and your system showing it — and is that gap measured and alarmed, or discovered by the customer?
Second, forward-only state: can a late, older event move a shipment's current state backwards, or is it filed to history without rewinding the present?
Third, matching: does every incoming 214 resolve to the accepted tender and the right stop — and what happens to the ones that do not match? An unmatched-event queue that nobody owns is a silent blind spot.
Fourth, expected-event monitoring: for each load, do you know which event should arrive next and by when — so that silence raises an exception instead of reading as calm?
Fifth, signal separation: do delay and exception events reach a person or a workflow immediately, separately from routine checkpoint traffic?
A flow that runs those checks turns the 214 from a diary into an instrument: you learn what is wrong while there is still time to do something about it.
Frequently asked questions
Who sends the EDI 214 · Transportation Carrier Shipment Status Message?
The motor carrier (or its dispatch/telematics provider) sends it to the shipper, broker, or 3PL that tendered the load. It reports events on a shipment the carrier previously accepted.
What is the difference between the EDI 214 and the EDI 990 · Response to a Load Tender?
The 990 is a one-time decision before the trip — accept or decline the tender. The 214 is the stream of events during and after the trip: pickup, arrival, delay, and delivery. The 990 commits; the 214 narrates the commitment being kept.
Why do 214 status events arrive out of order?
Because events are generated in different places — driver apps, dispatch systems, telematics — and transmitted in batches or after connectivity gaps. The event's occurrence time, not its arrival time, sets its place in the story, and receiving systems should apply events forward-only.
What happens after the final 214 delivery event?
The carrier invoices with a 210 · Motor Carrier Freight Details and Invoice. The receiver audits that invoice against the accepted 204 · Motor Carrier Load Tender and the 214 record — accessorials for detention, for example, stand or fall on the arrival and departure times the 214 reported.
Is a missing 214 event a problem?
Yes, if the event was expected. A pickup confirmation that has not arrived by its window is an exception in its own right. Treating silence as "on track" is how a missed pickup is discovered at the delivery appointment instead of at the pickup.
A status that arrives after the decision it was meant to inform is not visibility — it is an archive. The 214 works when its events arrive in time, in order, attached to the right load, with silence itself treated as a signal. At SignalEDI, we treat the 214 as the live half of the freight chain — tender, answer, status, invoice — because freight disputes and freight saves are both decided by whose status was true while it still mattered. I'm Chris, founder of SignalEDI, and we build EDI that keeps those states honest for shippers, brokers, and the carriers hauling for them.
Top comments (0)