Sending an EDIFACT IFTMIN Transport Order, Step by Step

If you've ever tried to find a working example of a UN/EDIFACT IFTMIN message, you already know the problem: the UNECE spec pages are dense reference tables and most vendor blogs stop at "we support EDIFACT" without ever showing you a segment. This walkthrough fixes that. By the end you'll have a transmittable EDIFACT IFTMIN message built segment by segment, sent to a road carrier over AS2, and confirmed at both the transport and business layers.

What IFTMIN Is and When You Need It

IFTMIN is the EDIFACT message a shipper sends to a carrier or freight forwarder to instruct a transport service for a specific consignment. Per the message definition, it's "a message from the party issuing an instruction regarding forwarding/transport services for a consignment under conditions agreed, to the party arranging the forwarding and/or transport services." If you work with X12 partners in North America, the closest equivalent is the EDI 304 Shipping Instructions message, since "the EDI ANSI X12 equivalent is EDI 304 Shipping Instructions (Ocean)."

IFTMIN doesn't work alone. It's the trigger for a whole chain: the carrier submits customs declarations, provides IFTSTA status updates back to the shipper, sends an IFTMAN arrival notice, and returns an IFTMCS contract status message. You'll typically fire an IFTMIN off the back of an ORDERS release, an emergency reroute, a dangerous goods load that needs DGS segment detail, or a seasonal capacity booking with a contracted carrier. This is standard practice with EDIFACT-first European road carriers like DB Schenker, Kuehne+Nagel, Dachser, Hellmann Worldwide Logistics, GLS, Hermes, and Gebrüder Weiss. Worth knowing before you start: several of these same carriers also run a parallel file-based protocol called FORTRAS, which is "a file-based connection with the same shortcomings" as EDIFACT, more in use in Germany and neighbouring countries. If a carrier gives you a choice, ask which one their integration team actually maintains actively — it's not always the one listed first in their onboarding pack.

Before You Start: What You Need

Don't open your EDI translator until you have these four things confirmed with the carrier:

• The carrier's IFTMIN implementation guide and confirmed directory version (D96A, D01B, or D04A) — these are not interchangeable, and a message built against the wrong version will fail validation even if every segment looks correct.
• An EDI translator or mapping tool that supports EDIFACT syntax, plus a reference table of GLN and UN/LOCODE codes for every ship-from and ship-to location you'll use.
• AS2 connectivity already provisioned with the carrier: exchanged AS2 identifiers and certificates, not just a stated intent to use AS2.
• A UAT or certification environment from the carrier where you can send test transmissions without them hitting a live dispatch board.

Building and Sending the IFTMIN: Step by Step

1. Confirm the IFTMIN version and mandatory segments. Pull the carrier's implementation guide and check which directory version they run. A message built to D96A syntax rules sent to a partner expecting D01B will often trigger a syntax rejection before it even reaches business validation.
2. Build the message skeleton: UNH, BGM, DTM. The UNH segment opens and uniquely identifies the message, referencing IFTMIN and the directory version. BGM carries the document name and your internal transport instruction number. DTM carries the requested pickup and delivery dates. Get these three right first — everything downstream references them.
3. Populate the party segments. Use NAD+CZ for the consignor (you, the shipper), NAD+CN for the consignee, and NAD+CA for the carrier. Use internationally recognized codes such as UN/LOCODE for ports and cities, IATA codes for airports, or GLN for specific facility addresses rather than free-text addresses — free text is exactly where mapping rejections happen.
4. Add the transport-stage segments: TDT and LOC. The TDT segment identifies the mode of transport using standard codes: 1 for maritime, 2 for rail, 3 for road — you'll use code 3 for a standard road-freight instruction. LOC segments carry the pickup and delivery locations, paired with DTM segments for the corresponding dates. Consistent location coding ensures that the carrier's systems can automatically identify pickup and delivery points, which matters more than it sounds like it should — inconsistent coding is a leading cause of manual intervention on the carrier side.
5. Add goods detail: GID, FTX, MEA, CNT. GID describes the goods item, FTX carries free-text cargo description, MEA carries weight and volume, and CNT gives package or unit counts. If the load is hazardous, add DGS segments here, since the IFTMIN includes DGS segments with the UN number, hazard class, and emergency contact information required by dangerous goods transport regulations.
6. Validate the built message against the implementation guide before you send anything. Run it through your translator's compliance checker, not just a generic EDIFACT syntax validator. A message can be syntactically valid EDIFACT and still fail the carrier's implementation guide rules around mandatory versus conditional segments for their specific setup.
7. Configure the AS2 channel. Exchange AS2-TO and AS2-FROM identifiers with the carrier, install their public certificate, and request a signed MDN on every transmission. Don't skip the signed MDN request to save a config step — it's the only reliable proof you have that the message arrived intact.
8. Send a test IFTMIN into the carrier's UAT environment. Confirm you get back a positive, signed MDN, and separately confirm the carrier's system generated a functional acknowledgment or test IFTMCS. Don't cut over on the MDN alone.
9. Cut over to production and monitor the reply chain. Watch for the carrier's IFTMCS contract-status response or the first IFTSTA milestone update, both of which confirm the order was picked up on their side, not just delivered to their AS2 endpoint.

How You Know It Actually Worked

You need two separate confirmations, and conflating them is the single most common mistake in self-built IFTMIN integrations. A positive, signed MDN only proves the carrier's AS2 gateway received and could parse the transport envelope. It says nothing about whether their transport management system accepted the order. That confirmation only comes from a business-level reply: an IFTMCS contract status message, or the first IFTSTA milestone showing the shipment has been picked up. If you only check the MDN, you'll find out about a rejected order when the truck doesn't show up, not when the message was sent.

Failure Mode 1: Negative or Missing MDN

This is a transport-layer problem, and it's almost always one of three things. According to Aayu Technologies' AS2 troubleshooting guide, the algorithm used to compute the MIC on the two ends can differ, the format of the MIC string can differ, or the payload itself can be altered or corrupted in transit. A subtler version of this shows up as a signature verification failure on your own side even though the transmission technically succeeded — in that case, the sender's AS2 system reports a signature verification failure for the received MDN even though the MDN itself could be marked as successful, and the fix is to ensure the receiver's signature/verification certificate is configured correctly on the sender's side. Before you escalate to the carrier's helpdesk, check your certificate expiry dates and confirm both sides are using the same MIC hash algorithm — this single mismatch accounts for a disproportionate share of "it just stopped working" tickets.

Failure Mode 2: Segment or Mapping Rejection

This is a translation and business-rules problem, not a transport problem, and it needs a different diagnostic approach. Cleo's troubleshooting framework recommends isolating which layer actually failed rather than guessing: check whether it's an EDI layer issue (envelope, schema, syntax, or implementation-guide problem), a transformation layer issue (map, route, or code-conversion problem), an application layer issue (TMS or WMS rejection), or a business layer issue (ship date, routing, or compliance rule). In practice, when a carrier's system throws back a rejection, it usually means the partner received the document but rejected it at the syntax or implementation-guide level, so you check syntax and map output, find the rejected segment or element, and compare it against the partner guide. Nine times out of ten the culprit is a mandatory segment your map treated as optional, a directory version mismatch, or a location code the carrier's system doesn't recognize because you used a facility GLN where they expected a UN/LOCODE.

Why Shippers Rarely Hand-Build This Per Carrier

Here's what catches most EDI teams off guard: none of this work is reusable across carriers. Every implementation guide is different, every carrier runs its own directory version, and the segment-level quirks you just debugged for DB Schenker won't necessarily apply to Kuehne+Nagel or Dachser. That's exactly why growing shippers stop hand-mapping IFTMIN per partner and move the whole problem into a transport management layer instead. TMS platforms like MercuryGate, Oracle Transportation Management, SAP TM, and Alpega handle multi-carrier EDI natively, and multi-carrier connectivity platforms such as Cargoson, Transporeon, and E2open take a different angle by maintaining the carrier connections themselves. Cargoson's approach is worth noting here specifically because it wraps EDIFACT- and FORTRAS-based carriers in a single API layer rather than asking you to re-map IFTMIN for every partner — "in its core, Cargoson is a multi-carrier shipping software designed to integrate seamlessly with your ERP system." If you're staring down a fifth or sixth carrier onboarding with a different directory version each time, that's the signal it's time to stop building bespoke maps and start evaluating a connectivity layer instead.

Checklist for Your Next Carrier Onboarding

• Confirmed directory version and implementation guide match between you and the carrier
• UNH, BGM, DTM skeleton built and validated against the guide
• NAD segments use GLN or UN/LOCODE, not free text
• TDT mode code and LOC pickup/delivery pairs correct
• GID/FTX/MEA/CNT populated, DGS added if hazardous
• AS2 certificates exchanged, signed MDN requested
• UAT test sent and confirmed with both a positive MDN and a business-level reply
• Production monitoring in place for IFTMCS or first IFTSTA milestone

Run through this list once per carrier and you'll catch most rejections before they hit production. If you find yourself running it for the fourth time this quarter, that's less an EDI problem and more a signal to look at consolidating your carrier connections.