EDI 323 Vessel Schedule Data for Cutoff and Rollover Planning

The carrier moved the sailing forward by a day on Tuesday morning. The schedule message arrived in the EDI translator within minutes, the voyage record in the TMS showed the new departure date by lunchtime, and on Wednesday evening two containers still reached the terminal gate after the receiving window had closed. Nobody had recalculated the cutoffs, because the cutoff fields were copied from the booking confirmation weeks earlier and never looked at the voyage again.

An X12 323 vessel schedule feed can prevent that, but only if each revision is matched to the right voyage, every cutoff is re-derived from the new dates, and every booking on the voyage is re-tested against its stuffing and filing plan. Done that way, a pulled-forward departure becomes a planner's alert at 09:15 rather than a rolled container at 18:30 the next day.

• What this guide covers: the 323 segment structure in release 4010, how to read port calls and dates, cutoff recalculation, telling a routine revision from a rollover risk, and the US and Indian filing clocks a schedule change can break.
• What you can reuse: an annotated sample message with the recalculation lines, an ownership table, a voyage-level cost comparison in dollars and rupees, and a go-live checklist that includes the DCSA schedule API alternative.

Where the 323 fits beside the 301 booking and 315 status messages

The 323 describes a vessel's voyage, not your cargo. It tells every subscriber where a ship will call and when, so one revision can affect dozens of bookings that no booking-level message mentions.

X12 describes transaction set 323, Vessel Schedule and Itinerary (Ocean), as carrying the information an ocean carrier needs to communicate a vessel's schedule and itinerary. Reference renderings of release 4010 place it in functional group SO. Carriers send it most often; implementation guides published by terminal operators and port bodies also use it.

• Booking level (301): the carrier's confirmation of one booking, with its assigned vessel, voyage and the cutoffs agreed for it; our 300 and 301 guide covers detecting a roll from consecutive 301s.
• Container level (315): events such as gate-in, loaded and discharged for one container, explained in our 315 status code guide.
• Voyage level (323): the port rotation and dates for one vessel voyage, shared by every booking on that sailing.
• Why it matters: a 323 revision often arrives before any 301 change, so it is the earliest machine-readable warning that cutoffs have moved.

The X12 323 Vessel Schedule and Itinerary (Ocean) message describes one vessel voyage: in release 4010 the V1 segment identifies vessel and voyage, and a mandatory R4 port-call loop, repeatable up to 999 times, carries up to 15 DTM dates and up to five V9 events per port.

Reading V1, R4, DTM and V9 in a release 4010 schedule message

Four segments do the work: V1 names the vessel and voyage, R4 names each port call, DTM dates it and V9 labels the event. Store each port call as its own row keyed by vessel identifier, voyage number and location code.

V1 needs either a vessel code (V101, up to eight characters) or a vessel name (V102, up to 28), and it can carry the flag country, the voyage number in V104, the carrier's SCAC in V105 and, in V108, the source of the vessel code. The 4010 qualifier list for V108 has four values: B for US Bureau of Census, C for the ship's radio call sign, L for Lloyd's Register of Shipping and Z for mutually defined.

The date qualifiers that matter for planning sit in the X12 code list: 369 Estimated Departure Date, 370 Actual Departure Date, 371 Estimated Arrival Date, 372 Actual Arrival Date and 311 Latest Receiving Date/Cutoff Date. The V9 event list separates SDD Scheduled Departure Date from EDD Estimated Departure Date, and includes SLD Sailed and COC Cancellation of Conveyance. Which of these a carrier actually sends is fixed by its implementation guide, so read the guide before mapping.

Recomputing gate, document and VGM cutoffs when the ETD moves

Cutoffs are offsets from the departure the terminal and carrier plan to, so they must be derived again from every new estimated departure. Copying cutoff timestamps once at booking guarantees they go stale on the first schedule revision.

Keep a reference table of offsets per terminal and per service: container yard receiving, shipping instructions, verified gross mass and hazardous cargo declarations. When a 323 sends DTM 311, store it and compare it with your derived value, because a terminal notice can change before the carrier's EDI does. The sample below shows one revision and the recalculation it should trigger.

ST*323*0001~
V1*9361235*NORTHERN SAMPLE*LR*124W*ABCD***L~
K1*REVISION 3 ETD ADVANCED 24H~
R4*L*UN*INNSA*NHAVA SHEVA*IN*SAMPLE TERMINAL~
DTM*369*20261120*0600~
V9*EDD*ESTIMATED DEPARTURE*20261120*0600~
R4*D*UN*USSAV*SAVANNAH*US*SAMPLE TERMINAL~
DTM*371*20261218*1400~
V9*EAD*ESTIMATED ARRIVAL*20261218*1400~
SE*10*0001~

Recalculation on receipt (illustrative offsets from the terminal table):
  new_ETD          = 2026-11-20 06:00   (was 2026-11-21 06:00)
  CY_cutoff        = new_ETD - 36 h  = 2026-11-18 18:00
  SI_cutoff        = new_ETD - 48 h  = 2026-11-18 06:00
  VGM_cutoff       = new_ETD - 40 h  = 2026-11-18 14:00
  slack(b, k)      = cutoff_k - planned_ready(b, k)
  alert if slack(b, k) < 6 h for any booking b on voyage 124W
US export voyages also: EEI_latest = planned_load_start - 24 h

The vessel code, name, terminal and SCAC above are invented for illustration; the UN/LOCODEs INNSA and USSAV are real. Offsets differ by terminal and service, which is why they belong in a maintained table rather than in mapping code.

Telling a routine schedule revision from a likely rollover

Most 323 revisions shift times by a few hours and need no action; the dangerous ones pull departure forward, drop a port or change the vessel. Score each revision on those changes before alerting anyone.

Compare each revision with the last stored one, port call by port call, and classify the difference. A later departure usually adds slack. An earlier one removes it from every booking at once, and that is the case where cargo is left behind because nobody can re-plan stuffing and trucking in the hours remaining.

• Departure pulled forward: recalculate all cutoffs and alert on any booking whose slack falls below the buffer.
• Port omitted: an R4 present in the last revision is missing; every booking loading or discharging there needs a carrier answer.
• Vessel code changed: V101 differs on the same service and voyage; treat it as a substitution and check manifests and filings that name the vessel.
• Event COC received: cancellation of conveyance; stop dispatch planning for the voyage until a 301 confirms the new sailing.
• Departure later by under 12 hours: update the record, log the revision, no alert.

The 323 never confirms that your booking was rolled; only the carrier's booking confirmation or notice does that. Our rollover workflow guide covers what to do once a roll is confirmed. A schedule feed earns its keep earlier, by warning while there is still time to stuff, truck and file ahead of the new cutoffs.

Customs and filing clocks a moved sailing can break in each market

A schedule change moves regulatory deadlines as well as terminal cutoffs. In both markets, the filing tied to loading or departure moves with the vessel, and the cut-off times themselves are set by terminals and carriers rather than by statute.

In the United States, 15 CFR 30.4(b)(2)(i) requires the US principal party in interest or its authorised agent to file Electronic Export Information for vessel cargo, and give the carrier the filing citation or exemption legend, 24 hours before the cargo is loaded at the US port. Our EEI filing guide covers the filing itself; the point here is that the deadline follows loading, not the booking.

Under 15 CFR 30.4(b)(2)(i), a US exporter or authorised agent must file vessel Electronic Export Information and give the carrier the filing citation 24 hours before loading at the US port, so a 323 revision that advances departure by 24 hours advances that EEI deadline by the same 24 hours.

Verified gross mass works the same way in both markets. IMO guidance MSC.1/Circ.1475 makes the shipper responsible for providing the verified gross mass of a packed container sufficiently in advance for the stowage plan, says a container without it should not be loaded, and expects the carrier to tell the shipper the specific deadline after discussion with the terminal. That deadline is a carrier rule, so it moves when the carrier's plan moves.

In India, export cargo needs a let export order on the shipping bill before loading, and the carrier files a departure manifest. Regulation 5(1) of the Sea Cargo Manifest and Transhipment Regulations, 2018 requires that manifest to be delivered electronically before the vessel departs, and regulation 5(3) allows updates within 24 hours after departure for containerised cargo. Port and terminal cutoffs at Indian gateways are commercial practice, published by terminals and lines, not a statutory clock.

Regulation 5(1) of India's Sea Cargo Manifest and Transhipment Regulations, 2018 requires the departure manifest before the vessel leaves, and CGST rule 96(1)(a) ties the IGST export refund to a manifest covering the shipping bill number and date, so rolled cargo must appear on the sailing vessel's manifest.

The rupee consequence is cash, not penalty. Rule 96(1) of the CGST Rules, 2017 treats the shipping bill as the refund application for IGST paid on exported goods once the carrier has filed an export manifest or report covering that shipping bill's number and date and the exporter has filed a valid GSTR-3B. A shipping bill that ends up on the wrong voyage's manifest leaves the refund without its trigger.

Who owns the voyage record, the offsets and each sign-off

A schedule feed touches four teams, and each record needs one owner who can correct it. Without named owners, a stale cutoff stays stale because every team assumes another maintains it.

Field mapping to Indian customs data deserves its own line. The departure manifest cargo declaration form under the 2018 regulations asks for the IMO code of the vessel, the vessel call sign, the voyage number and each shipping bill number and date. A 323 carries one vessel code with its source in V108, so whichever identifier the carrier omits must come from vessel master data, not from the message.

A voyage-level worked example in dollars and rupees

When departure moves forward, the choice for each exposed booking is to pull stuffing and trucking forward or accept the next sailing. The arithmetic below uses illustrative figures for one US and one Indian export voyage.

In both cases the 323 revision advanced departure by 24 hours, and six bookings sat on the voyage. Four still had six hours or more of slack after recalculation. Two did not: their containers were planned to gate in after the new container yard cutoff. The table compares the two choices for those two containers.

The US case is clear-cut because the customer contract carries a late-delivery credit. The Indian case is close: without the letter-of-credit discrepancy, accepting the next sailing would cost ₹29,091 and be cheaper than expediting. That is why the decision belongs to a planner with the contract terms in front of them, not to the integration layer.

Trace: a revised voyage the TMS filed as a brand-new sailing

The commonest 323 failure is not a missed message but a mis-matched one. In the trace below, every system worked as configured, and two containers still missed the receiving window.

1. Tue 09:12, revision received: the translator accepts 323 control number 0417 for voyage 124W; V102 now reads "M/V NORTHERN SAMPLE" instead of "NORTHERN SAMPLE", and DTM 369 at INNSA moves from 21 November 06:00 to 20 November 06:00.
2. Tue 09:13, wrong match: the TMS voyage lookup keys on vessel name plus voyage, finds no match and creates voyage record VY-88214; the six bookings stay linked to the old record VY-87790 with its old dates.
3. Tue 09:13, silent cutoffs: cutoff recalculation runs only for bookings on VY-88214, which has none, so no alert is raised and the stuffing plan still targets gate-in on 19 November.
4. Wed 18:00 to 18:40, gate rejection: containers for bookings BK-55120 and BK-55127 arrive at 18:25 and 18:40, after the new 18:00 receiving cutoff, and the terminal refuses them for voyage 124W.
5. Thu 10:30, fix applied: the lookup is changed to V101 with its V108 source plus V104, the duplicate record is merged, and a daily report lists any voyage record created without bookings.

With the corrected match, the same revision would have raised an alert at 09:14 on Tuesday showing two bookings with negative slack, more than 30 hours before the new cutoff.

Which schedule checks run as fixed rules and which need a planner

Matching, recalculation and alerting are rules; choosing what to do about an exposed booking is a planner's decision. Software can help read free text and estimate further slippage, but it should never move a cutoff by itself.

Go-live checklist for a 323 feed and its API alternative

Test a schedule feed against real revisions before trusting it with cutoffs. The checklist below covers the connection, the matching logic and the planner workflow, and notes where a schedule API can replace the EDI link.

Some carriers now publish schedules through APIs built to Digital Container Shipping Association standards. DCSA released Operational Vessel Schedules 3.0 in January 2024, covering schedule changes and exceptions such as port omissions and blank sailings, together with a Commercial Schedules 1.0 beta offering point-to-point, port and vessel schedule queries. The matching and recalculation rules stay the same whichever channel delivers the dates.

For related EDI and ocean guides, browse the Logistics and Supply Chain hub. If you want help connecting carrier schedules to your TMS, warehouse plan and customs filings so a schedule change becomes a planner alert instead of a rolled container, share your requirements and we will scope it with you.