EDI 204/990 Tender Setup: Auto-Accept Rules That Work

Before You Start

You need four things in place before you touch a single business rule: an active trading partner agreement (or VAN/AS2 connection) with each carrier, your assigned SCAC code, a TMS or middleware that can parse X12 204 and generate 990, and a routing guide listing primary and backup carriers per lane. Skip any one of these and your EDI 204 990 TMS configuration will fail in testing, not in production, which is the better place for it to fail.

Here's the detail people gloss over: a SCAC (Standard Carrier Alpha Code) is a unique 2-to-4 letter identifier assigned by the National Motor Freight Traffic Association, and shippers use SCAC codes in EDI 204 tenders to identify the carrier being tendered the load, with carriers required to include their SCAC in the 990 response and subsequent status updates. Without a valid SCAC, your system cannot route the tender or track the shipment. If your SCAC mapping table has a typo or a stale entry for a carrier that merged or rebranded, the tender either bounces or lands on the wrong dispatch desk. Confirm every SCAC against your routing guide before you build a single acceptance rule on top of it.

Configuring Tender Intake and Auto-Response, Step by Step

This is the core build. Do these seven steps in order, in a sandbox environment, before you touch live traffic.

1. Map inbound 204 segments to TMS shipment fields. The common segments in a 204 include the ST Transaction Set Header, B2 Shipment Identification, B2A Transaction Purpose, L11 Reference Numbers, G62 Date/Time, and N1/N3/N4 party identification. These elements include shipment identifiers, pickup and delivery locations, scheduling windows, equipment requirements, carrier identifiers, reference numbers, commodity descriptions, and special handling instructions, all of which carriers need to evaluate whether they can accept the load. Stop-offs live in repeating S5 loops, each carrying its own G62 date/time and location. Map every field your TMS needs to build a shipment record automatically; anything unmapped becomes a manual data-entry task later.
2. Build the lane/carrier acceptance matrix. This is the logic layer that decides auto-accept versus manual queue. At minimum it should score rate, equipment type match, and current capacity against each lane's assigned carrier tier. If you run backup carriers per lane, this matrix is also where the failover sequence gets defined, not bolted on afterward.
3. Set the respond-by SLA timer to mirror the carrier's actual window. The response time for EDI 990 sent within the EDI 204 is specified as "Must Respond By Date" and "Must Respond By Time," and if the EDI 990 is not received by the indicated time, the load may be reassigned to another carrier. That window isn't standardized. Response time requirements are defined by each trading partner's business rules, not by the X12 standard itself, and common response windows range from 15 minutes to several hours depending on the shipper. Amazon is a useful benchmark here: Amazon.com requires that EDI 990 accepting the load request be generated within 90 minutes after Amazon sends the 204 transaction. Set your own timer to the actual contracted window per carrier, not a company-wide default, or you'll be triggering false failovers on partners who legitimately have longer windows.
4. Configure the 990 outbound template with accept, decline, and conditional-acceptance codes. The 990 includes an acceptance or rejection code, and carriers can accept the load as tendered, accept with modifications, or decline. If you're the shipper receiving 990s from carriers, build parsing rules for all three outcomes, not just accept/decline. A conditional acceptance that gets silently treated as a straight accept is how you end up with a truck at the dock that can't actually carry the freight.
5. Wire the re-tender and failover rule. A decline or an SLA miss should auto-route the tender to the next carrier in your routing guide without a human touching it. If a load is rejected, or if the response to a load tender isn't received by the "Must Respond Date" and "Must Respond Time," the load is typically reassigned by the shipper to another carrier. Build this as a queue, not a single retry: primary declines, tender goes to backup one, backup one misses SLA, tender goes to backup two, and so on until you hit a manual-review threshold (most shippers cap this at two or three hops before a human gets paged).
6. Turn on 997/999 functional acknowledgment checks. After a 990 transaction is sent, the shipper responds with an EDI 997 functional acknowledgement confirming the 990 was received successfully. Without this check, a 990 that got lost in transit due to a VAN hiccup looks identical to a carrier that never responded. Alert on a missing 997 within 5-10 minutes of transmission, separate from your respond-by SLA timer.
7. Run a test cycle with one low-volume trading partner. Pick a carrier that handles maybe two or three loads a week, not your top lane. Send test 204s, confirm 990s fire back correctly, and watch the failover logic trigger intentionally (decline a test tender on purpose) before you flip the switch company-wide.

How You Know It Worked

Three checks confirm the setup is live and correct. First, test 204s should land in the TMS with the right stop sequence and equipment fields populated, no manual correction needed. Second, the 990 should fire back inside the SLA window with the correct accept, decline, or conditional code, matched by Load ID back to the original tender. Third, once a load is accepted, the carrier sends an EDI 214 Shipment Status Report to provide delivery-related information on that same load ID. If 214s start flowing correctly and match up to accepted 990s, your intake-to-execution chain is closed.

Failure Mode: Missed Respond-By Time and Wrong SCAC

Two failure modes account for most tender headaches. The first is a missed respond-by deadline. 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. If your SLA alerting only fires after the deadline has already passed, you're not preventing the miss, you're just documenting it. Build a near-miss alert at 75% of the SLA window (for a 60-minute window, that's a warning at 45 minutes) so a dispatcher can react before the load auto-reassigns. This matters more when carrier capacity is already tight; you don't want a slow response costing you a load you actually had the truck for.

The second failure mode is a wrong or stale SCAC. Time is of the essence for shippers, as many expect prompt responses to the EDI 204 within a certain timeframe, underscoring the importance of timely replies to maintain healthy trading partner relationships. When a SCAC is wrong, the tender either fails EDI validation outright or, worse, routes silently to a carrier who never should have seen it. The fix isn't a free-text field. Maintain SCAC as a lookup table tied to your carrier master record, validated against NMFTA's registry, and require a change-control step (not a one-off edit) any time a carrier's SCAC changes due to merger or rebrand.

Metrics to Track Post-Launch

Once the rules are live, four numbers tell you whether the configuration is actually working:

• Tender acceptance rate by carrier and lane
• Average 990 response time against the contracted SLA window
• Re-tender rate (how often a tender needs a second or third hop before acceptance)
• Percentage of tenders auto-accepted versus routed to manual review

A simple dashboard query pattern: join the 204 tender timestamp to the matching 990 response timestamp on Load ID, calculate the delta in minutes, and bucket by carrier and lane. Flag anything over 80% of the SLA window in a different color. If your re-tender rate climbs above single digits on a given lane, that's a sign your acceptance matrix is scoring that lane wrong, not a carrier problem.

Where This Fits in Your Broader Multi-Carrier Stack

The 204/990 cycle is the plumbing underneath most shipper TMS platforms, whether you're running MercuryGate, Descartes, Transporeon, or Alpega. If you're layering multi-carrier connectivity on top of your core TMS, tools like Cargoson, ShippyPro, and Shipmondo handle both EDI-based tendering and API-based carrier integrations, which matters if your routing guide mixes EDI-native LTL and truckload carriers with parcel carriers that only speak API. Whichever stack you run, the underlying logic in this guide (SLA timers, acceptance matrix, failover queue) transfers directly.

Peak Season Note

This is not a theoretical exercise right now. UPS surcharges start September 27, 2026 and FedEx starts September 28, 2026, both beginning with handling and size charges, and UPS surcharges end January 16, 2027, with FedEx and USPS ending January 17, 2027. That's a longer, earlier peak window than shippers have dealt with in prior years, and it means carrier capacity gets tight sooner. A tender that would have been accepted in August might get declined in November because the carrier's network is stretched. If your auto-accept and re-tender failover rules aren't tested and stable before Black Friday, you'll be diagnosing tender timeouts manually during the exact weeks you have the least slack to do it. Run your test cycle now, not in October.