EDI Integration for European Road Freight

EDI is not the legacy half of your network. It is the compliant half

Retail mandates it, automotive is built on it, and freight invoicing runs on it. Treating EDI as something to migrate away from is how shippers end up with two parallel truths: an API feed for the carriers who could support one and a file feed for the ones who matter most commercially.

The workable architecture is not a migration. Both channels land in the same place, normalise into the same internal event, and nothing downstream learns which channel a fact arrived on. Choosing between them per partner is the subject of API against EDI in road freight.

Messages we exchange

How the files actually move

AS2 for partners who already run it, SFTP where a simpler drop is acceptable, and OFTP2 where automotive requires it. Value-added networks are supported where a partner insists, though the per-volume charge is worth checking before you commit a high-frequency status flow to one.

Cadence matters more than transport. A status file transmitted hourly gives you a record rather than visibility, which is fine for invoicing and useless for a dispatcher. Where a partner can only send on a long cadence, their milestone data is reconciliation and their live position comes from telematics instead. The two are complementary rather than alternatives.

Mapping, and why it is per partner even when everyone is compliant

Conformance does not settle meaning. Two carriers can both send a standards-compliant IFTSTA and populate it differently, and the recurring disagreement is what counts as arrival: reaching the gate, reaching the dock, or the moment the driver reports it.

So the mapping is agreed explicitly, field by field, and stored against the partner. Every inbound message gets an idempotency key built from the shipment reference, the status and the event time, because files get resent and a duplicated arrival doubles recorded dwell. Events are ordered by event time rather than receipt time, since a departure routinely arrives in a file before the arrival it follows. The status code detail sits in the guide to EDI 214 and IFTSTA status messages.

eCMR and eFTI, the part with a deadline

Regulation 2020/1056 requires competent authorities across the EU to accept freight information in electronic form, and the practical consequence for a shipper is that the consignment note stops being a paper artefact that travels in the cab and becomes structured data that has to be produced on request.

That changes what the document flow has to carry: the consignment data itself, the signature events, and an audit trail tying both to the load. The document side is covered on the eCMR software page, and how the electronic consignment note behaves against paper in practice is set out in eCMR against paper CMR.

The seven weeks

GO LIVE is guaranteed in seven weeks, and the schedule is the same on every integration because the platform side never changes. What varies is how quickly your side can supply a test system and a named contact.

1. Weeks 1–2, scoping. We agree the field list, the direction of each field and which system is authoritative for it. This is the meeting that decides whether the project is easy, and skipping it is why integrations drift.
2. Weeks 3–4, connection. Credentials, endpoints and a first message moving in a test environment. Nothing is mapped yet, we are proving the pipe.
3. Week 5, mapping and events. Your fields onto our event model, including the definition of arrival, which is the single most disputed one.
4. Week 6, parallel run. Both systems live, event counts compared daily. Any gap is a mapping bug found before anybody depends on it.
5. Week 7, cutover and handover. Downstream consumers switch, monitoring is handed to your team with the reconciliation report that tells you when a feed goes quiet.

Data residency, GDPR and ISO 27001

Freight data is operational data about identifiable drivers and vehicles, so it falls under GDPR whichever way it reaches us. Three things are usually asked in a European security review, and the answers do not change per integration.

• Where the data sits. Processing and storage stay within the EU.
• Who can see it. Your freight data stays inside your trusted carrier network. A carrier sees the loads they are assigned, not your wider network.
• How it is governed. TrucksOnTheMap is ISO 27001 certified, and the controls that matter to a transport integration are access control, retention and the audit trail on every event.

Position data has a retention question of its own. Decide up front how long raw pings are kept as against derived events, because the derived events are what your KPIs need and the raw trace is what a works council will ask about.

Common questions

Which EDI messages do you support for road freight?

EDIFACT IFTMIN for the transport instruction, IFTMBF and IFTMBC for booking request and confirmation, IFTSTA for status, IFTMAN for the arrival notice, DESADV where the receiving site books against a despatch advice, and INVOIC for freight invoicing and self-billing. X12 204, 214 and 210 are supported where a North American partner is involved.

How do EDI files reach you?

AS2 for partners already running it, SFTP where a simpler drop is acceptable, and OFTP2 where automotive requires it. Value-added networks are supported where a partner insists, though the per-volume charge is worth checking before committing a high-frequency status flow to one.

Why does an EDI mapping have to be agreed per partner?

Because conformance does not settle meaning. Two carriers can both send a standards-compliant IFTSTA and populate it differently, and the recurring disagreement is what counts as arrival: the gate, the dock, or the moment the driver reports it. The mapping is therefore agreed field by field and stored against the partner.

Can EDI and API feeds coexist without producing two versions of the truth?

Yes, through one internal event model that both channels map into at the edge. Each event carries its source and whether its timestamp was machine-generated or keyed, every inbound message gets an idempotency key built from reference, status and event time so resends cannot duplicate an arrival, and events are ordered by event time rather than receipt time.

What does eFTI mean for our EDI flows?

Regulation 2020/1056 requires competent authorities across the EU to accept freight information electronically, so the consignment note becomes structured data that must be producible on request rather than paper travelling in the cab. The document flow therefore has to carry the consignment data, the signature events and an audit trail tying both to the load.

Send us one sample file

A real IFTSTA or 214 from your largest carrier tells us more in ten minutes than a scoping workshop does in a day.