EDI 210, 310, 110 and 410

Freight EDI Explained

EDI 210, 310, 110 and 410

Four numbers that turn up on every freight payables conversation. Here is what each one actually carries.

Freight EDI Updated August 2026 7 minute read

EDI transaction sets are referred to by number, which makes conversations about them impenetrable to anyone who has not memorised the list. The numbers are not descriptive and there is no pattern to learn — 210 does not relate to 310 in any way you could infer.

The short version: 210 is the motor carrier freight invoice, 310 is ocean, 110 is air, and 410 is rail. Same purpose, four modes. Everything else in freight EDI travels around these.

What follows covers each of the four, the transaction sets that accompany them, and the practical detail that matters most in a payables process — including why an invoice can be successfully transmitted, acknowledged, and still not be in anyone's system.

The invoice formats

Four modes, four numbers.

210 — Motor Carrier Freight Details and Invoice

The workhorse. A trucking carrier sends a 210 to bill for a completed movement, carrying the charges, the reference numbers linking it back to the load, and enough detail to validate it against the agreed rate. Most freight payables volume in domestic US operations arrives as 210s.

310 — Freight Receipt and Invoice (Ocean)

The ocean equivalent. Carries container-level detail, port pairs and the ocean charge structure — including the surcharges that do not exist in road freight, such as BAF and CAF.

110 — Air Freight Details and Invoice

Air. Includes chargeable weight, which for air freight is frequently dimensional rather than actual — one of the recurring sources of billing disputes on this mode.

410 — Rail Carrier Freight Details and Invoice

Rail. Carries car or equipment initial and number, route detail and rail-specific accessorials such as switching and storage.


What travels alongside

The transaction sets that resolve disputes.

An invoice on its own is an assertion. The documents around it are what let you check whether the assertion is correct — and in practice most disputes get settled by reading something other than the invoice.

Set What it is Why it matters at invoice time
204 Motor carrier load tender Usually carries the agreed rate. This is the reference document for validating a 210.
990 Response to load tender Confirms the carrier accepted the load, and on what terms.
214 Shipment status message Arrival, departure and delivery timestamps. Where accessorial disputes are actually settled.
997 Functional acknowledgement Confirms a transmission was received and syntactically valid. Nothing more.
820 Payment order / remittance advice What was paid and against which invoices. The reconciliation record.
824 Application advice Business-level acceptance or rejection — the message a 997 is often mistaken for.

The pairing worth internalising is 204 and 210. The tender says what was agreed; the invoice says what is being charged. Validation is the comparison between the two, and an operation that cannot easily retrieve the 204 for a given 210 is validating on memory.

The second is 214 and accessorials. Detention, layover, storage — all of them turn on timing, and the timestamps live in the status message rather than the invoice.


The common misunderstanding

A 997 does not mean the invoice was accepted.

This causes more confusion than any other point in freight EDI, and it costs real time when it goes unnoticed.

A functional acknowledgement confirms two things: the transmission arrived, and it was syntactically valid. That is the whole scope. It says nothing about whether the invoice passed business rules, whether the reference numbers matched a known load, or whether anyone will pay it.

What this looks like in practice: a carrier sends an invoice, gets a clean 997, and considers it delivered. Weeks later they chase payment. The invoice was rejected on business rules the same day it arrived — mismatched load reference, unknown location code, a charge type not in the agreement — and nobody was watching the 824.

If your payables process monitors 997s but not 824s or your own rejection log, invoices are dropping out of the pipeline silently in both directions. That is worth checking before it becomes a carrier relationship problem.

Validating extracted invoice data against the shipment record before posting
Transmission received is not the same as invoice accepted.

The reality

Most operations do not run on EDI alone.

Larger carriers generally trade EDI. Plenty of smaller operators do not — they invoice by email, by PDF, or by leaving it in a portal for you to collect. A payables process designed only around EDI leaves a meaningful share of invoices to be handled some other way, usually manually, usually by whoever has time.

Carrier invoices arriving by EDI, portal download, email and post
Four intake channels, one payables process.

Which means the practical questions are less about EDI than about coverage:

  • Which carriers trade EDI with you, and which do not?
  • For the ones that do not, who collects the invoice and how often?
  • Are non-EDI invoices validated to the same standard, or approved on sight?
  • Can you retrieve the 204 for any given 210 without asking someone?
  • Is anyone watching for invoices that were sent but never entered your system?

The last one catches operations out most often. An invoice that never arrives does not generate an exception — it generates silence, and silence looks identical to everything being fine. Related: freight automation and back office for freight payments.

Not sure what your non-EDI invoices are costing you?

Send us 100 recent invoices in whatever format they arrive. We validate every one against your agreed rates and send a written report in 5 business days.

Get My Free Audit

Common questions

Freight EDI, answered.

What is an EDI 210?

The EDI 210 is the motor carrier freight details and invoice transaction set. A trucking carrier sends it to bill for a completed shipment. It carries the charges, the reference numbers linking it to the load, and the detail needed to validate it against a rate agreement.

What are the EDI 310, 110 and 410?

They are the mode equivalents of the 210. The 310 is the ocean freight invoice, the 110 is the air freight invoice, and the 410 is the rail carrier invoice. Each carries charges and references appropriate to its mode.

What does an EDI 997 confirm?

A 997 functional acknowledgement confirms that a transmission was received and was syntactically valid. It does not confirm that the invoice was accepted, approved or will be paid. An invoice can generate a clean 997 and still be rejected on business rules afterwards.

What is the difference between a 204 and a 210?

A 204 is the load tender — the shipper offering a load to a carrier before the movement. A 210 is the invoice for that movement afterwards. The 204 usually carries the agreed rate, which makes it the reference document for validating the 210.

Why does an invoice dispute often get resolved by reading the 214?

The 214 is the shipment status message, carrying arrival, departure and delivery timestamps. Most accessorial disputes turn on timing — when a driver arrived, how long they waited, when a container was returned — and the 214 is where those timestamps live.

Do all carriers send EDI invoices?

No. Larger carriers generally do, but many smaller operators invoice by email, PDF or carrier portal. Most freight operations therefore run mixed intake, which is why a payables process built only around EDI leaves a significant share of invoices unhandled.


Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top
document.addEventListener('DOMContentLoaded', function() { // Wait for SmartMenus to fully load first setTimeout(function() { var nav = document.querySelector('#menu-1-18703de'); if (!nav) { nav = document.querySelector('.elementor-nav-menu'); } var items = nav ? nav.querySelectorAll('.menu-item-has-children') : []; Array.prototype.forEach.call(items, function(item) { var submenu = item.querySelector('.sub-menu'); var timer; item.addEventListener('mouseenter', function() { clearTimeout(timer); if (submenu) { submenu.removeAttribute('style'); submenu.style.cssText = 'display:block !important; visibility:visible !important; opacity:1 !important; pointer-events:all !important; position:absolute !important;'; } }, true); item.addEventListener('mouseleave', function() { timer = setTimeout(function() { if (submenu) { submenu.style.cssText = 'display:none !important;'; } }, 400); }, true); // Also keep open when hovering submenu itself if (submenu) { submenu.addEventListener('mouseenter', function() { clearTimeout(timer); }, true); submenu.addEventListener('mouseleave', function() { timer = setTimeout(function() { submenu.style.cssText = 'display:none !important;'; }, 400); }, true); } }); }, 1000); });