B10
Beginning segment: the carrier’s reference number, the shipment identification number, and the carrier code.
A carrier’s status update on a shipment in transit: picked up, in transit, out for delivery, delivered. Carrier to shipper, and often on to the consignee. This page covers what the 214 is for, the segments you meet when you open one, the documents it travels with, where it tends to go wrong, and how it moves over AS2 into your systems on Files.com, which receives, parses, validates, and routes it as configuration.
No credit card required · 7-day free trial · Live in minutes
The 214 is how a trucking carrier reports where a shipment is. Each message carries the shipment and reference numbers, the status code and reason (picked up, departed, arrived at terminal, out for delivery, delivered, delayed), the date and time, and the location, along with equipment and stop details when they matter.
Shippers feed 214s into visibility platforms and customer notifications, and receivers use them to plan dock schedules. A carrier typically sends several 214s per shipment as it moves, so the document is high-volume and time-sensitive in a way most EDI is not.
In document order, the segments that carry the 214's meaning. A partner's implementation guide says which are required and which fields each must hold.
Beginning segment: the carrier’s reference number, the shipment identification number, and the carrier code.
Business instructions and reference numbers, such as the bill of lading or PO.
Parties: shipper, consignee, and bill-to.
Shipment status details: the status code, the reason code, and the date and time of the event.
Equipment, shipment, or real-property location: city, state, and country of the event.
Equipment identification: the trailer or container.
Time zones and event ordering. A 214 stream from several carriers mixes local times, and a status that arrives out of sequence (delivered before out-for-delivery) confuses a naive consumer. Status and reason codes also vary in how strictly carriers use them, so a mapping that treats every code as canonical shows odd states.
The 214 rarely moves alone. These are the documents that precede, answer, or settle it.
Travels with this document in the same exchange.
A carrier’s acceptance or decline of a shipper’s request to move a load.
See The 990A trucking carrier’s invoice for a shipment, with the freight details the charges are based on.
See The 210The advance ship notice: what is in the shipment, how it is packed, and how it is labeled, sent before it arrives.
See The 856A partner sends the 214 over AS2, SFTP, or FTPS, and it lands in that partner’s inbox folder on Files.com with the transport receipt recorded. From there it is a workflow, not a project: TransformScript parses the X12 natively into the JSON, CSV, or XML your ERP or WMS reads, content validation flags a document whose contents are wrong before anything ingests it, and an automation routes the result to the system and the people who act on it.
Outbound is the mirror image. Your system exports its record, TransformScript builds the 214 the partner’s guide specifies, and the file dropped in the partner’s outbox goes out over AS2 with automatic retries until the MDN confirms delivery. Every transmission in both directions is in the audit log, and delivery monitoring alerts when a 214 that was due never arrives. The full picture is on the EDI software page.
What teams ask about the 214 and how it moves on Files.com.
An EDI 214 is the X12 Transportation Carrier Shipment Status Message. A carrier sends it to report a shipment’s status events, such as picked up, in transit, out for delivery, and delivered, with the date, time, and location of each.
The carrier sends it to the shipper, who may forward it, or the visibility data derived from it, to the consignee and to customers.
The 204 Motor Carrier Load Tender is the shipper’s request for the carrier to move a load; the 990 is the carrier’s acceptance; the 214 reports status while the load moves; the 210 is the carrier’s invoice afterward.
Yes. Files.com is a standards-compliant RFC 4130 AS2 endpoint, and a 214 sent by a trading partner lands in that partner’s inbox folder with a signed MDN receipt returned to the sender. Partners who exchange over SFTP or FTPS connect to the same platform and the document lands in the same place.
Yes. TransformScript parses the X12 214 natively and writes the JSON, CSV, or XML your systems ingest, as a step in the workflow that fires when the document arrives. Outbound, the same engine builds a 214 from your system’s export and drops it in the partner’s outbox for delivery.
Start the 7-day trial, turn AS2 on, and exchange certificates with your partner. The 214 lands in their folder, parses into the record your system reads, and every transmission carries a signed receipt.
No credit card required • Free for 7 days • Live in minutes