Setting Up EDI 214 Feeds for a New Carrier

What You Need Before You Start

Before you touch your TMS or EDI translator, get four things confirmed in writing from the carrier's EDI contact. Skipping this step is the single biggest reason new carrier onboarding drags from a two-week job into a six-week one.

• The carrier's EDI 214 implementation guide or companion guide, including their full AT7 status code list and reason code set. Every carrier has favorites and exceptions. TForce Freight, for instance, uses codes like J1 for "Delivered to Interline," which won't show up in a generic X12 reference.
• SCAC code, ISA/GS qualifiers, and the trading partner ID the carrier will use in production, confirmed by their EDI team, not guessed from a rate sheet.
• Admin access to your TMS or EDI translator to create a new trading partner profile, map segments, and set validation rules.
• A test environment or VAN sandbox mailbox for pre-production 214s, so you're not debugging against live freight.

You'll know you're ready to start when you can point to a written 214 spec, a confirmed SCAC, and a sandbox mailbox that both sides have tested connectivity to. If any of those three are missing, stop and get them before you map a single segment.

Step 1: Pull the Carrier's 214 Spec and Build a Status Code Crosswalk

The AT7 segment is where the real work happens, so start there. The AT7 segment is the core event-reporting component of the EDI 214, identifying the shipment milestone via AT701, an optional reason code AT702, and the event timestamp. Without a valid AT701 code, the segment carries no operational meaning at all.

Here's the catch: every carrier's AT701 code list looks slightly different. AT701 status codes commonly include X1 for pickup, D1 for delivered, X6 for delayed in transit, and NS for not yet picked up, but a rail or intermodal carrier will use a different subset, and some retailers' companion guides only accept 15 of the 46 published codes. Best Buy's spec, for example, requires either a combination of AT701 and AT702 or AT703 and AT704, but not both pairs, in every AT7 segment.

Build a crosswalk table before you configure anything. List every AT701 code the carrier says they'll send, next to your TMS's internal status buckets. A workable structure:

• Picked Up: X1 (Arrived at pick-up location), AF (Carrier Departed Pick-up Location with Shipment)
• In Transit: X4 (Arrived at Terminal Location), TR (Transit), B6 (Estimated to Arrive at Carrier Terminal)
• Exception: A9 (Shipment Damaged), A7 (Refused by Consignee), CA (Shipment Canceled)
• Delivered: D1 (Delivered), X5 (Arrived at delivery location loading dock)

Don't skip the reason code column. A reason code is required if AT701 is sent, and if no specific status reason code is needed the carrier should send NA. If a carrier's system sends a blank instead of "NA," your parser may reject the whole transaction, not just flag a warning.

Step 2: Create the Trading Partner Profile in Your TMS or EDI Translator

This is where you enter the SCAC, ISA/GS envelope qualifiers, and communication method (VAN, AS2, or SFTP) so your system knows how to authenticate and route messages from this specific carrier.

If you're going through a VAN, understand what you're paying for. Instead of connecting directly to each trading partner, both parties connect to a VAN, and once connected, every EDI document sent between them goes through the VAN before delivery to the recipient. That convenience isn't free. Setup and onboarding fees for a new trading partner typically run $500 to $2,500 for initial mapping, and some providers add ongoing per-partner charges on top. If you're onboarding your fifteenth carrier this year, ask your VAN for a volume rate before you sign off on another one-off setup fee.

Set the acknowledgment requirement while you're in the profile screen. For a shipper or broker TMS, you send an outbound 204 load tender plus a 997 or 999 acknowledgment for each document received, and ingest the 214 and 210, returning a 997 or 999 reporting the validation result. Don't treat the ack as optional boilerplate. A 999 Implementation Acknowledgment validates compliance against a specific implementation guide, going further than a 997 which only confirms structural parsing. During onboarding specifically, require 999s, not 997s. A clean 997 tells you the envelope parsed. It says nothing about whether the AT701 code the carrier sent is one your companion guide actually permits.

Step 3: Map Reference Segments So the 214 Attaches to the Right Shipment

A perfectly formatted 214 is useless if your TMS can't match it back to the load. That matching happens in the L11 segment.

The L11 reference segment carries L1101 as the reference ID, which might be a PO number, BOL number, or ship notice number, and L1102 as the qualifier code, such as PO for purchase order or BM for bill of lading. Multiple L11 segments can link the status back to all relevant documents, which is critical for automated matching in TMS and OMS systems that need to update order records when a 214 arrives.

Here's the trap most admins hit on their first new-carrier setup: assuming BOL numbers are globally unique. If your ERP generates BOLs from a sequence that resets annually, or if a 3PL reuses numbering across clients, you'll get false matches. Add a secondary qualifier, your internal load ID or shipment ID, to the L11 mapping so a collision doesn't silently overwrite the wrong shipment's status.

Also confirm the B10 segment lines up. B1001 is typically the reference identification, often the shipper's reference or BOL number, B1002 is the shipment identification number or carrier's PRO number, and B1003 is the SCAC code, with the PRO number acting as the primary key linking the 214 back to the original 204 load tender and any 210 invoices. If B10 and L11 disagree on which number is "the" BOL, your matching logic needs a tiebreaker rule, not a coin flip.

Step 4: Run Test Transactions Before Go-Live

Send and receive sample 214s through the VAN sandbox or test mailbox before anything touches production freight. Confirm three things: the AT701 code renders as the correct TMS milestone, the timestamp populates from AT705/AT706 rather than defaulting to the file's transmission time, and the location fields resolve from the MS1 segment rather than showing blank.

Ask the carrier to send you at least one sample covering each status in your crosswalk, including an exception code like A9 (damaged) or A7 (refused). It's easy to test the happy path and never see how your system handles a "Shipment Canceled" event until it happens on a real load in week two.

You'll know Step 4 worked when the 999 comes back clean and the rendered status in your dashboard matches what a human reading the raw AT7 segment would expect. If the AT701 code shows up as an unrecognized status or defaults to a generic "Unknown," go back to your crosswalk. You've missed a code the carrier actually uses in production, not just the ones listed in their spec's example section.

Step 5: Set Exception Rules and Sequence Checks

Codes will arrive out of order. Plan for it now, not after the first support ticket.

The most common failure mode in live 214 feeds is a status update arriving before the milestone that should have preceded it. Preventing "Delivered" events before pickup and ensuring lifecycle sequencing logic of Pickup, then In Transit, then Delivered are standard validation practices carriers and shippers are expected to maintain. In practice, carrier systems retransmit, queue, or batch events, and a "delivered" 214 can land in your inbox minutes before the "out for delivery" one due to lag on the carrier's side.

Don't let your TMS auto-overwrite a shipment's status the moment a later-sequence event arrives if an earlier expected milestone is missing. Instead:

1. Hold any 214 that reports a milestone more than one step ahead of the shipment's current recorded status.
2. Route it to a review queue instead of applying it automatically.
3. Require a super-user or ops lead to confirm before the record updates, especially for anything mapped to your "Delivered" or "Exception" buckets, since those trigger downstream billing and customer notifications.
4. Set a timer alert if no "Delivered" 214 arrives within a set window after the last "In Transit" update, so a stalled feed doesn't silently look like a shipment stuck at "Rest" for three days.

This is the same discipline you'd apply to any webhook backlog: never let an out-of-order event silently corrupt state.

Step 6: Cutover and Monitor the First 10 to 20 Loads

Go live in parallel, not cold turkey. For the first week, keep someone checking the carrier's own tracking portal against what your TMS shows for the same loads. This costs you an hour a day and saves you from finding out about a mapping gap from an angry customer instead of your own dashboard.

You'll know the new feed is working when three things line up: the dashboard status matches the carrier's portal within minutes of each event, nobody on your team is manually re-keying a status because the feed missed it, and your outbound 997/999 acknowledgment count matches the number of 214s you actually received. If that acknowledgment count doesn't match, you have documents failing silently upstream of your TMS, in the VAN or the translator, and no one downstream will notice until a shipment goes "missing" that was actually delivered on time.

Multi-carrier TMS platforms like Descartes, Transporeon, and MercuryGate handle a good chunk of this AT7-to-status crosswalk natively, so you're not hand-building every mapping table from scratch each time you add a carrier. Connectivity layers such as Cargoson take a similar approach for shippers running multiple carriers on different EDI maturity levels, which matters if half your carrier list is API-first and the other half is still sending fixed-width X12 through a VAN.

Quick Reference Checklist

• Confirm SCAC, ISA/GS qualifiers, and the carrier's written 214 spec with their EDI contact before touching your TMS.
• Build an AT701-to-internal-status crosswalk covering every code the carrier actually sends, not just the spec's examples.
• Create the trading partner profile with the correct communication method and require 999s during onboarding.
• Map L11 and B10 segments with a secondary load ID qualifier if BOL numbers aren't guaranteed unique.
• Test every status in your crosswalk in the sandbox, including at least one exception code.
• Build a review queue for out-of-sequence events instead of letting them auto-overwrite shipment status.
• Run parallel monitoring against the carrier's portal for the first 10 to 20 loads before calling it live.