transportkoppeling.nl
home / edi-integrations
EDI integration

EDI integration for your TMS: orders, status updates and invoices, automated

An EDI integration automates the message exchange between your TMS and your customers, carriers and platforms. Orders, transport orders, status updates and documents flow through automatically, with no retyping and no errors.

Without obligation · reply within one working day

What is an EDI integration?

Your planning talks directly to your customer’s

EDI (Electronic Data Interchange) is the standardised, automatic exchange of business messages (orders, transport orders, status updates and documents) between your system and those of your supply-chain partners. No more emails with PDFs that someone has to retype, but messages that are read straight into both systems. New to the terminology? See our EDI glossary.

We design, build and support these integrations for transport and logistics companies. You keep working in the TMS you know; we make sure it communicates flawlessly with the rest of the chain.

Formats

EDIFACT XML CSV JSON BORD512 XLSX TEXT

Protocols

AS2 SFTP OFTP2 SOCKET

Which messages we integrate

  • Orders & order confirmations (ORDERS, ORDRSP)
  • Transport order & consignment note (IFTMIN)
  • Status messages (IFTSTA)
  • Invoices (INVOIC)
  • Stock & stock movement messages
  • Validation & error reporting
Result

Fewer errors, shorter lead times and no double entry: your planning talks directly to your customer’s.

The messages in practice

Which message does what in a transport chain

In transport, EDI revolves around a handful of standard messages. Each message belongs to a specific moment in the trip. This is what the chain looks like for a shipper that uses a carrier:

IFTMIN
shipper → carrier

The transport order: loading and delivery address, time windows, packages, weights, references and special requirements such as ADR.

IFTSTA
carrier → shipper

The status of the shipment: loaded, in transit, delivered or an exception, with a timestamp and, where available, the name of the recipient.

INVOIC
carrier → shipper

The invoice, per trip or per period, with lines the shipper can automatically match against its own orders.

ORDERS / ORDRSP
customer ⇄ supplier

An order and its confirmation, for example between a wholesaler and its warehouse.

DESADV
supplier → recipient

The advance notice of a delivery (ASN), so the receiving warehouse knows what is coming.

Not every partner sends EDIFACT. Many shippers use their own XML or CSV format, and Dutch road transport also uses the TLN format (from the Dutch transport and logistics association). For the integration, that makes little difference: we translate the partner’s format into what your TMS can import, and vice versa. All the terms are explained in our EDI glossary.

How it works

One order, from instruction to invoice

Take a shipper that sends a carrier thirty transport orders every day. With EDI, it works like this:

  1. 01

    The order comes in

    The shipper’s system sends an IFTMIN via AS2 or SFTP. We translate it into an order in your TMS, with the right customer, addresses and time windows. An amendment or cancellation updates the same order.

  2. 02

    The planner plans

    The order appears on the planning board straight away, without retyping. If something is wrong, such as an unknown address, it is flagged before the trip leaves.

  3. 03

    Status updates go back

    When the driver loads or unloads, an IFTSTA goes to the shipper automatically. The shipper sees in its own system that the shipment is in transit or delivered.

  4. 04

    The invoice follows automatically

    At the end of the period, the invoice goes to the shipper as an INVOIC, with lines that match its orders exactly. That saves discussion about what was and wasn’t driven.

EDI or API?

When to use EDI, and when an API

EDI and an API do the same thing, namely exchanging data automatically between two systems, but in different ways. EDI uses fixed, agreed messages that are often sent in batches. An API is a direct, real-time connection in which one system requests data from the other or delivers data to it.

Choose EDI if…

your partner already uses it, which is usually the case with large shippers, retailers and platforms. You then connect to an existing standard, and your partner doesn’t have to build anything new.

Choose an API if…

speed matters, for example a status update that has to reach the customer within a minute, or if both systems have a modern API. See API integrations.

In practice we often combine the two: orders from a shipper via EDI, status updates from a subcontractor via its API, and everything arrives in the same place in your TMS. If a customer has no EDI or API at all, that can be handled too: see importing orders automatically without EDI. The difference is explained in more detail under what is EDI.

Cost and lead time

What an EDI integration costs and how long it takes

An honest answer starts with: it depends on a few things we can map out quickly. A standard interface is usually live within a few weeks. The difference between a simple and a large integration almost always comes down to the same points:

  • The number of message flows. Incoming orders only is less work than orders, status updates and invoices in both directions.
  • Whether the partner’s format is standard. An IFTMIN to a common specification is quicker to integrate than a proprietary format without documentation.
  • What your TMS can import. A package with a good import function or API saves a lot of time; see our pages on integrating your TMS and WMS.
  • How quickly test messages are available. In practice, waiting for test data from a partner causes the biggest delay, not the build itself.
  • Support after go-live. We monitor the integration and adapt it when a partner changes its messages. That makes the integration part of an ongoing arrangement, not a one-off project.

After an initial conversation, we send you a proposal with a fixed price for the build, so you know where you stand in advance. You can read how we approach this under how we work.

Frequently asked questions

EDI integrations in brief

What is the difference between EDI and an API integration?

EDI uses standardised messages (often sent in batches) and is the norm between shippers, carriers and platforms. An API integration is real-time and bidirectional. We often combine the two, and advise on what suits your partners. More background: what is EDI. If it concerns trips you subcontract, see carrier integration.

Does EDI work with my existing TMS?

Almost always. We have standard integrations with TMS packages such as Mendrix, Transpas and Qargo, and build custom solutions where needed.

How long does an EDI implementation take?

A standard interface is usually live within a few weeks. We first map your systems and message flows; see how we work.

Do I need to buy EDI software myself?

No. We take care of the translation and the connection with your partners. Your TMS only needs to be able to import orders and export status updates, and most packages can do that.

My customer is asking for AS2. What does that mean?

AS2 is a secure way of sending EDI messages over the internet, with certificates and an acknowledgement of receipt for every message. We set up the AS2 connection with your customer; you don’t need to configure anything yourself. See also the EDI glossary.

What happens if a message contains an error?

A message that is incorrect is held back and reported instead of being half-processed. We usually spot it before your planner does, and resolve it with you or with the partner.

Want to automate your EDI messages?

Book an introductory call, without obligation. Together we’ll look at your systems and partners and what an integration can do for you.