EDI in logistics: why message exchange still runs the industry

A message is an agreement, not a file format

Standards define syntax and code lists, and partners then agree an implementation: which segments are used, which optional fields are mandatory between the two of you, what your identifiers mean, how quantities and units are expressed, and how exceptions are represented. That agreement, usually written as an implementation guideline, is the real artefact. Two partners can both claim to support the same standard message and still fail to exchange anything useful, which is why an experienced integrator asks for the guideline before discussing timelines.

Onboarding: the cost nobody forecasts correctly

Each partner connection requires mapping between their message and your internal model, agreeing identifiers for locations, products and parties, establishing transport and security arrangements, testing with realistic data, and running a period of parallel operation. Almost none of that is reusable beyond the first partner of a given type, and the calendar time is usually driven by the partner's availability rather than by your development effort. Programmes that budget one integration and repeat it fifty times discover that partner count, not message complexity, is the variable that matters.

Acknowledgements, and the silence problem

The operational risk in batch messaging is that nothing arrives and nobody notices. Functional acknowledgements confirm receipt and syntactic acceptance; business responses confirm the content was processed. Without both, a failed transmission is discovered when goods appear unannounced or a customer asks about an order nobody has. Monitoring should therefore alert on expected messages that did not arrive, not only on messages that arrived and failed, and that expectation needs to be modelled per partner and per schedule.

Air, sea and customs each brought their own vocabularies

Air cargo has long-established messaging for bookings, status and consignment data; maritime and port communities developed their own; customs administrations exchange declarations and responses in nationally specified formats derived from international data models. A logistics operator of any size therefore maintains several message families at once, and the internal canonical model that sits between them is what stops each new connection from touching every application.

Why it persists

Batch messaging fits the rhythm of much logistics work, where despatches close at a cut-off and receipts are confirmed after unloading. It is well understood, it survives brief outages by queueing, and an enormous installed base of working connections would cost more to replace than to maintain. New integrations increasingly use interfaces that respond immediately, but the sensible framing is coexistence: choose the mechanism per interaction based on whether a decision waits on the answer.

Frequently asked questions

Should new partner integrations still use messaging?

Where the exchange is scheduled and high volume, it remains a good fit and the partner probably already supports it. Where a decision waits on an immediate answer, such as a booking confirmation or a price, an interactive interface is the better choice.

How many partners can one team realistically onboard?

Fewer than sponsors expect, because the constraint is partner availability and testing cycles rather than internal development. Prioritising by volume and accepting portals for the long tail is the usual practical compromise.

What reduces the cost of each new connection?

A stable internal canonical model, a published implementation guideline of your own, reusable transport and security configuration, and a test harness with realistic data. Together these convert a bespoke project into a repeatable configuration exercise.