EDI 404 Explained: Rail Carrier Bill of Lading
What EDI 404 is, how it differs from EDI 417 and 410, and how railroads like Union Pacific process rail shipment bills of lading via EDI.
If you've spent any time in retail or grocery EDI, the rail transaction sets look like a different universe entirely. There's no 850, no 856, no ASN in the way you're used to thinking about it. Instead you get a small, closed family of X12 documents built specifically for moving railcars between origin, interchange points, and destination. EDI 404 is the one that starts the whole chain.
What is EDI 404?
EDI 404 Rail Carrier Shipment Information is the ANSI X12 transaction set used to transmit a rail-carrier-specific bill of lading between a shipper (consignor) and a rail carrier. It's a commonly used X12 transaction set that facilitates the exchange of a bill of lading, containing shipment information specific to a rail-carrier, between a railroad and a rail carrier. It functions as the initial tender of a shipment between a consignor and a rail carrier and can double as notification of equipment release and/or a legal bill of lading.
That last point matters more than people give it credit for. Unlike most EDI documents, which just describe a transaction that happened somewhere else on paper, the 404 can be the legal document. There's no separate paper bill of lading trailing behind it in a well-run rail EDI setup.
EDI 404 vs EDI 417 vs EDI 410: don't confuse these
The confusion almost always comes from people assuming these three transaction sets are interchangeable stages of "the same document." They're not. Each one has a different sender, a different recipient, and a different legal weight.
| Transaction set | Who sends it | Who receives it | What it actually does |
|---|---|---|---|
| EDI 404 | Shipper / consignor | First-haul rail carrier | Rail-carrier-specific bill of lading information; the initial tender and possible equipment release notice |
| EDI 417 | Originating railroad | Connecting/interline railroads via Railinc | Relays detailed movement instructions for the shipment to rail carriers, built from the 404 data |
| EDI 410 | Rail carrier | Payer of freight charges | Facilitates rail carriers sending freight charge details for a cargo movement; acts as the invoice sent to the party responsible for payment |
Put another way: the 404 is instructions going in, the 417 is the waybill moving between railroads while the shipment is in motion, and the 410 is the bill that shows up after the car has already moved. If your integration team is mapping all three into a single "shipment" object in your TMS, that's usually the point where reconciliation breaks down, because the 417 and 410 don't always carry the same reference numbers back to the original 404 without a REF or N9 loop doing the matching.
How the 404 actually moves: Union Pacific and Railinc
Union Pacific's published EDI process is a clean example of how the document flows in the real world, and it holds for most Class I carriers with minor variations. The EDI 404 shipping instructions are input by the customer via EDI software and transmitted to the first road haul carrier listed in the routing, and Union Pacific's EDI system creates an acknowledgment and transmits this back to the customer to confirm receipt, with the first road haul responsible for transmitting EDI to all other carriers listed in the routing.
From there, the handoff to the wider rail network happens through Railinc rather than carrier-to-carrier point links:
- Customer submits the 404 to the first-haul railroad and gets an acknowledgment back.
- The 417 waybill is created and transmitted via EDI to Railinc's Forward & Store (F&S) System, which then transmits the 417 to all additional road haul carriers listed in the route.
- Forward and Store checks the incoming waybill for compliance to format and syntax standards, and if the initial edits pass, forwards the waybill to the other railroads in the route.
- Billing follows separately as a 410 once the movement is complete.
Every Class I carrier publishes its own flavor of this guide rather than relying purely on the base X12 standard. CSX even splits the 404 into two distinct implementation guides depending on freight type, which trips up a lot of integrators who assume "404" means one fixed layout. BNSF publishes a separate guide with its own carrier-specific quirks around equipment release logic, so mapping a 404 correctly for one Class I doesn't guarantee it will validate against another without rework.
The segments that actually cause problems
The base transaction set has more loops than most people need, but a handful of segments account for nearly every rejection or mismatch a rail EDI team deals with day to day.
- BGN carries the shipment's purpose, creation date, and time, which the carrier uses to schedule the movement. Get the date logic wrong and the shipment either gets rejected outright or silently held.
- N7 specifies the railcar number, equipment type, and length, and it's the segment carriers are tightening rules around. Union Pacific now requires a weight in the N7 segment on every loaded bill of lading, a change tied to the industry-wide 8050 upgrade on 417s.
- N9 and REF loops carry the bill of lading number and other reference identifiers, and this is the join key your 410 reconciliation depends on.
Date handling deserves its own callout. CSX's implementation notes are blunt about it: past dates and times will be rejected, and future dates and times will cause the bill of lading to be held and not released for processing until that date and time have been reached. That single rule causes more support tickets than any mapping bug, because it looks like a system failure when it's actually the carrier doing exactly what its spec says.
For shippers running rail lanes alongside truckload and parcel, the practical answer isn't to build custom 404/417 mapping logic into the ERP directly. Platforms like MercuryGate, Descartes, and Oracle Transportation Management, along with multi-carrier connectivity tools such as Cargoson, exist specifically to abstract this carrier-by-carrier variation away from the shipper's core systems, so a mapping change at BNSF doesn't mean a change request against your ERP.
Cross-border rail EDI: Carta Porte changed the 404 too
Mexico's Carta Porte tax rules didn't just touch invoicing systems, they reached into the rail EDI stack directly. The changes apply to Rail Carrier Shipment Information (EDI 404) and Rail Carrier Waybill Interchange (EDI 417), reflecting enhancements to support Carta Porte regulations enacted by Mexico's Servicio de Administración Tributaria, and apply across EDI versions 5010RAIL through 8040RAIL. Any shipper moving loads into or out of Mexico by rail needs Carta Porte fields present in the 404 or the shipment simply doesn't get billed correctly on the other end.
Version upgrades on top of that happen on the carrier's calendar, not yours. Union Pacific upgraded its EDI requirements from version 8030 to version 8050 for several inter-carrier transaction sets, timed with Railinc's Forward and Store upgrade to version 8050 across the railroad industry. If your mapping team is still running an older data element dictionary against a carrier that's already moved to 8050, expect the connection to fail cleanly rather than degrade gracefully.
Where 404 sits in the wider rail EDI family
The 404 has neighbors that show up in the same conversations. EDI 418 Rail Advance Interchange Consist transmits advance information about equipment being interchanged to a connecting rail carrier, giving the next railroad in the route a heads-up before the cars actually arrive. EDI 419 Advance Car Disposition and EDI 422 Shipper's Car Order round out the set, covering car movement notices to owners and the process of ordering railcars from the carrier in the first place. None of these show up outside rail freight, which is the point: this is a closed, tightly standardized ecosystem compared to the sprawling retail 850/856/810 world most EDI teams cut their teeth on.
FAQ
Is EDI 404 the same as a bill of lading?
Functionally, often yes. It transmits rail-carrier-specific bill of lading information and can serve as notification of equipment release and/or a legal bill of lading, so in many rail relationships there's no separate paper BOL behind it.
Who sends the EDI 404, the shipper or the railroad?
The shipper (consignor) sends it. It's input by the customer via EDI software and transmitted to the first road haul road listed in the routing.
What's the real difference between EDI 404 and EDI 417?
The 404 goes from shipper to the first carrier as instructions and tender. The 417 is what the railroads generate from that data to move the waybill between themselves through Railinc's Forward and Store system.
Does EDI 404 travel over AS2 or a VAN?
Both exist in the wild. Most Class I carriers now push AS2 as the preferred transmission method, with legacy VAN connections still supported for smaller shippers and short lines that haven't migrated.
Do intermodal shipments use a different version of the 404?
Yes. CSX publishes a separate EDI 404 Railcar guide (v.005010) for submitting rail shipping instructions and corrections, and a distinct EDI 404 Intermodal guide (v.005030) for intermodal shipping instructions and corrections. Mapping a railcar 404 template against an intermodal move, or vice versa, is a common cause of rejected transmissions during carrier onboarding.
