EDI for small carriers: what it is, when it pays, and when it does not

You win a customer. Somewhere in the onboarding pack, between the insurance certificate and the rate sheet, sits a line that reads EDI required. Nobody on the customer’s side can quite explain what it means, and the first quote you get back for it arrives with a project plan attached.

Here is what is actually behind that line, and how to work out whether it is worth doing.

EDI is a format, a pipe, and an agreement

Electronic Data Interchange means two companies’ systems exchanging business documents in an agreed structured format, so that nobody retypes anything. In European road freight that format is usually UN/EDIFACT, a United Nations standard published through UNECE as versioned directories. Each message type has a six-letter name, and each directory has a release: the current published definition of the transport instruction, for example, is directory D.23A, revision 17, dated 21 July 2023. Your customer will name a version, and it matters.

The standard covers the content and syntax of the message — the syntax rules themselves are ISO 9735. It says nothing about how the file gets from their server to yours. The format and the pipe are two separate agreements, and confusing them is the most common reason a first EDI conversation goes in circles.

Three messages carry almost all of the work

For a carrier, the useful shape is orders in, statuses out, invoices out.

Orders in — IFTMIN

Officially the Instruction message. UNECE defines it as a message from the party issuing an instruction regarding forwarding or transport services for a consignment under agreed conditions, to the party arranging those services. In plain terms: the customer’s transport order, arriving as a file instead of an email.

Two details are worth knowing. It is a single-consignment message, aligned with the separate booking messages (IFTMBP, IFTMBF, IFTMBC) — so if your customer talks about booking EDI, check which one they mean. And UNECE’s own principles note that the instruction results in a transport contract and is primarily meant for administrative purposes. It is the order, not the dispatch plan.

Statuses out — IFTSTA

The International multimodal status report message: a message to report the transport status, or a change in it, between agreed parties. It covers the physical movement of consignments, goods or equipment at any point in the transport chain.

UNECE lists four ways it can be sent — on request, on a schedule at predetermined times, when selected events occur, or on an exceptional event as agreed between the partners. That list is the negotiation. Committing to loaded, arrived, delivered and exception is a very different operational promise from committing to every status change the moment it happens, and the difference lands squarely on your drivers.

Invoices out — INVOIC

The Invoice message: a message claiming payment for goods or services supplied under conditions agreed between seller and buyer. Usefully, with the right data qualification the same message also serves as a credit note and a debit note, so corrections do not need a separate message type. If invoicing is the part of your week that hurts, this is the one to do first — and it pairs with getting the invoice out on the delivery day.

Two messages nobody mentions until something breaks

CONTRL, the syntax and service report message, syntactically acknowledges or rejects a received interchange, group or message. It tells you the envelope arrived and was well-formed.

APERAK, the application error and acknowledgement message, does two jobs: it tells a sender that their message reached the addressee’s application and was rejected because of errors found while processing it, or it acknowledges that the application received it.

The distinction matters at four o’clock on a Friday. Silence where a CONTRL should be means the file never arrived. An APERAK rejection means it arrived and their system refused it — a different problem with a different fix. Agree both up front, or we never received your invoice becomes an argument neither side can settle.

What setup genuinely involves

1. Their implementation guideline. Nobody sends bare EDIFACT. Customers issue a subset document specifying which segments they use, which qualifiers, and which of the standard’s optional fields are mandatory for them. It runs to dozens of pages. Two customers both on IFTMIN will not be identical, and that single fact drives the economics more than anything else here.
2. Code mapping. Their location codes, goods codes and status codes against yours. Rarely difficult, reliably slow, and it exposes every inconsistency in your own master data.
3. The connection. The channel, the credentials, and — the part that gets skipped — who notices when it stops.
4. Testing. Sample files, corrections, then a parallel period where EDI and email both run. Budget properly for the parallel period; it is where the mismatches actually surface.
5. Ownership afterwards. Directory versions move, guidelines get revised, someone adds a code. EDI is not a project that finishes.

The honest break-even

The costs are mostly fixed and mostly up front: reading the guideline, mapping the codes, testing. The benefits are per message: an order not retyped, a status call not answered, an invoice not queried. So the arithmetic is about recurring volume and duration, not about prestige:

• How many orders a month, and is the work contracted or spot?
• Is the flow one-directional? Orders in, with statuses still going out by phone, captures a fraction of the benefit.
• Will one mapping serve several customers? One guideline covering three customers changes the sums. Three guidelines for three customers does not.

A customer sending several loads a day on a multi-year contract repays the setup. A single customer sending a handful of loads a month because EDI was a box on their tender does not — and saying so is a legitimate commercial conversation, not a failure to modernise. Ask what else they will accept: a customer portal, a file drop, or an API. Very often EDI required translates as we will not retype your emails, and a customer portal answers that too, without a guideline.

What to ask before you say yes

• Which messages, in which direction? (Orders in, statuses out, invoices out is the common shape.)
• Which directory version, and whose implementation guideline?
• Which status events, at what frequency, and measured against what?
• Which acknowledgements — CONTRL, APERAK, or both?
• Who pays for the setup, and who pays when their guideline is revised?
• What happens when the link is down: does the work stop, or is there a fallback?

Those six questions turn an intimidating requirement into a scoped one. They also, quite often, reveal that what the customer needs is smaller than the word suggested. The same instinct applies when choosing the system underneath it.

Where navichain fits

The difference between EDI as a project and EDI as a setting is mostly whether your system already speaks it. navichain lists EDIFACT among its freight-partner integrations alongside Opter, LogTrade and Fraktjakt, with a REST API for ERP and TMS integration and a customer portal for the customers who do not need EDI at all — and because every feature is included on every plan, winning an EDI customer does not move you up a price tier. The platform page sets out what is inside, and pricing starts at 995 kr a month.