The status lives in one segment, AT7, and three separate code lists that people routinely confuse. Here is what each one is for.
Key takeaways
An EDI 214 is the message a carrier sends to a shipper, consignee or broker to report where a shipment is. X12 defines the 214 Transportation Carrier Shipment Status Message as being used “by a transportation carrier to provide shippers, consignees, and their agents with the status of shipments in terms of dates, times, locations, route, identifying numbers, and conveyance”. The status itself lives in one segment, and that is the part shippers write their specifications around.
The segment is AT7. Published X12 reference documentation describes AT7 as specifying the status of a shipment, the reason for that status, the date and time of the status and the date and time of any appointments scheduled — carrying a two-character shipment status code, an optional reason code, an appointment status code, and a date and time.
Almost every “which codes do we need?” conversation is really about three separate lists, and people mix them up:
The reference also notes the structural rule that trips up first implementations: only one of AT7-01 or AT7-03 may be present, and the date and time in AT7-05 and AT7-06 mean different things depending on which one it is — the moment the status occurred, or a date related to an appointment.
Out of the 72 values in element 1650, a domestic truckload lane usually runs on a dozen. These are the published X12 codes and descriptions, taken from the element 1650 code list:
Cross-border and intermodal work adds a second cluster: K1 Arrived at Customs, K2 Customs Released, I1 In-Gate and OA Out-Gate. If you run drayage, those four are the ones your customer will chase, and scheduling drayage around terminal windows explains why they move on someone else’s clock.
One warning about the list. It is a standard, not a contract. Every shipper publishes an implementation guide naming the subset it requires, the timing it expects and the reference numbers it wants echoed back. Send codes it did not ask for and they are ignored; miss one it did and you fail the scorecard.
The quality of a 214 programme is decided by the source of its events, not by the mapping. Three sources, in descending order of reliability:
Automating the first two and reserving the third for exceptions is the whole design. It is also what makes the data usable for something other than the shipper’s scorecard — the same arrival and departure timestamps are the evidence in a detention claim, which is the argument in how to prove detention time to a shipper.
Most specifications set a window — a status must be transmitted within so many minutes of the event. That is negotiable. What is not negotiable is the border. In the highway mode the CBSA requires advance commercial information at least one hour prior to arrival at a port of entry, and it warns that once pre-arrival data has been sent, changes do not restart the clock — only cancelling and re-submitting a transmission restarts it. A K1 or K2 status in your 214 stream is a report of that process, not a substitute for it.
Worked example: five milestones, one honest failure
A Manitoba carrier onboarding with a national retailer was given a specification requiring five events — arrived at pickup, loaded, departed, arrived at delivery, unloaded — plus SD Shipment Delayed with a reason code whenever an appointment would be missed, each transmitted within thirty minutes.
Four of the five were derived automatically: two geofence arrivals, one geofence departure, and a driver tap for loading complete. The fifth, unloaded, was left with the driver because the yard geofence could not distinguish a completed unload from a truck still in the dock.
The delay code was the hard one. The carrier deliberately did not automate it. A delay event carries a reason that the shipper reads as an explanation, and an automated guess — traffic, weather, previous stop — would have been a guess in writing. Instead the system flagged every load whose projected arrival had slipped past its appointment window and put it in front of the dispatcher with the reason list ready. The transmission was automatic; the reason was a person’s.
As few as the customer will accept, sourced as automatically as possible. Every additional code is another thing that can be late or wrong, and a scorecard penalises lateness on codes you volunteered exactly as hard as on codes you were required to send.
The status says what happened; the reason says why. In AT7 the reason element is conditional on a status code being present, so a reason without a status is not valid.
Not usefully. The device produces position and duty-status data; the transaction set needs shipment identifiers, stop sequence and reference numbers that live in your dispatch system. The integration belongs between the two — see dispatch software for trucking companies.
No. It is a status report. Proof of delivery is the signed document, and how that document is captured and stored is a separate workflow — automating bill of lading and proof of delivery processing deals with it.
We will map your required codes to sources you already own and show you the exception queue.
