Implementers: 5 EDI 214 Segments to Capture and Map
Practical reference for EDI implementers: capture the five 214 segments, decode AT7 status codes, map shipment states into your TMS, and follow an...
Implementers: 5 EDI 214 Segments to Capture and Map
An EDI 214 is the ANSI X12 transportation carrier shipment status message: carriers send it to report event codes (AT7), dates, times and locations against a shipment. It carries the identifiers a receiving system needs to match the update to the right load, and its AT7 codes drive the practical outcomes that matter: real-time visibility, ETA recalculation, delivery confirmation and clean invoice reconciliation.
TL;DR:
- Most carrier shipment status updates are triggered at key points such as pickup, terminal arrival, ETA change, and final delivery, with exception events like refusals or cancellations occurring as needed.
- Properly matching shipment identifiers like the SCAC and waybill number is crucial for reliable data integration, with each AT7 event typically recorded separately for detailed tracking.
- Focus on common event codes like AF for pickup, X4 and AR for transit milestones, and D1 for delivery, while treating exception codes like A7 and CA as manual review triggers.
- Batch transmission frequency significantly impacts real-time visibility, with event-driven updates providing more accurate ETA and status information for operational decisions.
- Parsing and implementing 214 data effectively requires validating code lists, maintaining raw event histories, and ensuring idempotency to prevent duplicate records.
Table of Contents
What is the EDI 214 and when do carriers send it?
The 214 sits inside the ASC X12 EDI standard as the Transportation Carrier Shipment Status Message, built to report shipment events, dates, times, locations, routing and conveyance details back to whoever tendered the load. It’s the carrier’s half of a conversation that starts with a tender and ends with an invoice.
A carrier typically fires a 214 at several natural checkpoints in a shipment’s life:
- Pickup completed at origin
- Arrival at an intermediate terminal or rail ramp
- A change to the estimated delivery time
- Final delivery at destination
- An exception: refusal, damage, delay, cancellation
The 214 doesn’t operate alone. It completes a loop that usually starts with an EDI 204 load tender, where the shipper offers the load and the carrier accepts it. The 214 then reports what happens to that load in transit, and once delivery is confirmed, the cycle typically closes with a 210 invoice, which the 214’s delivery event helps validate. Skip the 214 and you’re left invoicing on trust rather than evidence.
Version matters more than most integrators expect. The segment set and even the meaning of certain qualifiers shift between X12 releases, and version 4010 remains widely referenced in carrier documentation, though 4020 and later versions add fields some trading partners require. Confirm the version in your partner’s implementation guide before you build a parser, not after it starts rejecting files.
Reading the 214: segments and fields worth capturing
Every 214 opens and closes with the standard X12 envelope: ISA (interchange), GS (functional group) and ST (transaction set header) at the top, with matching trailers at the bottom. These frame the message and identify sender and receiver, but the shipment detail lives inside.
- B10 is the anchor segment. It carries the shipment identifiers, waybill or pro number, and often a purchase order reference, and it’s the segment most receiving systems key their matching logic off first.
- N1/N3/N4 loops carry party and address information, shipper, consignee, or terminal details. Treat these as supplementary; the identifiers in B10 are more reliable for matching than freeform address text.
- LX/AT7 is the workhorse. The LX loop numbers each status event, and the AT7 segment carries the event code, reason code, date and time, which is why most parsing logic centres on this pair.
- AT8 adds weight and quantity data tied to the event, useful for reconciling what was picked up against what was tendered.
- MS1/MS2/MS3 segments (where present) carry routing, equipment and location detail, handy for intermodal or rail moves where the conveyance itself matters.
For matching and storage, index on the SCAC (Standard Carrier Alpha Code) plus the B10 reference numbers, with the PO as a secondary key. Store every AT7 line as its own event record rather than collapsing them, because a single shipment can generate a dozen or more status updates before it reaches its destination.
Decoding AT7 event codes: what they mean and how to act on them
The AT7 segment is where the actual status lives, and the field that matters most is Data Element 1650, the event code. Some AT701 values signal the shipment has been delivered, while others simply mark progress in transit, so your parsing logic needs to distinguish the two categories rather than treating every code as equivalent.
A handful of codes cover most real-world traffic:
| Code |
Meaning |
Typical trigger |
| AF |
Actual pickup |
Driver collects the load at origin |
| AB |
Appointment scheduled |
Delivery or pickup appointment set |
| X4 |
Arrived at terminal |
Load reaches a cross-dock or ramp |
| AR |
Arrived at destination |
Truck reaches the final delivery point |
| D1 |
Delivered |
Load handed off, POD typically follows |
| AG |
Estimated delivery |
ETA update, no physical event yet |
| I1 |
In-gate (intermodal) |
Container enters a rail or port facility |
| A7 |
Refused by consignee |
Delivery attempted but rejected |
| CA |
Cancelled |
Shipment cancelled after tender |
| NS |
No status available |
Placeholder or data unavailable |
Build your state machine around three buckets rather than eleven separate branches:
- In-transit codes (AF, X4, AR, AB, AG) update location and ETA without closing the shipment.
- Terminal codes (D1) close the shipment and should trigger POD retrieval and invoicing workflows.
- Exception codes (A7, CA, NS) need a human in the loop, not an automatic state change.
Carriers occasionally send codes outside your accepted list, particularly during onboarding. Don’t fail the whole file. Log the unknown code, hold the shipment in its last known state, and raise an alert for manual review rather than silently dropping the event or guessing at its meaning.
Where 214 integrations actually break
Most 214 failures trace back to a handful of repeat offenders rather than exotic edge cases. Reference mismatches top the list: a carrier’s B10 or PO reference doesn’t match what was sent on the original 204 tender, often because of formatting differences like leading zeros or inconsistent SCAC codes. Weight and unit discrepancies, timezone handling, and inconsistent date formats across trading partners cause the rest.
Batching frequency is a quieter problem. A carrier that batches 214s once daily gives you accurate history but poor real-time visibility, while event-driven transmission, sent as each status changes, is what actually supports live ETA tracking. Push for event-driven sends wherever a partner’s system supports it.
A practical validation and testing sequence:
- Confirm the interchange and version qualifiers in ISA/GS match what your partner profile expects.
- Enforce required-field checks on B10, SCAC and at least one AT7 line before accepting a file.
- Maintain an accepted code list per carrier and flag anything outside it rather than rejecting outright.
- Exchange and verify 997 functional acknowledgements as part of onboarding, not as an afterthought.
- Simulate exception scenarios (refusal, cancellation, delayed ETA) before go-live, not after the first real one arrives.
Pro Tip: Ask new carriers for three or four sample 214 files covering pickup, in-transit and delivery before you write a single line of mapping code. Real files expose formatting quirks that specification documents never mention.
Mapping 214 events into your TMS, WMS or ERP
Store 214 events as an append-only log rather than overwriting a single shipment record. Deriving current status from the most recent event preserves the full history and makes reconciliation and dispute resolution far simpler than trying to reconstruct a timeline after the fact.
A workable mapping between AT7 codes and internal states looks like this:
- AF → “Picked up” (starts the in-transit clock)
- X4/AR → “In transit” with updated location
- AG → ETA field updates, schedule and receiving teams notified, no state change
- D1 → “Delivered”, triggers POD retrieval and closes the leg
- A7/CA → “Exception”, routed to a human queue rather than auto-closed
ETA updates deserve their own handling path. When an AG event lands, update the schedule and push a notification to receiving teams immediately, since a stale ETA is worse than no ETA at all for dock planning.
Guard against duplicates. Carriers occasionally resend the same event after a connection retry, so key your idempotency check on the combination of B10 reference, AT7 code and event timestamp before writing a new record. Keep raw event history for as long as your invoice dispute window requires, then archive rather than delete.
Author perspective: what actually matters when you scale this
Get the matching keys right before anything else. SCAC plus waybill or pro number will carry you through 90% of shipments; address parsing and freeform fields are enrichment, not foundation. I’d rather see a team accept a narrow set of event codes cleanly than try to handle every possible AT7 value on day one and choke on the exceptions. Expand coverage as each carrier proves stable, and use 214 events against the 210 invoice to settle disputes with evidence instead of phone calls.
— Vytautas
Getting 214 data into a system that actually uses it
Parsing a 214 correctly is only half the job. The harder problem is turning AT7 events into something your operations team acts on the same day, an ETA that updates a customer’s tracking link, a delivery event that releases a POD, a status change that flags a load ready to invoice. Logivo ingests EDI feeds including 214 status updates and maps them into shipment states your team already works from, alongside live driver tracking and POD capture that closes the loop when a D1 event lands.
Because this platform runs on usage-based pricing rather than a long contract, you can validate your own mapping rules against real carrier traffic during a guided 30-day trial before a single load is charged. If reconciling 214 events against invoices is the part costing you the most admin time, that’s the workflow worth testing first. Take a look at Logivo’s transport management platform and see how your own EDI feed behaves inside it.
Sources
FAQ
What do the EDI 214 reason codes mean?
Reason codes sit alongside the AT7 event code and explain why a status occurred, such as a delay cause or a refusal reason; exact code sets are usually defined per trading partner agreement rather than universally fixed.
What is an EDI 214 document?
It’s the ANSI X12 transportation carrier shipment status message, an electronic file carriers send to report events like pickup, transit progress, delivery or exceptions against a specific shipment.
What is the difference between EDI 204 and EDI 214?
The EDI 204 is the load tender a shipper sends to offer a shipment to a carrier; the 214 is the carrier’s response reporting what actually happens to that load once it’s moving.
What are all the EDI codes?
There’s no single universal list; AT7 event codes vary somewhat by carrier and industry segment, though common ones like AF (pickup), D1 (delivered) and CA (cancelled) appear across most implementations.
How does EDI 214 tracking connect to invoicing?
A delivery event (D1) on the 214 gives the receiver the evidence needed to validate the subsequent 210 invoice, which is why matching 214 history to invoices shortens billing disputes considerably.
Recommended