How to Send an EDI 315 Ocean Shipment Status Update

Ocean visibility data still moves largely through one transaction set most shippers have never had to build themselves: EDI 315 ocean shipment status, the X12 message ocean carriers use to report container and vessel milestones. This walkthrough covers mapping the segments, sending your first transaction, catching the failure mode that trips up most first attempts, and deciding whether it's worth building at all given where DCSA's API roadmap is heading in 2026.

What EDI 315 Actually Reports (and Who Sends It)

EDI 315 is the message ocean carriers and forwarders send to shippers, consignees, and forwarders to report status events like pickup, vessel loading, port arrival, and delivery. EDI 315, also known as a Status Details (Ocean) document, is an EDI transaction set used by ocean carriers to update shippers and receivers about a shipment, informing trading partners about specific events in the shipping cycle for a single shipment or container. It sits in the same X12 transportation family as EDI 214, but built for ocean freight instead of trucking.

The structural quirk that catches people off guard: a single 315 transaction set can carry one event across many containers, or multiple events for one container, but it cannot mix multiple containers under one shipment reference in the same set. The transaction set can be used to provide all the information necessary to report status or event details for selected shipments or containers, and is intended to accommodate the details for one status or event associated with many shipments or containers, as well as more than one status or event for one shipment or container. Design your mapping around that boundary from day one, or you'll be rebuilding it after your first multi-container booking arrives.

What You Need Before You Build Your First 315

Get these four things in place before you touch a mapping tool:

• A signed trading partner agreement specifying which status/event codes are actually in scope. Carriers don't all use the same code sets, and many values are agreed bilaterally rather than pulled from one universal list.
• An active connection method: direct carrier EDI, a VAN, AS2, or a network like INTTRA/GT Nexus (now part of E2open) or Infor Nexus.
• Reference data on hand before mapping starts: booking number, bill of lading number, vessel name and voyage ID, and UN/LOCODEs for the origin and destination ports.
• Access to your carrier's actual implementation guide, not just the generic X12 spec. Infor Nexus, for example, publishes its own 315 mapping guide with carrier-specific segment usage that differs from the base ASC X12 standard in small but important ways.

Step-by-Step: Mapping and Sending the Message

Once you have partner data and connection details confirmed, the build itself follows a predictable sequence:

1. Confirm the event code list and envelope qualifiers with your partner, including ISA/GS segment values for the functional group.
2. Build the ST/B4 header carrying the transaction set ID and the basic beginning segment data for the shipment or equipment being reported.
3. Populate N9 reference segments for the booking number and bill of lading number, plus any other reference identifiers your partner requires.
4. Add the Q2 segment to carry vessel name, voyage number, and the estimated or actual dates tied to the shipment.
5. Add paired R4 segments to identify port of loading and port of discharge. Both segments need to be present together; sending one without the other is a common cause of translator rejection.
6. Populate DTM date/time segments tied to the specific milestone being reported, following the conditional rule that if a DTM04 qualifier is present, DTM03 becomes required.
7. Populate the actual status/event code element, using only codes your partner agreement has defined. This is the field most likely to break downstream systems if it's wrong.
8. Send a test transaction and confirm your translator produces a well-formed SE trailer with segment counts matching what you sent.
9. Confirm receipt. After receiving an EDI 315 transaction, retailers will usually send back an EDI 997 Functional Acknowledgement. No 997, no confirmed delivery.
10. Move to production and reconcile the incoming milestone stream against your TMS or visibility platform's expected event sequence, watching specifically for events arriving out of order.

How You Know It Worked

Three signals tell you the 315 pipeline is working: a 997 comes back clean with no syntax errors, milestone dates land in the correct chronological sequence (gate-out before load, load before vessel departure), and your visibility system shows no duplicate or orphaned status codes against shipments it doesn't recognize. If any of those three break, don't wait for a customer complaint to notice. Build a daily reconciliation check that flags gaps in the expected sequence automatically.

Common Failure Mode: Undefined or Mismatched Event Codes

The most frequent production issue with EDI 315 isn't a segment error. It's a status code your system doesn't recognize. Because event codes are frequently negotiated per partner rather than pulled from a single universal table, a carrier can send a legitimate code your map has never seen. When that happens, the transaction either bounces back as a syntax exception or, worse, gets silently misfiled against the wrong shipment reference because your logic defaulted it to something close enough.

When inaccurate data is received by the EDI system, perhaps because of erroneous qualifiers or data structures not recognized by a trading partner system, the result can be an EDI error code. The fix is unglamorous but effective: maintain a shared code-mapping table with every ocean partner, run every real-world event permutation through a dedicated test cycle before go-live, and configure your system to alert on any unmapped code rather than silently defaulting it to a generic status. A silent default is how a demurrage clock starts running against the wrong container without anyone noticing for three days.

Where This Fits in a Modern Carrier Connectivity Stack

Multi-carrier visibility platforms and TMS providers increasingly pre-map 315-equivalent ocean events so your team isn't hand-building segments per carrier relationship. Descartes, MercuryGate, E2open, CargoSmart, and multi-carrier connectivity tools like Cargoson all sit in this space, absorbing the carrier-specific quirks so your internal systems see one normalized event feed instead of nine different flavors of the same milestone.

That normalization work matters because the underlying carrier landscape is shifting under EDI's feet. DCSA Track & Trace APIs have already been implemented by seven of the nine DCSA carrier members. Pilot work is also moving past pure track-and-trace. The HMM–HelloContainer pilot demonstrates how DCSA's Booking and Electronic Bill of Lading Standards can move digital trade beyond fragmented EDI and email-based workflows toward scalable, API-driven integration, working alongside cargo owner FrieslandCampina to test whether standardised APIs could improve data quality, reduce manual effort and deliver real operational reliability.

Should You Migrate to DCSA APIs Now?

Not all at once, and not by ripping out working EDI connections. The core problem DCSA is solving is real: EDI is not intended for real-time data exchange, it is normally configured to send messages on a pre-set schedule, and shippers must wait for carriers to notify them about agreed-upon events, with exceptions requiring processing batches of EDI messages at fixed intervals. APIs flip that model. APIs can automatically send data in real-time to any API-compliant device that connects to the internet, and shippers and freight forwarders can query a carrier's system or subscribe to automatically receive status updates for any relevant event.

For 2026, a hybrid stance makes more sense than a hard cutover. Keep EDI 315 running for partners who haven't implemented DCSA APIs yet, since a majority of carriers rebuilding this from scratch still isn't realistic this year. Pilot the API route with your highest-volume carrier first, ideally one already running production DCSA Track & Trace. And use the migration conversation as leverage to consolidate your carrier connections through a single visibility platform rather than negotiating API access one carrier relationship at a time, which is exactly the fragmentation problem EDI created in the first place.