Does an EDI 850 Purchase Order Specify the Carrier?

Sometimes. The EDI 850 has an optional TD5 "Carrier Details" segment, which can carry a specific SCAC code, a routing sequence, or nothing more than a generic shipping method. On most retailer purchase orders, TD5 is a placeholder tied to a static routing guide, not a live carrier decision. The actual EDI 850 carrier routing gets finalized later, in a TMS or through a separate routing transaction, not in the PO itself.

What does the TD5 segment in an EDI 850 actually contain?

TD5 is defined in the X12 standard as "Carrier Details (Routing Sequence/Transit Time)," and its stated purpose is to specify the carrier and sequence of routing and provide transit time information. It sits in the header area of the transaction, usually optional, though some retailers make it required and allow up to twelve occurrences on a single PO, as seen in Home Depot's 850 implementation guide.

The elements inside TD5 matter more than the segment name suggests:

• TD501/TD502 identify a routing sequence code and the party responsible for defining it, used when specifying a routing sequence to be used for the shipment movement in lieu of specifying each carrier within the movement.
• TD503 carries the actual carrier or SCAC code when one is named.
• TD504 and later elements cover transportation method, routing description, and service level.

In practice, a lot of live TD5 data is closer to a shrug than an instruction. EDI2XML's own 850 walkthrough shows a TD5 segment where the segment is used to communicate the preferred shipping carrier or method, but the routing indicates shipping instructions with no specific details given, followed by a bare "CG" code meaning Ground Carrier, indicating ground transportation with no specific carrier or routing details provided. Compare that to a Tractor Supply DTC purchase order, where TD5 actually names a real carrier code (CNWY) alongside an LTL mode indicator. Same segment, wildly different amount of real information, depending entirely on what the trading partner bothered to populate.

Who actually decides which carrier ships the order, the PO or the TMS?

For FOB Origin shipments, the buyer's transportation network, not the PO, makes the real call, and that decision often arrives through a completely separate transaction. NEXCOM's supplier instructions are explicit about this: NEXCOM requires suppliers to obtain routing for all purchase orders regardless of FOB terms, and the ship-to addresses provided via the routing process supersede the addresses that appear on the purchase orders.

That routing process runs on the 753/754 pair, not the 850. The supplier transmits a 753 "ready to ship" request, and the buyer answers with EDI 754, sent by a buying organization or its logistics authority to provide authoritative routing direction, including carrier SCAC, equipment, pickup window, and special handling. NEXCOM's own TMS runs this on a fixed cadence: NEX TMS begins the automated process of planning eligible FOB Origin order releases every Tuesday and Friday at 01:05 ET, and truckload shipments are placed out for bid and awarded the same day with routing available by 5:00 PM ET that afternoon. None of that logic lives in the original 850's TD5 field. It can't, because the carrier assignment hasn't happened yet when the PO goes out.

This is exactly the gap that multi-carrier platforms are built to sit in. Cargoson, along with MercuryGate, Descartes, Transporeon, and Alpega, consumes the ship-to and requested-ship data coming off the 850 and runs actual carrier selection and rate comparison across a live carrier panel, instead of trusting a static TD5 value that may have been typed in months earlier by whoever built the trading partner's implementation guide.

What happens when the carrier on the 856 ASN doesn't match what was in the 850?

Nothing good. Retailers run a three-way match across the order, the shipment notice, and the invoice, and when the order, the ASN, and the invoice disagree, payment gets held or deducted. The 856 carries carrier information at the shipment level, and that data has to reflect what actually happened at the dock, not what the original PO assumed. As 3PLGuys puts it plainly, the fundamental rule is that ASN data must match the physical shipment exactly, and the fix for chargebacks on carrier or count mismatches is to generate the 856 from actual pick/pack scan events rather than estimates, which eliminates the most common failure mode where the ASN reflects what was supposed to ship, not what actually shipped.

If your ASN generation logic is still copying the TD5 carrier field forward from the 850 instead of pulling the confirmed carrier off the BOL or the TMS execution record, you're building a mismatch into every shipment where the routing guide default and the actual pickup carrier diverge.

Should carrier assignment live in the EDI layer or in a TMS?

Carrier selection belongs in the TMS. EDI is the compliance and audit trail, recording what was agreed and what was shipped, not the system making live rate and capacity decisions. The table below is the short version of why that split holds up operationally.

Keep TD5 populated even when a TMS is making the real decision. Retailer scorecards flag blank required segments regardless of whether the field is functionally used downstream.

Do small or mid-market suppliers need to fill out TD5 manually?

Rarely by hand. Most EDI platforms and VANs auto-populate TD5 from the buyer's implementation guide defaults or from carrier data already sitting in the connected TMS. The failure mode worth watching for is the opposite problem: over-customizing TD5 or TD3 to reflect your own internal routing preference instead of what the trading partner's guide specifies. That breaks compliance validation on the retailer side, even though the segment is technically well-formed EDI.

What should you check before go-live if TD5 data is involved?

Confirm three things before a new trading partner connection goes live. First, that any SCAC or carrier code populated in TD503 matches the buyer's approved carrier list, not just a valid code in general. Second, that routing sequence logic in TD501/TD502 follows the sequence the implementation guide expects, since some retailers use it to name a routing party rather than a carrier directly. Third, and most commonly missed, confirm the downstream 856 pulls its carrier and tracking data from actual shipment execution in the TMS or WMS, not from whatever was copied forward out of the original 850. That third check alone prevents most of the carrier-mismatch chargebacks that show up months after a connection has otherwise been running clean.