Ocean freight integration
Ocean Freight EDI and API Integration
An ocean shipment is a chain of cutoffs: the booking, the shipping instructions and verified gross mass, then container events through arrival, release and empty return. ECOM connects your TMS, ERP, forwarding and customs systems to carriers and terminals, then maps, validates, tests and monitors each message or API call, so teams stop re-keying bookings and chasing container status by email.
Overview
What is ocean freight EDI and API integration?
Ocean freight EDI and API integration is the automated exchange of booking, shipping instruction, container and billing data between shippers, forwarders, ocean carriers, marine terminals, customs brokers and customs authorities. Three families of standards are in use. ANSI X12 is common in North America, with sets such as the 300 booking request, 304 shipping instructions, 315 status details and 310 freight receipt and invoice. UN/EDIFACT is common internationally, with messages such as IFTMBF, IFTMIN, IFTSTA, VERMAS and the container messages COPARN, CODECO and COARRI. The Digital Container Shipping Association (DCSA) publishes standard interfaces for container shipping, including Booking, Track and Trace, Verified Gross Mass and Arrival Notice. Each carrier decides which of these it accepts, in which versions.
Overview
For ocean carriers and the businesses that connect to them
Ocean data passes through carriers, terminals, forwarders and customs parties.
Ocean carriers and their agents
You receive booking and instruction data from many forwarders and shippers, each with its own format and channel.
NVOCCs and freight forwarders
You connect to many carriers and terminals and must reconcile their messages for customers.
Shippers and importers
You need booking confirmation, container events, arrival notice and invoices in your TMS and ERP.
Terminals and inland transportation partners
You exchange gate, release and delivery events that the carrier and the beneficial cargo owner rely on.
How ECOM helps
How ECOM supports ocean workflows
The ocean leg connects to inland transportation and customs workflows. These offerings apply across them.
Bookings and instructions entered once
Booking and shipping instruction data flow from the system where the shipment is created, so teams stop re-keying into one portal per carrier.
Cutoffs you can see coming
Booking confirmations, cutoff dates and instruction and VGM status are tracked per shipment, so a missing item is noticed while there is still time to send it.
Container milestones in your own systems
Gate, load, discharge and arrival events reach your TMS or visibility tools, so planners see where a container is and how much free time remains.
Invoices you can reconcile
Freight and demurrage or detention invoices that carry the bill of lading and container numbers can be compared with the shipment before they are paid.
How ECOM delivers it
Message and API mapping
Booking, shipping instruction, VGM, status, arrival and invoice data mapped between your systems and the X12 version, EDIFACT message or carrier API each partner specifies.
Validation before sending
Outbound messages are checked against the partner specification, and acknowledgments, rejections and application errors are matched back to the shipment.
Connectivity
Connections over AS2, SFTP, HTTPS and APIs, hosted by ECOM or opened to the partner, according to what each carrier, terminal or customs system supports.
Specification review and testing
ECOM reviews the carrier specification, builds the maps and tests scenarios with the partner, including amendments, rejections and late changes, before go-live.
Monitoring and alerts
Unconfirmed bookings, missing instructions or VGM, silent containers and failed transfers surface as exceptions so someone can act before the cutoff.
Ongoing support
ECOM offers 24×7 support, with coverage hours and response targets defined in each service agreement.
ECOM offerings for this workflow
Systems Integrator
Connects TMS, ERP and WMS platforms with booking, instruction, container-event and invoice data from carriers and terminals. Hundreds of customers use the Systems Integrator today, and ECOM performs these integrations for customers.
Exception Management Center
Helps automate exception handling and manage internal and customer-facing SLAs, such as rolled bookings and missed cutoffs.
Transaction Life Cycle Manager
Holds shipment paperwork and supporting evidence with the shipment, including proof of delivery, signatures, damage reports and shortage reports.
Inland and customs coordination
The inland dray is covered on the intermodal and road pages, and the data exchange with brokers on the customs page.
Freight Onboarding
Brings carriers and other freight partners live.
Trading Partner Onboarding
A self-service portal that supports almost all verticals, with customer click-through onboarding, protocol-specific setup and automated transaction testing.
Reconcile360 (invoice-to-cash)
Invoice-to-cash automation across all verticals, including ocean partners, so freight billing connects to cash.
Which offerings apply, and the partners, protocols and systems in scope, are agreed with you during scoping.
Workflow
From booking to empty return: the ocean container lifecycle
An export or import container passes through the carrier, a terminal and customs. The stages below follow a typical container shipment from schedule to invoice, with the X12, EDIFACT and DCSA options for each.
- 01
Check the schedule
The shipper or forwarder looks up vessel schedules and routings before booking.
Typical messages: X12 323 Vessel Schedule and Itinerary; DCSA Commercial Schedules and Operational Vessel Schedules
- 02
Book the container
The booking request reserves space and equipment, and the carrier confirms with a booking number, vessel and voyage, and cutoff times.
Typical messages: X12 300 and 301 (303 to cancel); EDIFACT IFTMBF and IFTMBC; DCSA Booking
- 03
Send shipping instructions and VGM before cutoff
Shipping instructions tell the carrier how to prepare the bill of lading, and the shipper provides the verified gross mass, which must reach the carrier and terminal before loading.
Typical messages: X12 304; EDIFACT IFTMIN; EDIFACT VERMAS or DCSA Verified Gross Mass
- 04
Gate in and load
The carrier announces the containers to the terminal, the terminal reports gate-in and loading, and the carrier updates its records.
Typical messages: EDIFACT COPARN, COPRAR, CODECO and COARRI; X12 322
- 05
Sail and track
Events during the voyage, including loading, departure, transshipment and arrival, give shippers and consignees container visibility.
Typical messages: X12 315 Status Details; EDIFACT IFTSTA; DCSA Track and Trace
- 06
Arrival notice and customs
The carrier tells the consignee that the cargo is arriving, and the manifest and importer security filings go to U.S. Customs and Border Protection.
Typical messages: X12 312 or EDIFACT IFTMAN or DCSA Arrival Notice; CBP ACE manifest and ISF messages
- 07
Discharge, release and gate out
The terminal discharges the container, the carrier releases it, and the trucker gates it out to the consignee.
Typical messages: X12 317 Delivery/Pickup Order; EDIFACT COREOR, COARRI and CODECO
- 08
Return the empty container
The empty container is returned to a depot or terminal. A gate-in event ends the equipment clock, so timing and visibility matter here.
Typical messages: EDIFACT CODECO gate event; X12 322; status messages
- 09
Invoice and settle
The carrier bills freight, and demurrage or detention if it applies, and the payer audits the invoice against the booking, bill of lading and container events.
Typical messages: X12 310 Freight Receipt and Invoice (Ocean); EDIFACT INVOIC
Who sends which ocean message to whom
Shippers and forwarders mostly exchange booking, instruction and billing messages with the carrier. The carrier exchanges container messages with terminals and files manifests with customs. The diagram shows typical directions; the tables give purpose, trigger, data and systems for each message.
Illustrative example: one booking with two containers
An illustrative booking, followed step by step. Partners define their own messages and sequence.
| Step | Message | From → to | What the integration checks |
|---|---|---|---|
| Book the sailing | Booking request (300, IFTMBF or DCSA Booking) | Shipper → carrier | Required booking fields are present, and the booking reference is saved against the shipment. |
| Confirm the booking | Booking confirmation (301 or IFTMBC) | Carrier → shipper | The confirmation matches the request, and cutoff dates are stored and tracked. |
| Send instructions and VGM | Shipping instructions (304 or IFTMIN) and VGM (VERMAS) | Shipper → carrier | Both arrive before their cutoffs, and both containers have a verified weight. |
| Gate in and load | Gate and loading reports (CODECO, COARRI) | Terminal → carrier, then status to shipper | Both containers show a gate-in and loading event. |
| Track and arrive | Status (315, IFTSTA or Track and Trace) and arrival notice (312) | Carrier → shipper and consignee | Events arrive in order, and free time is shown beside each container. |
| Invoice the freight | Freight invoice (310 or INVOIC) | Carrier → payer | The invoice carries the bill of lading and container numbers and is compared with the booking. |
Messages
Transactions and messages
Typical requirements—confirm with your trading partner.
Schedules, booking, shipping instructions and bills of lading
These messages create the shipment with the carrier. Each business step can be carried by an X12 set, an EDIFACT message or a DCSA interface, depending on the carrier. DCSA also publishes a Bill of Lading standard; confirm with each carrier whether it offers shipping instructions or electronic bills of lading through it.
| Transaction | Purpose | Sender → receiver | Trigger | Key data | Connected systems | Business benefit |
|---|---|---|---|---|---|---|
| 323 · DCSA Commercial Schedules Vessel schedule and itinerary ANSI X12; DCSA | Shares a carrier’s vessel schedules and itineraries. DCSA describes Commercial Schedules as a common way for carriers to communicate vessel schedule information to customers. | Ocean carrier to Shipper, forwarder or planning system | Schedule published or changed | Vessel, voyage, ports and dates | Carrier schedule systems to TMS or planning tools | Booking against current schedules |
| 300 · IFTMBF · DCSA Booking Booking request ANSI X12; UN/EDIFACT; DCSA | Reserves space, containers and equipment on a sailing. X12 describes the 300 as the booking request for ocean vessel space. | Shipper or forwarder to Ocean carrier | Cargo ready and a sailing chosen | Ports, dates, cargo, container number and type, special requirements | TMS, ERP or forwarding system to carrier booking system | Bookings placed from your system, not a portal |
| 301 · IFTMBC Booking confirmation ANSI X12; UN/EDIFACT; DCSA Booking | Confirms space and equipment availability, or in EDIFACT states that the booking is accepted, pending, conditionally accepted or rejected. | Ocean carrier to Shipper or forwarder | Carrier decision on the booking | Booking number, vessel and voyage, cutoff times, equipment pickup | Carrier system to TMS or forwarding system | Cutoffs known as soon as the booking is confirmed |
| 303 Booking cancellation ANSI X12 | Cancels a previous booking request. | Shipper or forwarder to Ocean carrier | Cargo not ready or plans changed | Booking reference and cancellation reason | TMS to carrier booking system | Cancelled bookings released without delay |
| 304 · IFTMIN Shipping instructions ANSI X12; UN/EDIFACT | Tells the carrier how to prepare the contract of carriage, such as the ocean bill of lading or sea waybill. | Shipper or forwarder to Ocean carrier | Booking confirmed and cargo details final, before the instruction cutoff | Shipper, consignee and notify party, cargo description, packages, weights, container numbers and seals | TMS, ERP or forwarding system to carrier documentation system | Bill of lading drafts based on your data, so corrections are fewer |
| 310 Freight Receipt and Invoice (Ocean) ANSI X12 | Carries ocean bill of lading information from carriers to interested parties; it can serve as a shipment receipt, a copy of the bill of lading or a freight invoice. | Ocean carrier to Shipper, consignee or payer | Bill of lading issued or freight billed | Bill of lading, parties, charges, container details | Carrier system to ERP or freight audit | Freight billed against a known bill of lading |
Verified gross mass, container and terminal messages
Before loading, the carrier and terminal need the verified gross mass of every packed container. Container messages then move between the carrier and the terminal as the container gates in, loads, discharges and gates out. SMDG publishes implementation guidelines for the EDIFACT container messages.
| Transaction | Purpose | Sender → receiver | Trigger | Key data | Connected systems | Business benefit |
|---|---|---|---|---|---|---|
| VERMAS · DCSA Verified Gross Mass Verified gross mass UN/EDIFACT; DCSA | Submits the verified gross mass of a packed container. Under SOLAS the shipper is responsible for it, and the container should not be loaded without it being provided in advance. | Shipper, forwarder or weighing party to Ocean carrier or terminal | Container packed and weighed or weight calculated, before the VGM cutoff | Container number, verified weight, weighing method, responsible party and signature | Warehouse, packing and TMS systems to carrier or terminal | VGM delivered before cutoff, with an audit trail |
| COPARN Container announcement UN/EDIFACT | Orders the release of empty containers or announces containers arriving at a terminal. | Shipping line or its agent to Terminal or depot | Booking confirmed and equipment or arrival to be arranged | Container type, booking reference, release or receiving details | Carrier system to terminal or depot system | Truckers admitted at the gate |
| COPRAR Container discharge/loading order UN/EDIFACT | Orders the terminal to discharge specified containers from a vessel or to load them. | Shipping line or its agent to Container terminal | Vessel call planned | Container list, vessel, voyage, discharge and load details | Carrier system to terminal system | Terminal works to the carrier’s plan |
| COARRI · 322 Container discharge/loading report UN/EDIFACT; ANSI X12 | The terminal reports containers discharged from or loaded onto a vessel. X12 322 reports terminal activity such as ingates and outgates. | Container terminal to Shipping line or its agent | Container loaded or discharged | Container number, vessel, voyage, date and time, position | Terminal system to carrier system | Loading and discharge confirmed |
| CODECO Container gate UN/EDIFACT | The terminal or depot confirms containers delivered or picked up by an inland carrier. | Terminal, depot or container freight station to Shipping line or equipment owner | Container gates in or out | Container number, gate-in or gate-out, date and time, trucker | Terminal or depot system to carrier system | Free-time and equipment clocks based on real gate events |
| COREOR · 317 Container release order and delivery/pickup order UN/EDIFACT; ANSI X12 | COREOR releases containers to a named party. X12 317 lets importers or their agents order a marine terminal operator to deliver or pick up goods. | Shipping line, or importer or its agent to Terminal or depot, or marine terminal operator | Freight paid and documents in order | Container number, authorized party, release details | Carrier or brokerage system to terminal system | Containers released to the right party |
Container tracking, arrival notices and vessel messages
Tracking and arrival messages feed the visibility that consignees, brokers and planners rely on. They are the main defence against surprises at the port.
| Transaction | Purpose | Sender → receiver | Trigger | Key data | Connected systems | Business benefit |
|---|---|---|---|---|---|---|
| 315 · IFTSTA · DCSA Track and Trace Container status and events ANSI X12; UN/EDIFACT; DCSA | Reports status or event details for shipments or containers, such as gate, load, discharge and delivery. | Ocean carrier, forwarder or terminal to Shipper, consignee or agreed party | Container event occurs | Container and bill of lading references, event type, date and time, location | Carrier and terminal systems to TMS or visibility tool | Milestones and free time visible in your own systems |
| 312 · IFTMAN · DCSA Arrival Notice Arrival notice ANSI X12; UN/EDIFACT; DCSA | Gives the consignee what it needs to receive a shipment, including estimated arrival and charges due. | Carrier or forwarder to Consignee, notify party or agent | Vessel approaching the destination port | Estimated arrival, bill of lading, containers, charges and release information | Carrier system to consignee, broker or ERP | Clearance and pickup planned before free time runs |
| BAPLIE Bayplan and stowage plan UN/EDIFACT | Describes which containers are loaded in which positions on a vessel. CBP lists stow plans among vessel filings and SMDG publishes the implementation guideline. | Vessel operator or carrier to Terminal at the next port, carrier or vessel planner | Vessel loaded or about to arrive | Container positions on the vessel, weights, port of discharge | Carrier and terminal planning systems | Terminals prepared for what is on board |
Freight invoices, customs filings and acknowledgments
Invoices and customs filings close the shipment. For goods arriving in the United States by vessel, the carrier files the manifest and the importer or its agent files the Importer Security Filing with U.S. Customs and Border Protection.
| Transaction | Purpose | Sender → receiver | Trigger | Key data | Connected systems | Business benefit |
|---|---|---|---|---|---|---|
| INVOIC Invoice UN/EDIFACT | Bills freight and related charges in EDIFACT. | Carrier or forwarder to Shipper or payer | Billing event | Bill of lading, container numbers, charges, totals | Carrier billing system to ERP or freight audit | Invoices audited against the shipment |
| Demurrage and detention invoices Demurrage and detention billing FMC 46 CFR Part 541 | Under the FMC rule, an invoice must identify the bill of lading, container numbers, port of discharge for imports and the basis for why the billed party is liable, and must be issued within 30 calendar days from when the charge was last incurred. | Billing party to Billed party | Free time ends and a charge is incurred | Bill of lading, container numbers, port of discharge, charge dates and basis for liability | Carrier or terminal billing system to ERP or freight audit | Charges checked against container events and invoice requirements |
| 309, 350, 353, 355, 356, 357, 997 Customs manifest and status messages ANSI X12 (CBP ACE ocean manifest) | CBP lists these X12 messages for the ACE ocean manifest: the 309 customs manifest, and the 350, 353, 355, 356, 357 and 997 for status, events, acceptance or rejection, permit to transfer, in-bond and acknowledgment. | Carrier or NVOCC, and CBP for responses to U.S. Customs and Border Protection, and the filer for responses | Before vessel arrival, per CBP rules | Bill of lading, shipper and consignee, cargo description, containers | Carrier and customs filing systems to CBP systems | Manifest data filed and answered electronically |
| ISF (309 with security filing) Importer Security Filing ANSI X12 (CBP ISF) | CBP’s ISF rule applies to import cargo arriving in the United States by vessel. CBP lists the ISF-10 and ISF-5 filings with ISF status and acceptance or rejection messages. | ISF importer or its agent to U.S. Customs and Border Protection | Before the cargo arrives, per CBP rules | The importer, shipment and cargo data that CBP’s ISF requirements specify | Importer or broker systems to CBP | Filings made and corrected on time |
| 997 / 999 · CONTRL · APERAK Acknowledgments and application responses ANSI X12; UN/EDIFACT | Acknowledge whether a file or interchange could be read (997, 999, CONTRL) or report application-level errors (APERAK). They are not the carrier’s acceptance of a booking or instruction. | Receiver of the file to Sender of the file | Receipt of any file | Accepted or rejected status and error detail | EDI translation and monitoring layer | Unreceived or rejected files noticed quickly |
Carrier, terminal and customs workflows compared
An ocean shipment touches three different kinds of partner, and each has its own messages, owner and timing. Scoping them separately avoids missing a flow.
| Criteria | Ocean carrier or NVOCC | Marine terminal or depot | Customs (U.S.) |
|---|---|---|---|
| What it handles | Booking, shipping instructions, bill of lading, tracking, arrival notice and freight invoice | Container gates, loading and discharge, release and equipment movements | Manifest and security filings, status and responses |
| Typical messages | 300, 301, 303, 304, 310, 312, 315; IFTMBF, IFTMBC, IFTMIN, IFTSTA, IFTMAN; DCSA Booking, Track and Trace, Arrival Notice | 322, 317; COPARN, COPRAR, COARRI, CODECO, COREOR; BAPLIE | 309, 350, 353, 355, 356, 357 and 997 for the ACE ocean manifest; ISF filing and status messages |
| Who usually exchanges them | Shipper or forwarder with the carrier | Mostly the carrier or its agent with the terminal; shippers see events through the carrier | Carrier or NVOCC for the manifest, importer or its agent for the security filing |
| What to confirm with the partner | Accepted standards, versions, cutoffs and codes | Which events you will receive, and through whom | Who files, what deadlines apply and how responses reach you |
Systems
Ocean documents, evidence and exceptions
This diagram replaces the earlier sample-data dashboard. It follows the documents and evidence that accompany a container and the exceptions that most often interrupt it, so you can see where the Exception Management Center and Transaction Life Cycle Manager apply.
Systems an ocean freight integration connects
Ocean data starts in several systems and ends in several more. Integration scope usually covers the ones below, and the right mix depends on whether you are a shipper, a forwarder or an NVOCC.
| System | What flows | What to plan for |
|---|---|---|
| TMS and forwarding system | Bookings, shipping instructions, VGM, status and freight charges. | The system of record for the shipment; its references must reach every message and invoice unchanged. ECOM integrates TMS environments including Oracle Transportation Management; connector availability depends on the product and version. |
| ERP and accounting | Order and shipment references, freight accruals, carrier invoices and payments. | Invoices are audited against bookings and bills of lading before payment. |
| Warehouse and yard systems | Cargo readiness, container loading, weights and empty returns. | Weights from packing feed the verified gross mass, and gate events feed free-time tracking. |
| Carrier and NVOCC systems | Booking confirmations, bills of lading, status, arrival notices and invoices. | Each carrier defines its own versions, codes and connection method. |
| Terminal and depot systems | Container announcements, release orders, gate events and loading and discharge reports. | Messages are usually exchanged with the carrier, so shippers receive terminal events through the carrier or its status messages. |
| Customs and brokerage systems | Manifest, security filing and customs status data. | Filing responsibility and deadlines come from U.S. Customs and Border Protection and the filer. |
Problems and exceptions
Ocean freight integration problems and how ECOM addresses them
These are the problems that most often bring ocean shippers and forwarders to integration.
| Problem | Why it hurts | How ECOM addresses it |
|---|---|---|
| Manual booking and shipping-instruction entry | Bookings and instructions are keyed into one portal per carrier, so errors creep in and your systems and the carrier disagree. | Mapping from your TMS, ERP or forwarding system to each carrier’s X12, EDIFACT or API format, with connectivity over the method the carrier supports. |
| Shipping-instruction and VGM cutoffs | A missed instruction or VGM cutoff can mean a rolled container or late bill of lading, and nobody notices until the cutoff has passed. | Cutoff dates from booking confirmations tracked per shipment, with alerts when instructions or VGM have not been sent or acknowledged. |
| Container visibility gaps that can contribute to demurrage and detention | When gate, discharge and arrival events do not reach your systems, free time runs out unseen and charges can follow. Seeing the clock sooner gives teams time to act. | Status and gate events mapped to consistent milestones, with free-time information shown beside the container and alerts on containers with no expected event. |
| Rejected messages and bill of lading corrections | Instruction or VGM errors come back as rejections close to the cutoff, and bill of lading amendments cost time. | Validation before sending, rejections matched to the shipment and scenario tests of amendments and rejections before go-live. |
| Freight and demurrage invoice discrepancies | Invoices that do not match the booking, bill of lading or container events are disputed by hand and paid late. | Invoice data mapped to your ERP with bill of lading and container numbers intact, so charges can be compared with the shipment and container events. |
| Slow carrier onboarding | Each carrier has its own specification, accepted standards and test process, so new connections take longer than the business wants. | Specification review, reusable maps, partner testing and tracking through to production, then monitoring and 24×7 support. |
Handling ocean exceptions before the cutoff
Exceptions are normal in ocean shipping. What matters is that they are detected, routed to someone and corrected with the original booking and container references attached.
| Exception | Typical cause | How it is handled |
|---|---|---|
| Booking pending, conditionally accepted or rejected | Space or equipment is not available, or the carrier requires changes. | The confirmation status is matched to the booking and routed to the planner, and a replacement or amended booking is tracked to confirmation. |
| Shipping instructions missing or different from the booking | Late cargo details or changes after the booking. | Bookings approaching the instruction cutoff without instructions are flagged, and differences are shown before the instruction is sent. |
| Arrival notice or release delayed | Late notice, a customs or freight hold, or outstanding payment. | The delay is routed to the consignee or broker with the container and bill of lading references. |
Get started
How an ocean freight integration project works with ECOM
Every carrier, terminal and customs system specifies its own requirements, so the work starts with your partner and the problem you are solving.
- 01
Tell us the carrier, systems and problem
Use the contact form or call, and describe which carriers you ship with, which flows you need and where cutoffs or container visibility are causing trouble.
- 02
Review the specification
An ECOM specialist reviews the carrier specification: accepted standards, versions, codes, cutoffs, connection method and test process.
- 03
Agree scope and approach
We outline the messages or APIs, mapping, connections and testing involved, and separate carrier, terminal and customs flows so none is missed.
- 04
Build and test with the partner
Maps and connections are built, then tested with the partner using realistic scenarios such as amendments, VGM corrections and rejections.
- 05
Go live and monitor
Production starts with monitoring in place, and 24×7 support is available with coverage defined in your service agreement.
Helpful to share, never required
- The ocean carrier, terminal or other partner you need to connect with
- Its specification or onboarding document, if you have one
- Your current systems, for example TMS, ERP, forwarding and customs systems
- The transactions or APIs you need, for example booking, shipping instructions, VGM, tracking or invoices
- The business problem you want to solve, such as cutoff misses or container visibility
- Your target timeline
Have a carrier specification? Send it for review Call Sales: 972-836-7750
Sources
Sources and related pages
Standards and partner requirements are revised over time, and each trading partner publishes its own. Confirm current versions with the partner before you build.
Standards and public sources
- DCSA standards (reference documentation)Standard interfaces and current releases: Booking, Track and Trace, Verified Gross Mass, Bill of Lading, Arrival Notice, Commercial Schedules and Operational Vessel Schedules.
- DCSADCSA’s description of its founding in 2019 and its mission.
- DCSA Commercial Schedules standardPurpose of the Commercial Schedules standard.
- SMDG EDIFACT message implementation guidelinesGuidelines for the container messages, including COPARN, COPRAR, COARRI, CODECO and COREOR.
- SMDG VERMAS guidelineThe EDIFACT message for verified gross mass.
- ASC X12 transaction setsOfficial names and purposes of the 300, 301, 303, 304, 309, 310, 312, 315, 317, 322 and 323 transaction sets.
- U.S. CBP: ACE import manifest documentationX12 messages CBP lists for the ACE ocean manifest.
- U.S. CBP: Importer Security Filing (10+2)ISF applies to import cargo arriving in the United States by vessel.
- U.S. CBP: ISF frequently asked questionsImporter and agent responsibilities and ISF messaging.
- U.S. CBP: stow plans and container status messagesStow plan and container status message formats CBP lists, including BAPLIE, 322, 315, CODECO and COARRI.
- UK Maritime and Coastguard Agency: MGN 534 (SOLAS VGM)SOLAS verified gross mass: effective July 1, 2016, shipper responsibility, and the two methods.
- 46 CFR Part 541: Demurrage and detentionFMC billing requirements, including invoice contents (§ 541.6) and issuance (§ 541.7).
Related pages
- EDI 300 Reservation (Booking Request) (Ocean)The X12 booking request in detail.
- EDI 304 Shipping InstructionsThe X12 shipping instructions in detail.
- EDI 315 Status Details (Ocean)Container status and events.
- VERMAS verified gross massThe EDIFACT VGM message in detail.
- Transportation and logistics EDIAll modes: truck, rail, ocean and air.
- Air cargo EDI and API integrationAir waybill, status and freight invoice integration.
- Rail freight EDI and API integrationRailroad transactions, interchange and equipment visibility.
- Logistics trading partner guidesIntegration guides for logistics providers.
- Trading partner onboardingHow certification and onboarding run.
- Carriers & Freight TransportationRoad, rail, ocean, air, intermodal and cross-border freight: freight onboarding, systems connectivity, exceptions and delivery evidence.
- Customs and Cross-Border Process AutomationIntegration and process automation for cross-border documents, broker data exchange, validation and clearance-status exchange. Not customs brokerage.
- Intermodal Transportation IntegrationIntegration for truck to rail to truck and truck to ocean to truck moves: references, equipment identifiers, handoff events, documents and exceptions.
- Logistics AutomationAutomate tenders, status updates, freight invoices and warehouse orders with logistics partners.
FAQs
Frequently asked questions
What is ocean freight EDI?
Ocean freight EDI is the exchange of structured messages between shippers, forwarders, ocean carriers, terminals and customs systems for bookings, shipping instructions, bills of lading, container status, arrival notices and invoices. ANSI X12 and UN/EDIFACT are the two traditional standards, and carriers increasingly offer APIs as well.
What is DCSA and how does it relate to carrier APIs?
The Digital Container Shipping Association (DCSA) was founded in 2019 by major ocean carriers to establish IT standards for interoperability in container shipping. It publishes standard interfaces such as Booking, Track and Trace, Verified Gross Mass and Arrival Notice. Which DCSA interfaces a given carrier offers, and in which versions, is set by the carrier.
What is the difference between the X12 300 and the EDIFACT IFTMBF?
Both request a booking. The X12 300 Reservation (Booking Request) (Ocean) is the North American X12 transaction set, while IFTMBF is the UN/EDIFACT firm booking message. A carrier confirms with the X12 301 or the EDIFACT IFTMBC. Which one you use depends on what the carrier accepts.
What is VGM and how is it sent to the carrier?
Under the SOLAS container weight rules, which apply from July 1, 2016, the shipper is responsible for the verified gross mass of a packed container, and the container should not be loaded unless the master and terminal representative have it in advance. Carriers accept it in different ways, for example the EDIFACT VERMAS message, the DCSA Verified Gross Mass interface, a portal or another agreed format, so confirm the method with each carrier.
Which messages track a container?
The X12 315 Status Details (Ocean), the EDIFACT IFTSTA status report and the DCSA Track and Trace interface report container events. Terminal and depot events travel as the container messages CODECO for gates and COARRI for loading and discharge, usually between the terminal and the carrier.
Can integration prevent demurrage and detention charges?
No. Carriers set and bill those charges, and integration does not remove them. Container visibility can help you see free time running out sooner and act on it, and invoice data helps you check charges. U.S. Federal Maritime Commission rules in 46 CFR Part 541 set minimum content and timing for demurrage and detention invoices.
Do I need separate integrations for the carrier, terminal and customs?
Usually yes, because they are different parties with different messages. Carriers handle booking, instructions and billing, terminals handle gate and vessel events, and U.S. Customs and Border Protection handles manifest and importer security filings. Scoping them separately avoids missing a flow.
What should I send ECOM to get started?
The carrier, terminal or other partner you need to connect with and its specification if you have it, your current systems, the transactions or APIs you need, the business problem and your target timeline. You do not need a finished specification to start the conversation.
Discuss the ocean freight flows you need to automate
Tell us the carrier, your systems and where cutoffs or container visibility are causing trouble. An ECOM specialist will review the messages, APIs and testing involved.