Do You Need an EDI 990 for Every EDI 204?

Yes, nearly every shipper's routing guide requires a carrier to send an EDI 990 for each EDI 204 it receives, within a defined response window. Shippers have specific requirements for the EDI 204 document and related workflow, and generally, carriers must send an EDI 990 for each EDI 204 within a defined time period. Miss that window and the shipper's system treats your silence as a decline.

What Happens If a Carrier Never Sends the 990?

The load gets re-tendered to the next carrier on the routing guide, and you lose the freight without ever formally rejecting it. The response time for EDI 990 sent within the EDI 204 is specified as "Must Respond By Date" and "Must Respond By Time." If the EDI 990 is not received by the indicated time in EDI 204, the load may be reassigned to another carrier.

This isn't a soft guideline buried in a trading partner agreement that nobody reads. If the load tender is rejected, the shipper will reassign and tender the load to a different carrier — and plenty of shippers build this logic directly into the G62 segment of the outbound 204, so the deadline travels with the tender itself. Some shippers go further. Unless agreed to beforehand, all loads tendered must be responded to with an EDI 990 indicating if the load tender is accepted or rejected, and the EDI 990 must be received by the "Must Respond By Date/Time" included in the EDI 204 header, or the load is subject to reassignment.

If you're running a TMS or dispatch system with auto-decline logic, this is the exact failure mode it's built to catch. A missed window doesn't just cost you the load. If it happens repeatedly, it shows up in your tender acceptance scorecard with that shipper, and that scorecard often determines whether you stay on the routing guide at all.

How Fast Does the 990 Actually Need to Come Back?

Most shippers expect a response in 30 minutes to 2 hours for time-sensitive truckload freight, though the exact window is set per trading partner. Shippers typically expect a 990 response within a specific timeframe, often 30 minutes to 2 hours, and failure to respond may result in the load being retendered to another carrier. That pattern holds across manufacturers using similar EDI 204 implementation guides, from Procter & Gamble to Nestlé to Southeastern Freight Lines.

SCAC identification is non-negotiable in this exchange. Shippers use SCAC codes in EDI 204 tenders to identify the carrier being tendered the load, and carriers must include their SCAC in the 990 response and subsequent status updates. Without a valid SCAC, the shipper's system cannot route the tender or track the shipment. If your 990 goes out with a mismatched or missing SCAC, it can fail validation entirely, which looks identical to a missed deadline from the shipper's side. Check that field first when a carrier swears they responded on time and the shipper's system shows nothing.

Can a Carrier Decline or Counter-Offer Instead of Accepting?

Yes. A carrier can accept, decline, or accept with modifications, and the 990's B1 segment carries that exact reservation action code. The EDI 990 is the ANSI X12 transaction set used by motor carriers to accept, decline, or conditionally accept a shipper's load tender. At the code level, this comes down to a single data element: the Reservation Action Code carries a value of 'A' for Reservation Accepted or 'E' for Reservation Declined, and the carrier must respond with either code depending on whether it intends to accept or reject the load tender.

Declining fast is just as valuable to the relationship as accepting fast. A load isn't booked until the carrier says yes, and the 990 includes an acceptance or rejection code — carriers can accept the load as tendered, accept with modifications, or decline. A shipper who gets a clean decline within ten minutes can re-tender immediately. A shipper who hears nothing until the truck fails to show up at the dock has a much bigger problem on their hands.

How Does the 990 Fit Into the Full 204-990-214-210 Lifecycle?

The four documents form a complete loop: the 204 offers the load, the 990 answers it, the 214 tracks it in motion, and the 210 bills for it once it's delivered. Rather than tendering loads by email and chasing status by phone, the parties exchange structured documents that each system can read the same way: a 204 to offer a load, a 990 to answer, a 214 to report status, and a 210 to invoice.

Laid out by direction from a carrier's point of view:

• EDI 204 (inbound): the shipper or broker offers a specific load with pickup/delivery windows, equipment type, and commodity details.
• EDI 990 (outbound): the carrier accepts, declines, or conditionally accepts the offer, tied to the deadline set in the 204.
• EDI 214 (outbound): the carrier reports pickup, in-transit, and delivery events as the load physically moves.
• EDI 210 (outbound): the carrier bills for the completed move, and this is where line items, accessorials, and the total due need to tie back to what was actually tendered and delivered.

The two documents that cause the most operational pain aren't the ones you'd expect. Two documents cause most of the trouble: the 990 is time-sensitive because tenders expire, and the 210 gets rejected when it doesn't match the original 204. If you've covered 214 exception codes or 210 invoice mismatches on this blog before, this is the piece that was missing in the middle.

Is the 990 Still Relevant Now That TMS Platforms Automate Tendering?

Yes, and arguably it matters more now than it did a decade ago, because modern tendering engines run on the accept/decline signal the 990 provides. Dispatch systems increasingly parse it automatically rather than requiring a human to open a VAN portal. One connectivity platform built specifically for EDI 204 tenders illustrates the pattern: a system can connect to a TMS or dispatch system and process incoming 204 tenders in real time, with capacity rules triggering an automatic 990 response without a dispatcher touching the file.

For shippers managing carrier mixes that span EDI-native FTL/LTL partners and API-only parcel or regional carriers, the practical challenge isn't the 990 transaction itself, it's keeping one coherent view when half your network speaks X12 and the other half speaks REST. Platforms like MercuryGate, Oracle Transportation Management, and Cargoson increasingly sit in that gap, translating EDI 990 responses into the same dashboard view as API-based carrier confirmations so dispatchers aren't juggling two different interfaces for the same decision.

What's the Difference Between a 990 and a 997 or 999 Acknowledgment?

The 997/999 confirms the EDI file arrived and parsed correctly. The 990 is the actual business answer: yes, no, or yes-with-changes. They solve different problems and you need both. EDI 997 is the traditional X12 functional acknowledgment used to confirm receipt and syntax validation of an EDI transaction set, and the most important point is that an EDI 997 does not confirm that the underlying business transaction was accepted.

Put plainly: EDI 997 is a technical acknowledgment that confirms an EDI transaction was received and successfully parsed, while the 990 says whether the carrier is actually taking the load. Some shippers layer both into the same exchange, sending a 997 against every 990 they receive to close the loop on both the transport and business layers. If your mapping only generates one of these and not the other, you've got a gap worth fixing before it shows up as a missed tender during an audit.

If you're building or auditing a 204/990 integration, start by pulling the specific trading partner's implementation guide rather than assuming X12 defaults apply. The "Must Respond By" field, the SCAC qualifier, and the accepted reservation action codes all vary enough between shippers that a mapping built for one routing guide will quietly fail against the next.