How to Process an EDI 322 Rail Ingate/Outgate Feed

Every Class I railroad and marine terminal in North America reports container gate activity through the same X12 message: EDI 322, Terminal Operations and Intermodal Ramp Activity. If you run drayage dispatch for a company moving import or export containers off rail ramps, this feed is either the thing that keeps your demurrage clock under control or the thing nobody wired up correctly, which is why you're reading a support ticket about a $2,400 per diem charge right now. This walkthrough uses CN Rail's and CSX's published implementation guides to show exactly how to consume a 322 feed and connect it to your TMS or drayage dispatch system.

What the EDI 322 Actually Tells You

The EDI 322 exists to report gate events, not to describe cargo or negotiate rates. This X12 Transaction Set contains the format and establishes the data contents of the Terminal Operations and Intermodal Ramp Activity Transaction Set (322) for use within the context of an Electronic Data Interchange (EDI) environment. In practice, the 322 reports terminal and intermodal ramp activity, chiefly ingate and outgate events, to the parties authorized on a shipment, and a terminal operator, port authority, or intermodal ramp sends the 322 to authorized parties to the shipment, such as ocean carriers, railroads, motor carriers, and shippers.

Each message fires at a specific moment: a container or trailer passes an ingate or outgate at a marine terminal or intermodal rail ramp and the gate system records the movement. And each event identifies the equipment initial and number, seal numbers, event status with date and time, and the terminal or port location, so carriers and shippers can track custody of a container or trailer as it moves through marine terminals and rail ramps. The spec itself isn't small. The X12 322 specification defines 26 segments carrying 113 data elements, 43 of which are mandatory, though any single railroad's implementation guide, per the Stedi X12 322 reference, only lights up a fraction of those.

Before You Start: What You Need

You need three things in place before a single test file moves: trading partner enrollment with the specific railroad, a tested AS2 or VAN connection, and a TMS or drayage dispatch system with fields ready to receive gate-level data, not just load-level data.

For CN Rail specifically, the EDI Onboarding team email address is [email protected], and that team walks you through the same configuration attributes covered below (local time versus UTC, last free day inclusion, pickup number reporting). CSX publishes an equivalent guide for its own 322 v007050 implementation, and both documents assume you already have a working connection, not that you're setting up EDI from scratch.

On the receiving side, your TMS or dispatch platform needs a container number field, an equipment ID field, and a dwell or appointment clock that can be started by an external event rather than a manual entry. This is the point where carrier connectivity software actually earns its keep. Platforms like MercuryGate, Descartes, Uber Freight, DrayNow, Trucker Tools, and Cargoson exist specifically to take gate-event EDI and turn it into dispatch triggers instead of leaving it sitting in a translator as an unmapped file.

Step-by-Step: Setting Up and Parsing the Feed

1. Confirm 322 subscription scope with the railroad. Decide which events you actually need, gate-in, gate-out, notification, last free day, and how often. CN Rail's EDI Scheduler is flexible on this: EDI Scheduler provides flexible production times for the 322, and the 322 can be produced up to a maximum of 46 times per day in ½ hour intervals except for 2:00 and 2:30. Don't just accept the default schedule; ask for the interval your dwell-clock logic actually needs.
2. Establish or verify AS2/VAN connectivity and request a test interchange. Confirm certificate validity, MDN settings, and that your translator can parse an ISA/GS/ST envelope from this specific trading partner before asking for production data.
3. Map the envelope and core segments. The 322 carries most of its useful data in a small handful of segments. See the table below for what each one does.
4. Match incoming container and reference numbers against open dispatch records. Use the equipment initial and number to match against your open load or dispatch record, and cross-check any booking, BOL, or pickup reference carried in N9.
5. Trigger downstream workflow off the event code. A gate-in event should flip container status to "available for pickup" or "returned empty." A gate-out event should start the drayage or dwell clock, not wait for a driver to check in manually.
6. Generate a 997 or 999 functional acknowledgment for every 322 received. This is non-negotiable. Missing acknowledgments are the first thing a railroad's EDI support team checks when a dispute opens.
7. Build a demurrage alert off the DTM timestamp plus the last free day attribute. If you request this attribute from CN Rail, if this attribute is selected, the last free day of storage would be provided, which gives you a hard date to alert against instead of estimating it from a static free-time table.

Segments That Carry the Data You Actually Care About

How You Know It Worked

You'll know the feed is live when three things line up: a 997 or 999 accepted without segment errors, container status changes appearing in your TMS within the railroad's stated production window, and demurrage clock start times matching the terminal's own gate records rather than drifting by hours. Spot-check the first week of production against the terminal's own web portal or the railroad's EDI Scheduler output, not just your internal dashboard. If your dwell clock and the terminal's own clock disagree by more than the production interval, something in your DTM mapping is wrong, not the railroad's data.

Failure Mode: Wrong Terminal Coding and Late Transmission

The most common real-world failure isn't a rejected interchange, it's a silently wrong one. Wrong or missing terminal or ramp location coding in the R4 segment attributes the gate event to the wrong facility, which means your dispatch system thinks a container is sitting at Ramp A when it's actually at Ramp B, and your driver gets sent to the wrong gate. On top of that, late event transmission drives equipment tracking and time-based charges, so delayed 322s distort dwell measurement and dispute resolution. A related, quieter problem: equipment identification mismatches happen when the equipment initial and number in N7 don't match the equipment master and related shipment records, leaving gate events unmatched to a shipment, and seal numbers missing or inconsistent between the ingate and outgate events trigger seal-integrity exception handling.

The fix for the location problem is boring but effective: validate every R4 code your railroad sends against its published station or ramp code list before go-live, not after the first misrouted driver call. For late transmission, set an SLA-based alert if an expected 322 doesn't arrive within the railroad's stated production window, CN's roughly 30-minute cycle being a good baseline, so a missing event gets caught by a monitoring job instead of by a demurrage invoice three weeks later.

Why This Matters More in 2026

Short-haul drayage moves look low-risk on paper and aren't. These moves span fewer than 150 miles but carry enormous financial risk; missed appointment windows, chassis shortages, and poor coordination between dispatchers, drivers, and warehouses can turn a routine pickup into thousands of dollars in demurrage and detention charges, sometimes within a single day. That risk hasn't gotten smaller. For fleet managers operating in 2026's tighter, more congested port environment, reactive management is no longer an option. The data backs up why real-time gate-event processing pays for itself: proactive last-free-day monitoring, automated alerts, and coordinated warehouse scheduling prevent 60 to 80 percent of detention and demurrage charges from forming, according to FleetRabbit's 2026 drayage fleet management guide.

That's also why any TMS claiming carrier connectivity needs to prove it can ingest event-driven EDI like the 322, not just document-level transactions like invoices and bookings. It's a meaningfully different integration problem, and it's the one that actually protects your demurrage budget.

Related Reading

If you're setting up this feed for the first time, pair it with a look at how EDI 214 shipment status messages complement gate events for full-journey visibility, how EDI 404 rail carrier bills of lading tie into the same shipment records, and a refresher on AS2 connectivity and 997/999 acknowledgment handling if your translator setup is still new. For the underlying spec detail referenced throughout this guide, CSX's own EDI 322 v007050 specification is worth bookmarking alongside CN Rail's implementation guide.