How to Set Up EDIFACT IFTMIN Carrier Integration

Most European road freight carriers still won't accept a booking through a clean REST API. They want an EDIFACT IFTMIN message, and they'll send status updates back as IFTSTA. If your team is staring at a carrier onboarding pack full of segment codes and qualifiers, wondering where to start, this is the build guide. It walks through setting up an EDIFACT IFTMIN integration from scratch, mapping the fields that matter, testing against a real carrier environment, and handling the moment when the carrier's "standard" message turns out to have its own dialect.

Why EDIFACT still gates carrier onboarding for European shippers

Because most of the carriers you actually work with in the EU still run their systems on it. Automotive, industrial, and CPG companies standardize on EDIFACT for plants and suppliers outside North America. Unlike ANSI X12, which numbers its transaction sets, EDIFACT names messages by function: IFTMIN for instructions, IFTSTA for status. That naming convention is one of the few things about EDIFACT that's actually intuitive.

IFTMIN is used in European road freight and multimodal transport where EDIFACT is the carrier integration standard, and the message itself carries pickup and delivery locations, commodity, weights, service level, and references the commercial shipment, with NAD identifying shipper, consignee, and carrier, and TDT and EQD describing mode and equipment needs. It may pair with IFTSTA milestones until proof of delivery, which is exactly the pairing this guide sets up.

What you need before you start

Get these five things in place before you write a single map, or you'll be redoing work in week three.

• The carrier's Message Implementation Guide (MIG). Not the generic UN/EDIFACT spec, the carrier's own document. Confirm the exact version, D.96A and D.21A are still common in production despite newer releases existing.
• Your own identifiers. GLN or carrier-assigned EDI IDs for every shipper, consignee, and ship-from/ship-to location you'll reference in NAD and LOC segments.
• A confirmed connectivity channel. AS2, SFTP, or a VAN subscription. Ask the carrier directly which one they require, don't assume.
• An EDI translator or mapper. Something sitting between your TMS/ERP and the carrier connection that converts your internal shipment record into EDIFACT segments and back.
• A test or certification environment on the carrier's side. If they don't offer one, that's a red flag worth raising before you commit a go-live date.

Step-by-step: building the IFTMIN outbound connection

This is the sequence that actually works, in the order it needs to happen.

1. Request and read the carrier's IFTMIN MIG. Exact segment requirements depend on the message directory (D.96A, etc.) and your trading partner's implementation guide, so don't build against the generic spec and assume it'll match.
2. Set up the connectivity channel. Exchange AS2 certificates or SFTP credentials, and get your AS2 ID or VAN mailbox address confirmed in writing by the carrier's integration contact.
3. Map your TMS/ERP shipment fields to IFTMIN segments. At minimum you're mapping: BGM for instruction type and reference number, NAD for shipper, consignee and carrier parties, TDT for mode and means of transport, LOC for pickup and delivery locations, DTM for dates and times, and RFF for order or PO references. EDIFACT uses a hierarchical structure: UNH (message header) opens the transaction; BGM (beginning of message) carries the document name and reference; party data uses NAD; lines often use LIN with QTY, PRI, and MOA.
4. Generate a test IFTMIN file from a real, non-live shipment and submit it into the carrier's certification environment. Don't invent test data from scratch, use an actual completed shipment so the volumes, references and location codes are realistic.
5. Validate the CONTRL functional acknowledgment. A negative CONTRL means a segment or qualifier mismatch in the file, not that the shipment itself failed to process on the carrier's side. Fix the specific segment flagged and resend, don't rebuild the whole file.
6. Configure inbound IFTSTA parsing. IFTSTA is used in Electronic Data Interchange between trading partners involved in administration, commerce and transport to report status, and specifically a BGM segment indicates the beginning of the message and identifies the consignment for which status is being reported, while a LOC segment identifies a place or location which applies to the consignment such as consignment origin and destination. Map the carrier's status event codes to your own internal milestones: loaded, departed, arrived, delivered, exception.
7. Run a parallel period. Send real shipments through both the new EDI flow and your existing manual or portal process simultaneously. Reconcile status timestamps and POD data between the two before you touch the cutover switch.
8. Go live, then monitor. Watch acknowledgment rates and IFTSTA completeness on a dashboard. Silence from the carrier's system is not the same thing as success, treat it as a signal worth investigating, not a sign everything's fine.

How you know it worked

Three numbers tell you whether the connection is actually production-ready, not just theoretically live.

First, your CONTRL acknowledgment rate on outbound IFTMIN should sit at or near 100%. Anything less means files are silently failing structural validation on the carrier's side. Second, IFTSTA milestones should arrive within whatever SLA the carrier committed to during onboarding, not "eventually." Third, and this is the real test, count how many shipments for that carrier still get manually re-keyed into a portal after go-live. It should be zero. If someone on your team is still typing shipment details into a web form for a carrier you just integrated via EDIFACT, the integration isn't actually done, it's just running in parallel with the old process.

This pairing of instruction and status data is also what makes automated freight audit possible later. Once you can match an inbound IFTSTA delivery confirmation against the original IFTMIN instruction and the eventual invoice, you've got a clean, three-way match without a person doing it by hand.

The failure mode nobody warns you about: "standard" EDIFACT isn't standard

Two carriers can both claim IFTMIN D.96A compliance and still send you files your mapper chokes on, or worse, accepts and misfiles. The most common trap is reference qualifiers: one carrier uses RFF+CN for a consignment number where another uses RFF+ON for an order number, and if your mapping assumes one and gets the other, the data doesn't error out, it just lands in the wrong field. Optional segments are the other trap. A carrier's MIG might mark a segment as conditional and then, in practice, always populate it a specific way that the generic spec never tells you to expect.

The fix isn't clever mapping logic, it's discipline in testing. Never certify against the generic UN/EDIFACT specification alone. Always test against the carrier's actual sample files and their specific MIG. And set up alerting on CONTRL rejections as a standing operational habit, not a one-time go-live checklist item. A carrier can change their EDIFACT implementation on their end without telling you, and the first sign you'll get is a rejection you weren't watching for.

When to skip building this yourself

If you're onboarding one or two carriers a year, build this in-house. The mapping work above is a few weeks of effort per carrier once your team has done it once, and it's a skill worth having internally.

If you're managing a carrier base in the dozens, the math changes. Each new carrier is, in practice, its own integration project, complete with its own MIG quirks, its own qualifier choices, its own certification cycle. Without a working connection, a dispatcher keys shipment details into carrier portals by hand, copies tracking numbers between screens, and reconciles invoices in a spreadsheet. With it, booking, tracking, and invoice exchange run without manual entry, but getting there and keeping it running is the ongoing cost most teams underestimate. This is the gap that carrier connectivity platforms are built to close. Multi-carrier connectivity layers such as Cargoson, alongside TMS vendors like MercuryGate, Descartes, Transporeon and Alpega, maintain pre-built EDI and API maps across large carrier networks, so adding a new carrier doesn't mean re-running the whole mapping and certification exercise from scratch. Platforms like Orderful take a similar approach on the trading-partner side more broadly: Orderful decouples your EDI from your TMS, and with an API-first model, your systems no longer need to be inextricably woven together, giving you the freedom to upgrade systems without re-onboarding every partner or rewriting every flow. For parcel-heavy operations the equivalent logic shows up in multi-carrier shipping platforms like Sendcloud, ShippyPro or Shippo, which abstract carrier-specific label and tracking APIs the same way EDI hubs abstract IFTMIN and IFTSTA.

As a rough rule: if the annual cost of your team's time spent maintaining custom EDI maps across a growing carrier list starts rivaling a connectivity subscription, that's usually within 12 to 18 months of crossing from a handful of carriers into dozens.

Quick reference checklist

• Get the carrier's specific IFTMIN/IFTSTA MIG, version and segment list before mapping anything
• Confirm your GLNs/EDI IDs and the exact connectivity channel (AS2, SFTP or VAN)
• Map BGM, NAD, TDT, LOC, DTM and RFF from your TMS/ERP to the carrier's IFTMIN structure
• Test with a real non-live shipment in the carrier's certification environment
• Treat a negative CONTRL as a segment/qualifier fix, not a shipment failure
• Map inbound IFTSTA event codes to your internal milestone set
• Run a parallel period against your existing process before cutover
• Track CONTRL acknowledgment rate and IFTSTA completeness as your two go-live signals
• Never assume "EDIFACT-compliant" means identical to another carrier's implementation

Start with one carrier, get it clean end to end, and use that first build as the template your team reuses. The second carrier always goes faster than the first, and by the fourth or fifth you'll know exactly where to look when a new MIG lands on your desk.