5 Implementation Steps for EDI 204 Load Tender
A practical, implementation-first reference for EDI 204: five implementation steps, a raw 204 example, segment checklist, and mapping and testing notes...
5 Implementation Steps for EDI 204 Load Tender
The EDI 204 is the ANSI ASC X12 Motor Carrier Load Tender, the transaction a shipper, broker, or 3PL sends to formally offer a specific load to a carrier. It carries stops, weights, equipment needs, and appointment windows, and it expects an EDI 990 reply within a set window, followed downstream by EDI 214 status updates and an EDI 210 invoice. Logivo builds this lifecycle into its transport management platform so tenders, responses, and billing stay in sync automatically.
TL;DR:
- The EDI 204 load tender is ideal for dedicated truckload lanes and automated spot tendering but performs poorly with multiple unrelated LTL pickups.
- Accurate implementation requires following each carrier’s specific guidelines, particularly for stop counts and appointment window handling, to prevent rejections.
- Proper mapping of segments, especially the stop-off loop (S5) and date/time qualifiers (G62), is crucial for reliable transmission and response processing.
- Automating 204 workflows with platforms like Logivo reduces manual reconciliation, speeds onboarding, and improves invoicing accuracy.
- Key pitfalls include relying on the generic X12 standard rather than the carrier’s implementation guide, neglecting negative tests, and ignoring missed 990 responses.
Table of Contents
When should you use an EDI 204 load tender?
Shippers, freight brokers, and third-party logistics providers send 204s to tender truckload freight and structured multi-stop moves. The transaction assumes a defined, single load with a known carrier relationship on the other end, which is exactly why it works so well for contract lanes and dedicated capacity.
It works less well for classic LTL pickup manifests. YRC Freight’s implementation guide explicitly caps LTL usage at two stops, and forcing a multi-stop LTL pattern onto a 204 built for truckload logic tends to produce declined tenders or misrouted freight. Carriers built their 990 and 214 responses around truckload assumptions, and bending those assumptions rarely ends well.
Good candidates for a 204 tendering system include:
- Dedicated truckload lanes with recurring pickup and delivery pairs
- Contract tenders governed by a routing guide with sequenced carrier fallbacks
- Automated spot and route tendering where a TMS selects and offers loads without manual intervention
- Multi-stop truckload moves where sequencing and appointment windows matter to the carrier’s dispatch
If your freight profile is genuinely LTL with a pickup manifest and multiple unrelated shippers on one truck, check the carrier’s own IG before mapping a 204. Some carriers support it under specific conditions; most do not.
Required segments and elements in an EDI 204 document
Every EDI 204 document follows the same skeleton, but the specific elements a carrier enforces vary by their implementation guide. Here is what actually needs to be populated correctly.
- ST — Transaction set header; identifies this as a 204 and carries the control number.
- B2 — Beginning segment for the load tender; carries the shipment ID and standard carrier alpha code.
- B2A — Set purpose (original tender, cancellation, or change); carriers key their routing logic off this code.
- L11 — Reference numbers (PO, bill of lading, load ID); the primary matching key carriers use downstream.
- S5 — Stop-off details; one occurrence per stop, sequenced by stop number.
- N1/N3/N4 — Name, street address, and city/state/ZIP loops attached to each S5 stop.
- N7 — Equipment details (trailer type, length, weight capacity).
- G62 — Date/time qualifiers for pickup and delivery windows.
- AT8 — Weight, volume, and quantity totals for the shipment.
- L3 — Total weight and charges summary.
- PLD — Pallet or handling unit detail, where the carrier requires it.
The S5 loop is where multi-stop complexity lives. Each stop gets its own S5 occurrence with an attached N1/N3/N4 address block, so a five-stop milk run produces five sequenced S5 loops, not one segment with five addresses crammed in. Better EDI’s documentation on the stop-off loop is worth bookmarking if you are building multi-stop mapping logic from scratch.
Date and time handling causes more grief than anything else on this list. G62 qualifiers distinguish earliest pickup from latest delivery, and getting the qualifier code wrong is one of the most frequent causes of appointment-window failures implementers see in production.
Pro Tip: Build explicit negative test cases for G62. Test what happens when your earliest and latest pickup times collide, and when a dock close time falls before an appointment window opens. Carriers will reject silently before they reject loudly.
What does a raw EDI 204 look like in practice?
A stripped-down 204 for a two-stop truckload move looks like this:
| Segment |
Example content |
What it tells the carrier |
| ST |
ST204— |
Transaction type and control number |
| B2 |
B2PRPUSCAC*L |
Shipment purpose and carrier code |
| B2A |
B2A*— |
Original tender (new) |
| L11 |
L11LOADBM |
Load reference number |
| S5 |
S51LD |
Stop 1, load |
| N1 |
N1SHAcme Distribution |
Shipper name at stop 1 |
| G62 |
G62*—*— |
Requested pickup date |
| S5 |
S52UL |
Stop 2, unload |
| N1 |
N1CNRetail DC 4 |
Consignee name at stop 2 |
| G62 |
G62*—*— |
Delivery appointment date |
| L3 |
L3*— |
Total weight |
| SE |
SE*—*— |
Transaction trailer, segment count |
Before transmitting, verify the SE segment count matches the actual number of segments between ST and SE, and confirm the ST control number matches the SE trailer. Mismatched counts are a common rejection reason that has nothing to do with the freight data itself.
The 204 driven messaging workflow: 990, 214, 210, and matching rules
Sending the 204 is only step one. Once a carrier receives it, they reply with an EDI 990, which carries an accept or decline code and, on acceptance, confirms the SCAC and load reference back to the shipper. A decline code should trigger your next routing-guide carrier automatically rather than sitting in a queue for someone to notice.
From there:
- EDI 214 shipment status messages reference the original load number from the 204’s L11 segment, so your system can match a pickup or delivery event to the right tender without manual lookup.
- EDI 210 invoices arrive after delivery and should tie back to the same load reference, closing the loop from tender to payment.
- EDI 997 functional acknowledgements confirm receipt of each transaction at the EDI layer, separate from the business-level 990 response.
Most trading partner agreements specify a “must respond by” window for the 990, usually requiring a timely response for time-sensitive freight. Treat a missed window the same way you’d treat an explicit decline.
Building a reliable EDI 204 process: implementation and mapping notes
Every carrier’s implementation guide is the actual contract, not the generic X12 specification. The base standard tells you what a segment can contain; the carrier IG tells you what they will actually accept, which required fields they enforce, and which stop-count limits apply.
- Pull the carrier’s own IG first. Compare it against the X12 204 baseline and log every deviation in required fields, code lists, and stop limits.
- Build test cases beyond the happy path. Cover hazmat loads, multi-stop sequencing, accessorial charges, and appointment-window edge cases, plus deliberate negative tests that should be rejected.
- Map to a canonical internal load object. One internal schema for stops, equipment, weights, and references lets you generate a 204, an API call, or a CSV export from the same data without duplicating business logic.
- Build explicit error handling and re-tender rules. Define what happens automatically on a decline, a missed 990 window, or a malformed acknowledgement.
- Version your mappings per carrier. IGs change; a mapping that worked in 2025 can silently break after a carrier updates their guide.
Pro Tip: Keep a living crosswalk document per carrier and a lightweight replay harness that fires your standard test 204s into a carrier’s test mailbox. Onboarding a new carrier goes from weeks of back-and-forth to a few days once you can replay known-good and known-bad samples on demand.
How Logivo handles EDI 204 workflows without the manual overhead
Logivo automates the parts of this lifecycle that eat the most staff time: transmitting and receiving 204s and 990s, matching 214 status events back to the right load, and pushing delivery confirmations straight into invoicing.
- Automated 204 transmission and 990 matching against your routing guide
- 214 status events reconciled to load records without manual lookup
- Invoicing handoffs triggered on delivery confirmation, cutting billing delays
- Role-based access controls so EDI configuration stays limited to the right team members
- A guided one-month trial, so you can validate the automation against your own carrier mix before committing
What I’ve learned from watching EDI 204 integrations go wrong
The three mistakes I see repeated most often: teams map to the generic X12 spec instead of the carrier’s own IG, they skip negative testing on appointment windows until a real load gets rejected, and they treat the 990 as optional rather than building an automatic re-tender when it doesn’t arrive on time. Fix those three and most 204 headaches disappear before they start. Pull the carrier IG first, test the ugly cases deliberately, and never let a missed 990 sit unnoticed.
— Vytautas
Get Logivo running on your EDI 204 workflows
Manually reconciling 204s, chasing 990 responses, and matching 214 events to the right invoice eats hours every week that a dispatcher could spend on the phone with carriers instead. Logivo is built to take that reconciliation off your plate, automatically matching tender responses and status events so nothing sits in a spreadsheet waiting for someone to notice it.
Running the platform against your own carrier mix shows the difference quickly:
- Faster carrier onboarding, since new IGs get mapped against a canonical load schema rather than rebuilt from scratch
- Fewer rejected tenders, because status matching and appointment logic run automatically instead of manually
- Invoicing that fires on delivery confirmation, not on someone remembering to check a status feed
Logivo’s transport management platform includes a guided one-month trial, so you can test the automation against real loads before paying anything. Start the trial and see how many hours it saves your team in the first month.
Primary specs and carrier implementation guides worth bookmarking
Keep these close if you are building or validating 204 mappings:
Sources
FAQ
What is EDI 204 used for?
The EDI 204 formally tenders a specific load to a motor carrier, carrying stops, weights, equipment requirements, and appointment windows so the carrier can accept or decline it.
What is the difference between EDI 204 and EDI 214?
The 204 offers a load to a carrier before pickup; the EDI 214 reports shipment status after the carrier accepts, referencing the original load number from the 204.
The specification defines segments including ST, B2, B2A, L11, S5 stop loops with N1/N3/N4 addresses, N7 equipment details, G62 date/time qualifiers, AT8 totals, and L3 weight and charge summaries.
What is an EDI in freight?
EDI, or Electronic Data Interchange, is the structured exchange of business documents like load tenders, invoices, and status updates between shippers, carriers, and logistics platforms such as Logivo without manual re-entry.
Recommended