The Integration Ticket: How Finished-Vehicle Logistics Connects Over EDI

Why EDI is the entry ticket

Automotive supply chains run on tolerances measured in minutes. To feed just-in-time and just-in-sequence manufacturing, OEMs have mandated electronic data interchange for decades. Inbound parts logistics digitised long ago. Outbound finished-vehicle logistics lagged, and it is now catching up fast, because the manufacturers and the large shippers have made electronic connectivity a condition of doing business.

That changes what integration means for a carrier, forwarder, or terminal operator. It is no longer an IT line item you handle after winning the account. It is often what decides whether you win the account. A global equipment manufacturer moving vehicles by sea will ask, during the tender, how you exchange bookings, how you report status, and in which format. If the answer is "we will build it later," you are already behind an operator who can say "we already speak that."

So the practical question is not "should we do EDI." It is "which of the 3 worlds are we connecting to, with which messages, and how fast can we onboard." This paper answers that.

The 3 networks you connect to

Most confusion about automotive EDI comes from treating it as one system. There are 3, and they behave differently.

1. OEM-direct. You connect to a manufacturer's own specification and portal. The standard is regional: North American OEMs mandate ANSI ASC X12 (Ford, for example), while European and international OEMs mandate UN/EDIFACT (Mercedes-Benz) or the automotive ODETTE/VDA message family (Stellantis). Governance is strict, specs are detailed, and the manufacturer sets the pace.

2. Ocean-carrier networks. Carrier booking and status ride over shared platforms and value-added networks (a carrier booking network such as INTTRA, for example). These aggregate many carriers and shippers behind common message formats, so one connection reaches many counterparties.

3. Shipper and 4PL networks. A manufacturer's logistics program often runs inside a network operator that sits between the shipper, its forwarder, and the carriers. When a carrier onboards to that network, the roles are distinct: the manufacturer is the shipper, its freight forwarder books, the carrier moves the cargo, the network is the exchange, and your platform is the carrier's integrator into it.

A working operation touches all 3 at once. The art is not picking one. It is having a data model that can serve all 3 from the same shipment record.

The message catalog

This is the reference map: which message carries which business event, in each of the 3 standards. Treat it as the landscape. The exact message version and field semantics are always defined in each partner's implementation guide (MIG), so use this to orient, then map to the specific guide.

Two things this table makes obvious. First, the same business event has a different name in each world, which is exactly why a single integration project has to hold several vocabularies at once. Second, the ODETTE/VDA FV family is the one built specifically for finished vehicles, tracked by VIN, rather than adapted from container or parts logistics. That is the direction the industry is moving.

What a purpose-built FVL platform handles natively. Logisoft's platform runs a real X12 and EDIFACT engine (typed message models, not string assembly) across the subset that finished-vehicle work actually uses: ocean schedules (IFTSAI, X12 323), booking and shipping instructions (IFTMIN, IFTMBF, IFTMBC), transport status (IFTSTA, X12 315), bills of lading and OEM messages (X12 310, and Ford's 300/304/310/315/323/865 suite), acknowledgements and advice (824, 997), Stellantis X12 (540, 824, 856, 660, 997), and the ODETTE/VDA FV family in production (FV14, FV17, FV18). Visibility feeds that are REST or JSON rather than EDI are handled the same way, and a token-authenticated Export API pushes booking, stock, and forecast data downstream. The point is not the count of formats. It is that they all resolve to one shipment and one VIN.

Connection patterns and the onboarding sequence

Onboarding an automotive EDI link is governed by the manufacturer's quality regime (the IATF 16949 family), so it is deliberately staged. The sequence below is the one that plays out in practice.

Timelines are measured in months, and large OEM programs often run 1 to 3 years from kickoff to certified production, because the certification gates and the number of message types are the constraint, not the connection itself.

Where integrations break

EDI integrations rarely fail on the transport protocol. They fail on the business rules and the data. These are the recurring break points, drawn from real onboarding work.

• Version drift. A booking-request guide moves from V1.8 to V1.9, or a schema is reissued mid-project. One release even shipped without a namespace declaration. Without advance notice of schema changes, every drift is rework. Ask for it in writing at the start.
• Namespace and root mismatches. A message can be structurally valid and still rejected because the root element or namespace does not match what the partner expects.
• Missing mandatory elements. Fields that seem optional (nature of cargo, latest delivery, communication details) are mandatory for a given partner, and their absence fails the message.
• Status-granularity disputes. Two parties define an event differently. Is the status "vessel loaded" or "gate out"? If the message says one and the counterparty expects the other, the milestone is wrong even though the data flowed.
• Master-data misalignment. The quiet killer. Carrier codes (SCAC), booking numbers, and equipment check digits have to match on both sides. And underneath all of it, the VIN and the vehicle model or variant have to align, which is why a structured variant master and reliable VIN decoding matter as much as the message mapping.

Most of these are invisible until a message is rejected in production. A platform that validates against the partner's rules before sending, and that reconciles master data centrally, turns them from incidents into non-events.

In practice

A global equipment manufacturer's ocean program is a clean example of all 3 network types at once. The manufacturer is the shipper, its forwarder books, a RoRo carrier moves the cargo, and a value-added network sits in the middle. On the carrier's side, the integration delivered ocean schedules (EDIFACT IFTSAI and X12 323), XML booking over SFTP, and X12 315 track and trace, went into production in late 2025, and now runs live.

The OEM-direct pattern repeats across manufacturers on their own standards: Ford over X12, Mercedes-Benz over EDIFACT, Stellantis over the ODETTE/VDA FV family. Same shipment record, different vocabularies, one platform doing the translation.

Build, buy, or platform

3 ways to handle automotive EDI, and a checklist to judge any of them.

• Build in-house. Full control, but you own every OEM spec, every version bump, and every certification. Realistic only if integration is your core competency and you have the team to staff it for years.
• Point middleware. A generic EDI or iPaaS tool handles the transport and generic mapping, but it knows nothing about finished vehicles. You still build and maintain the automotive semantics (VIN keys, FV messages, RoRo and breakbulk variants) yourself.
• A finished-vehicle platform. The connectors and the vehicle data model ship together, so onboarding a new OEM is configuration against a known structure rather than a structural mapping project.

Where customs fits

EDI is one half of a single data problem. The same VIN, tariff code, and booking record that OEMs and carriers exchange over EDI also has to satisfy ICS2, ENS, and the national customs systems. Treating EDI and customs as one data spine, rather than two projects, is what removes the re-keying between them. That is the subject of our companion paper, the customs-compliance operating model for RoRo and finished-vehicle forwarding.

Sources

The message families and standards in this paper are attributed to their sources: Odette International and ECG (the "FV" finished-vehicle-logistics message family and message meanings), ASC X12 and UN/EDIFACT (standard transaction sets and message types), IATF 16949 (the automotive quality-management framework governing supplier onboarding), Fortune Business Insights (finished-vehicle logistics market size), and Port Economics (RoRo share of vehicle exports).

About Logisoft

Logisoft is a logistics software platform built specifically for RoRo and finished-vehicle logistics, used by ocean vehicle carriers, forwarders, and terminal operators to run bookings, yard and terminal operations, customs, and billing on one shipment record. Its integration layer speaks X12, EDIFACT, and the ODETTE/VDA FV family from that same record, so a new OEM, carrier, or shipper network is a configuration against a known data model rather than a fresh integration project. Logisoft is developed by INTRA Logisoft Labs, based in Nicosia, Cyprus. Learn more at logisoft.io.

To see one platform speak all three EDI worlds against a single VIN, book a demo.