How to Send an EDI 204 Load Tender to a Carrier

If you've only worked with the EDI 990, 210, or 211 so far, the 204 is the document that kicks off the whole chain. This walkthrough shows you exactly how to build an EDI 204 load tender, populate the segments a carrier actually expects, send it over AS2, and confirm the load was accepted before you move on to dispatch. By the end you'll know how to send an EDI 204 that a carrier's EDI desk won't bounce back to you on day one.

What an EDI 204 actually does in the tender workflow

The EDI 204 is the document a shipper, broker, or 3PL sends to offer a specific truckload shipment to a carrier. An EDI 204 is the Motor Carrier Load Tender transaction defined by the ASC X12 standards body, used by a shipper, broker, or 3PL to offer a specific shipment to a motor carrier for transport. It is the opening document of the freight transaction, the way a load is formally tendered. Nothing moves until this transaction goes out.

It sits at the front of a predictable chain. The EDI 204 Motor Carrier Load Tender is followed by the 990 Response to a Load Tender where the carrier accepts or declines, then the 214 Shipment Status Message as the load moves, and finally the 210 Motor Carrier Freight Invoice once the move is complete. If you've read our earlier posts on the 990, 210, and 211, this is the transaction that makes all three of those possible. Get the 204 wrong and every downstream document inherits the problem.

What you need before you start

You need four things in place before you build your first tender for a new carrier, and skipping any of them is the fastest way to spend an afternoon debugging a rejected interchange.

• The carrier's own EDI implementation guide. SCAC-specific variations are real: CN's 204 guide expects a respond-by G62 date and an AT5 segment for temperature control, while R+L Carriers' spec adds an MS3 interline segment and N7A for accessorial equipment that CN doesn't use the same way.
• A signed trading partner agreement with the carrier covering AS2 connection details: your AS2 ID, the carrier's AS2 ID, their receiving URL, and certificate exchange for signing and encryption.
• A TMS or EDI translator that can generate X12 004010 (or 5010) 204 output. Most shippers run this through a TMS like MercuryGate, Oracle TMS, SAP TM, or Cargoson rather than hand-building flat files, and if you're tendering to more than a handful of carriers, a multi-carrier connectivity layer is what keeps 50 carrier-specific 204 variants from turning into 50 separate mapping projects.
• A UAT or certification environment with the carrier. Most require at least one test round before they'll accept production tenders.

Building the EDI 204, segment by segment

Here's the build order that matches how every implementation guide we checked (CN, ArcBest, R+L) lays out the transaction. Follow this sequence and you'll have a syntactically clean 204 before you touch AS2.

1. Populate the ISA/GS envelope. Your AS2 ID goes in ISA06/GS02, the carrier's receiver ID in ISA08/GS03. CN's own sample interchange reads ISA*00* *00*KNSX *01*GENERIC *02*CNBH *250116*0911*U*00401*000014741*1*P*>, with the functional group identifier set to SM for Motor Carrier Load Tender.
2. Open the transaction with ST*204. ST01 is always "204"; ST02 is a control number you assign and must match the SE trailer at the end. CN's example shows ST*204*001 as the opening of the transaction.
3. Fill the B2 segment. This carries the SCAC, shipment ID, and payment method. ArcBest's spec lists the required elements as B2 02 Standard Carrier Alpha Code, 04 Shipment Identification Number, and 06 Shipment Method of Payment, and CN's sample populates it as B2**CNBH**ShipmentID*L*PP.
4. Set B2A to flag original, cancellation, or change. B2A01 carries "00" for an original tender. B2A02 tells the carrier what kind of move this is; LT means Load Tender - Truckload (TL) Carrier Only, while PC covers a Partial Load Tender, Carrier Consolidate. A full truckload original tender reads B2A*00*LT.
5. Add L11 reference numbers. Use this loop for your PO, BOL, or internal load number. CN's example ties a purchase order reference directly to a stop: L11*666666*PO.
6. Add N1 and N7 loops for parties and equipment. N1 carries shipper, consignee, and bill-to detail; CN's guide specifies N1 Name for OB, BT and/or SH, with N7 Requested Equipment Details following to specify trailer type and any temperature requirements.
7. Build the S5 stop-off loop with G62 dates at each stop. This is where sequencing matters most. CN's sample shows the pattern clearly: S5*1*CL, followed by G62*10*20250107 for the pickup date, then S5*2*CU with G62*68*20250112 for the delivery appointment. Get the stop sequence number in S501 wrong and the carrier's TMS will sequence the route incorrectly.
8. Add commodity and weight detail with L5 and AT8. Depending on whether you're using order-level detail, these segments live in different loops. If sending order level detail within the 0350 loop, use L5 and AT8 segments in loop 0360 to relay commodity detail; otherwise use them within the 0320 loop. R+L's guide also expects an AT5 Bill of Lading Handling Requirements segment for anything needing special handling instructions.
9. Close with SE and verify the segment count. SE01 must equal the exact number of segments between ST and SE, inclusive. A mismatch here is one of the most common causes of a 997 syntax rejection, so count before you transmit, not after.

How the carriers in this guide handle the same transaction differently

Transmitting over AS2 and confirming the carrier accepted it

Sending the file is the easy part. Confirming the carrier actually processed it is where most teams get sloppy. You're looking for three separate confirmations, in order, and skipping any of them means you're flying blind on a load that's supposed to move today.

• The AS2 MDN. A signed Message Disposition Notification confirms the carrier's AS2 server received the file intact. No MDN, or a negative MDN, means the transmission failed at the transport layer, before the carrier's translator even looked at the content.
• The 997 or 999 functional acknowledgment. This confirms the X12 syntax is valid, segment counts match, and the carrier's translator could parse the transaction. This is separate from whether they accept the load, it only confirms the envelope and structure were clean.
• The EDI 990 Response to a Load Tender. The EDI 990 is how the carrier accepts or rejects the shipment. This is the document that actually tells you whether the load is covered. Check the trading partner agreement for the carrier's expected response window, and if a 990 hasn't arrived by that deadline, don't assume acceptance. Follow up.

Using "Must Respond By" G62 segments in your original tender is a straightforward way to set the carrier's clock and avoid ambiguity on when a response is due. Build that into your heading-level G62 from the start rather than relying on a verbal SLA nobody can point back to.

When the 990 doesn't come back, or the carrier rejects

Two failure modes account for most of the stuck tenders we see. The first is a SCAC mismatch: the code you put in B2 doesn't match what the carrier has on file for that trading partner connection, often because the carrier onboarded you under a slightly different ID than the SCAC the motor carrier actually uses day to day. The NMFTA assigns the SCAC codes that identify the carrier a load is tendered to, and a typo or stale code here is enough to make the carrier's system silently drop the inbound file instead of acknowledging it.

The second is a duplicate or out-of-sequence ISA/GS control number. If your translator reuses a control number from a prior interchange, or two tenders go out with the same ST02 control number, the carrier's translator will generate a 997 rejection rather than a 990, and the rejection usually references the segment or control number that failed, not the business content.

When either happens: pull the carrier's EDI help desk log for the interchange control number and timestamp, correct the control number or SCAC, resend, and confirm the MDN and 997 both come back clean before you re-check for the 990. Escalating to a phone or email tender should be the last resort, not the first move, because it breaks the audit trail you need for the eventual 210 invoice reconciliation.

Where this fits in a mixed EDI and API carrier stack

Classic X12 204/990 isn't going away, and plenty of carriers still expect it exactly as described above. The practical problem is that maintaining a separate 204 mapping for every carrier variant, on top of newer REST APIs that some regional carriers now expose, gets expensive fast once you're past a few dozen trading partners. A multi-carrier API provider builds all the carrier connections, whether modern APIs, older EDIFACT-based EDI, or email integrations, and exposes them through one standardized interface, so instead of implementing and maintaining separate carrier connections you implement one standard and trigger all your transport orders through it. Platforms built for this, including Cargoson, PartnerLinq, and Descartes, exist specifically so your EDI team isn't rebuilding the same 204 logic for every new carrier onboarding.

Quick reference checklist

• ISA/GS envelope with correct sender/receiver AS2 IDs
• ST*204 with a unique control number matching SE
• B2 populated with SCAC, shipment ID, payment method
• B2A set to 00/LT for an original truckload tender
• L11 references for PO, BOL, load number
• N1/N7 loops for shipper, consignee, and equipment
• S5/G62 stop sequence correctly ordered with dates
• L5/AT8 commodity and weight detail in the correct loop
• SE segment count verified before transmission
• AS2 MDN received, 997/999 clean, 990 confirming acceptance

Run your first tender through a UAT cycle with the carrier before you push it live, even if your translator validates the syntax without complaint. The carrier's parser is the only thing that confirms whether your segments actually match their expectations, and that's a cheaper lesson to learn in test than on a load that's due at the dock in four hours.