EDI Trucking Integration: What a Carrier Needs to Connect

EDI trucking integration means connecting your transportation management system to a trading partner so that load tenders, responses and status messages move as structured files instead of emails and phone calls. A shipper or broker offers you a load, your system reads it, and your answers and updates go back the same way. The format is the ANSI X12 standard, and the 204 Motor Carrier Load Tender is the document that starts most loads.

The hard part is rarely the file format. It is the plumbing between you and the partner, the proof that a file arrived, and what happens when a tender changes after you accepted it. This guide walks through those pieces in the order a carrier meets them, with a checklist you can use before you switch on the next partner.

What does EDI trucking integration actually connect?

It connects three things: the partner's system that creates the tender, a transport channel that carries the files, and your TMS that turns each file into a load. If any one of the three is wrong, the other two look fine. That is why integrations that "worked in testing" can fail quietly later.

The National Motor Freight Traffic Association describes the limit of the model plainly: data moves in batch cycles, not in real time, which means delays, blind spots and often disputes when information changes mid-shipment. It also says APIs complement EDI in most companies today. For a carrier the practical reading is simple. EDI is the language most large partners still require, so you need it to work well, even if you also add faster feeds later.

Which EDI messages does a carrier handle on one load?

One truckload usually touches four message types plus an acknowledgement. The table lists each one, who normally sends it and what it carries. Names and purposes come from the X12 and Stedi references linked in the sources.

The 990 response carries the accept or decline in its B1 segment, and the 214 uses the AT7 segment for the shipment status and MS1 for the location. Which of these a given partner wants is set in that partner's own guide, so a carrier with five partners often has five slightly different requirements for the same four messages.

How do AS2 and a VAN get the files to your partner?

Files travel by one of two routes. With a value-added network (VAN), both sides connect to a hosted intermediary. With a direct connection, the two companies talk to each other over the internet, usually using AS2. RFC 4130 defines AS2 as business data exchanged over HTTP with S/MIME security, and it returns a receipt called a message disposition notification (MDN).

A vendor that sells direct EDI software, CData, says VANs typically charge minimal setup costs and then fees per document, while direct connections cost more to set up and are cheaper at high volume. It is a vendor view, so check it against your own volume. For a small carrier the more useful question is who owns the work. A VAN or managed service handles the partner set-up, and a direct connection puts certificates, test files and monitoring on someone you employ or pay.

Why is "sent" not the same as "delivered" in EDI trucking integration?

A send log records that your system handed the file to the transfer service. It does not record that the partner received it. In AS2 the proof is the signed receipt: RFC 4130 describes the MDN as the recipient's receipt, and a signed one carries a hash of the content so the sender can check that what arrived matches what was sent.

This matters because a failure can be total and silent. When a large broker rotated its AS2 security certificate, hundreds of status messages failed to deliver in carrier data we have looked at while the send log still said "sent". The only real proof of delivery was the partner's receipt or a 997 acknowledgement, which is the lesson in this Hemut anonymized carrier data point. The dashboard looked healthy for as long as nobody compared sent counts with receipt counts. See also the 997 definition for what an acknowledgement does and does not prove.

What does a 997 prove, and what does it not?

The 997 Functional Acknowledgment reports the result of a syntax check: accepted, accepted with errors, or rejected. The standard says it does not cover the meaning of the information, so a 997 shows that the data is structurally valid, not that the receiver agrees with it or will act on it. A tender you can parse can still be one your dispatcher must question.

It also only helps if it is switched on. We saw a carrier send roughly 2,500 EDI status messages in two weeks to a shipper's platform with acknowledgements turned off, so neither side could confirm what was actually accepted. That is Hemut anonymized carrier data again, and the fix is a setting, not a project. Ask each partner to enable the 997 and then read the returned acknowledgements, not just the outbound count. The 997 reference shows the accepted and rejected codes to watch for.

Does the shipper see the status you send?

Not always. A shipper may score carriers in a different tool from the platform that receives your files. In one case a carrier's EDI feed flowed perfectly to one platform while the shipper's actual tracking tool saw nothing, which is another Hemut anonymized carrier data point. Ask the partner in writing which system produces the on-time score you are measured on, and confirm your status messages reach it, not only the front door.

A short test settles it. Send one 214 status message with a known time and location, then ask the partner to show you where it appears in the screen they actually use. If it does not appear, the fix lives in their forwarding step, and no change on your side will help.

How do tender changes and cancellations arrive?

A tender can change after you accepted it, and the 204 says so in a field. The B2A segment carries a transaction set purpose code in its first element, and the code list for element 353 defines 00 as Original, 01 as Cancellation, 04 as Change and 05 as Replace. Your integration has to read that code and apply it to the right load. A change handled as a new load creates a duplicate, and a cancellation that is ignored leaves a driver assigned to a load that no longer exists.

Ask any vendor, including us, what happens to a dispatched load when a revised tender arrives. The answer should be specific: who is alerted, what is changed on the load, and what is left for a person to approve. If the answer is "it syncs", ask for a demonstration with a changed appointment time.

What does a working integration save? A worked example

Here is an example with invented inputs, so replace them with your own. Say a carrier receives 30 EDI load tenders a week. A dispatcher who retypes each tender into the TMS spends 8 minutes on it. A system that reads the 204 tender into a load leaves a 2 minute review to catch anything odd. Those two timings are assumptions, and the arithmetic is what you can reuse.

A second invented case covers the silent failure. Say a partner's certificate expires on Monday and you notice on Thursday. If you send 25 status messages a day, that is 25 x 3 = 75 messages with no receipt, which is the exposure the MDN receipt exists to catch. A daily check that compares sent counts with receipts would have flagged it on the first morning, so the cost of the check is a few minutes against three days of invisible failures.

How Hemut Command reads EDI 204 tenders

Hemut Command is a TMS built for asset-based trucking carriers. It reads EDI 204 load tenders into loads, so a dispatcher starts from a load that already exists instead of from a blank form. That covers the biggest source of retyping in the example above, the tender itself.

The approved claim stops at the 204. If your plan depends on any other message in the table, or on a specific partner's companion guide, get written confirmation from every vendor you evaluate, Hemut included, and test it with a real file before cutover. Our guide to testing trucking dispatch software shows how to build that test, and trucking TMS software explains what a carrier TMS covers around it.

Checklist: before you connect the next trading partner

1. Get the partner's EDI guide and list which of the 204, 990, 214, 210 and 997 they require from you.
2. Decide the route (VAN or direct AS2) and name the person who owns certificates and renewals.
3. Turn on the 997 and, for AS2, signed receipts, before the first test file.
4. Run one tender through end to end and confirm it becomes the correct load.
5. Test a changed tender and a cancelled tender, and write down what the TMS does with each.
6. Ask which system the partner scores you in, and have them show a test status message there.
7. Add a daily comparison of messages sent against receipts or acknowledgements received.