Automating the EDI 204, 990 and 214 Tender Cycle

The EDI 204/990/214 cycle sounds simple on a whiteboard: tender a load, get a response, track the shipment. In production, over AS2, with a real carrier on the other end, it's a different story. This walkthrough covers the exact segments, timing rules, and one failure scenario you'll hit eventually, so you can build this integration once and not have to rebuild it after your first missed tender.

What You Need Before You Start

You need an active AS2 connection (self-hosted or through a VAN), the carrier's AS2 ID and endpoint URL, exchanged encryption and signing certificates, and an agreed field layout for the 204. Without all four in place, don't bother building the mapping yet.

Specifically, line up:

• Your AS2 ID, URL, and certificate, plus the carrier's matching set (encryption certificate and, often, a separate signing certificate)
• Agreement on MDN type: synchronous or asynchronous, and which signing algorithm (SHA-256 is standard now, though older 3DES-based setups still show up)
• The partner's exact 204 field requirements, particularly the "Must Respond By" date/time and any required reference qualifiers (DO vs. CR)
• Confirmation of where transactions actually route: many shippers don't accept AS2 directly at all

That last point trips up more new integrations than certificate errors do. General Mills routes all EDI transactions through a VAN, Sterling Commerce, and requires partners to arrange for the 204 to be received from Sterling Commerce either directly or via interconnect from another VAN, with the 990, 214, and 210 sent back the same way. If you build a direct AS2 connection assuming point-to-point delivery and the partner actually expects VAN interconnect, your first test will fail for a routing reason that has nothing to do with your mapping.

Also worth confirming early: the 204 transaction set is built for shippers to offer a full truckload shipment to a motor carrier, including scheduling, equipment, and commodity details, and it is not meant to carry LTL bill-of-lading or pickup-notification data. If you're moving LTL freight, you're on a different document entirely.

Confirming AS2 and Segment Requirements With Your Partner

Before you write a single mapping rule, get the partner's connectivity questionnaire answered in writing, not implied. Most trading partner specs, General Mills included, ask upfront whether you're hosting AS2 in-house, which software you're using, and whether it's Drummond certified, plus request your production and test encryption certificates as zipped attachments.

On the 204 itself, the segments you're mapping are consistent across shippers even when field-level requirements differ: ST for the transaction header, B2 for shipment identification, B2A for transaction purpose, L11 for reference numbers, G62 for date/time, N1/N3/N4 for party identification, S5 for stop-off details, N7 for equipment information, and SE to close the transaction. Get the partner's specific usage notes for L11 qualifiers (load ID, PO, BOL) and G62 date qualifiers, because these vary by shipper even though the segment names don't.

If you're managing this manually across a growing carrier base, this is also the point where TMS and carrier-connectivity platforms earn their keep. Systems like MercuryGate, Descartes, Transporeon, and Cargoson handle AS2 setup and certificate exchange as part of standard carrier onboarding, which matters once you're past a handful of trading partners and into dozens.

Sending, Responding, and Closing the Loop

Here's the actual sequence, end to end, with the parts people get wrong.

1. Build and transmit the 204. Populate ST/B2/B2A/L11/G62/N1/S5/N7/SE with your load reference, pickup and delivery windows, equipment type, and commodity detail. Send it over your AS2 connection and confirm you get back a synchronous or asynchronous MDN, per what you agreed with the partner, and separately a 997 functional acknowledgment.
2. Set the "Must Respond By" field correctly. This isn't decorative. Some shippers, Amazon among them, require that the EDI 990 accepting a load request be generated within 90 minutes of the shipper sending the 204. Best Buy runs the same 90-minute clock for truckload and intermodal/rail carriers, with LTL carriers exempted from the 990 requirement entirely. Build your G62 "Must Respond By" logic to match whatever window your specific partner enforces, not a generic default.
3. Wait for the 990. The carrier can return one of five possible responses on the 990 for a given shipment offer, ranging from straight acceptance to decline, with conditional accept variants in between. If the shipment is accepted with conditions or declined outright, the transaction can also carry the reasons or the conditions attached to that response. Confirm receipt with a 997 the moment it lands, separate from parsing the B1 response code itself.
4. Handle a missed or late 990. This is your first real failure mode, covered in detail below.
5. Process inbound 214s. Once accepted, the carrier reports shipment progress through the 214. Six shipment statuses are typically required to communicate the stages of pickup and delivery: AA, X3, CP, AB, X1, and D1. In practice that breaks down as AA and AB for pickup and delivery appointment date/time, X3 and X1 for arrival at pickup and delivery locations, CP for completed loading at pickup, and D1 for completed unloading at delivery. Map these into your TMS or ERP as discrete milestone events, not a single "status" field, because reason codes and delay notices (SD) ride alongside them and need their own handling.
6. Close the loop with the 210. The carrier sends an EDI 210 Motor Carrier Freight Details and Invoice to the shipper or consignee to request payment for freight charges once delivery is confirmed. The 210 invoice is tied directly to the 214 shipment status data, and when detention or layover charges are billed, the 214 timestamps have to support what's being invoiced. If that 214 data isn't present, the invoice gets held for manual review or rejected outright. This is a strong argument for getting 214 timing accurate long before you worry about invoice reconciliation.
7. Run a staged test cycle before go-live. Don't test everything at once. General Mills tests documents in a fixed order and doesn't move partners to production until testing on all of them is complete: first the 204 load tender and 990 tender response, then the 214 shipment status including carrier-of-execution reporting, and finally the 210 freight invoice. Follow that sequence. A 210 that reconciles against broken 214 data will fail in a way that's much harder to debug than a 204 that never gets acknowledged.

How to Know It Worked

Success looks like this: 997s coming back for every 204, 990, 214, and 210 you send or receive; 990s landing inside the agreed response window (90 minutes for Amazon and Best Buy, tighter or looser depending on your partner); 214 status codes populating on schedule against the AA-X3-CP-AB-X1-D1 sequence; and MDN logs showing clean, positive delivery on every AS2 transmission. General Mills uses the 997 specifically to reconcile all outbound 204 transmissions, and recommends partners do the same for their outbound 990, 214, and 210 transmissions. Your AS2 provisioning, inbound, and outbound logs are the first place to look when something in that chain goes quiet.

Common Failure Mode: Missing or Negative MDN

You send the 204, wait for the MDN, and get nothing back, or you get a negative MDN with an error you don't recognize. This is usually one of three things.

First, a certificate mismatch. A signature verification failure typically indicates a certificate mismatch, where the correct certificate isn't configured on one side of the connection, often because a partner rotated their certificate and didn't tell you, or because encryption and signing certificates got swapped. Check both sides.

Second, a connection or firewall issue. A connection timeout usually points to a network issue or firewall configuration blocking the connection, so verify that the correct ports, typically 443 for HTTPS, are open and check the AS2 URL for typos.

Third, a mismatch in what was requested versus what was sent. A missing MDN commonly traces back to a misconfiguration in the MDN requesting or issuing mode, such as the sender not explicitly requesting an MDN, or requesting async when the receiver is set up for sync.

Fix sequence: verify certificate validity and expiration on both ends first, confirm AS2 IDs and MDN type match what's documented in the partner spec, then send a throwaway test file to a non-production AS2 endpoint before touching anything in your live 204 flow. Don't debug certificate and firewall issues simultaneously against production traffic. You'll lose track of which fix solved the problem.

Where TMS Platforms Simplify This

Maintaining 204/990/214 mapping, certificate rotation, and AS2 endpoints for one or two carriers is manageable by hand. Past a dozen carriers, each with its own response window, reference qualifier preferences, and certificate renewal schedule, it stops scaling.

For smaller shippers who don't need full 204/990/214 volume, parcel-focused tools like Shippo, EasyPost, or ShipStation solve a similar connectivity problem through APIs rather than AS2, without the truckload-specific transaction set.

Next Steps

Start with the connectivity handshake, not the mapping. Confirm routing (direct AS2 or VAN interconnect), exchange certificates, and agree on the 990 response window in writing before you send a single test 204. Then run the staged test sequence, tender first, status second, invoice last, and treat 990 response time as the one metric worth watching daily. It's the number your carrier scorecard tracks, and it's usually the first place a broken integration shows up.