How to Set Up EDIFACT IFTSTA Shipment Tracking

If you're still calling carriers to ask "where's my truck", you're not alone, but you're also not using EDI the way it was designed. The EDIFACT IFTSTA message exists specifically to push consignment status milestones automatically from a carrier's system into your TMS, no phone call required. This guide walks through the actual field-by-field setup: what to request from your carrier, which segments matter, how to test before going live, and what to do when the status codes don't match.

Why IFTSTA instead of tracking portals or email updates

IFTSTA replaces manual status chasing with a structured data feed that your TMS can act on automatically. IFTSTA is the UN/EDIFACT message used to report the transport status of a consignment or its equipment at defined milestones — booked, collected, gated in, loaded, departed, arrived, discharged, delivered. It is the tracking message of the freight-forwarding and multimodal world: carriers, forwarders and logistics platforms exchange IFTSTA to keep every party's shipment status in sync.

Every message carries the same core data regardless of mode. Each IFTSTA carries the shipment reference, the status code and reason, the location and the event date/time. That structure is what lets a TMS calculate ETAs and flag exceptions on its own. It underpins the "track your shipment" experience end customers expect, and feeds the exception-management and ETA-prediction logic in modern TMS and freight platforms.

Compare that to the alternative most shippers still run: a carrier portal you check manually, or a status email that lands in someone's inbox at 6pm on a Friday. Without it, tracking is phone calls and spreadsheets; with it, a forwarder can show customers where their cargo is and flag delays automatically the moment a milestone slips. If you've already set up IFTMIN to send transport orders to carriers, IFTSTA is the natural next step: IFTMIN tells the carrier what to move, IFTSTA tells you what happened to it.

What you need before you start

Don't open a connection with a carrier until you have these in place. Skipping any one of them is how "quick EDI projects" turn into six-week fire drills.

• A signed EDI trading partner agreement with the carrier, specifying which party sends IFTSTA and at which milestones
• A communication channel already tested for other messages: AS2 connection, SFTP with exchanged credentials, or a Value Added Network (VAN)
• The carrier's IFTSTA implementation guide and status code list, since exact segment requirements and code values depend on the message directory version and the carrier's own implementation choices
• An EDI translator or TMS module that can parse EDIFACT, such as SEEBURGER, TrueCommerce, Stedi, Better EDI, or a TMS with native carrier EDI/API connectivity
• A test or sandbox environment with the carrier, not your production TMS instance
• A nominated internal owner who will maintain the status code cross-reference table after go-live (this is the part everyone forgets)

Setting up IFTSTA with your carrier: the steps

This is the actual sequence. Skip a step and you'll find out about it during your first carrier system upgrade, not before.

1. Request the implementation guide and directory version. Ask the carrier which EDIFACT directory they run, since the segment set differs by release. Message Type IFTSTA, Version D, Release 21A, controlling agency UN, was last revised in 2021-06-10. Your UNH segment's composite S009 needs to declare the matching version: International multimodal status report messages conforming to this document must contain the following data in segment UNH, composite S009: Data element 0065 IFTSTA 0052 D 0054 21A 0051 UN. If your carrier still runs D.96A, you map to that directory instead, not D.21A.
2. Establish and test the communication channel. Exchange AS2 certificates or SFTP credentials and send a null test file both directions. Confirm the direction of the flow matches your agreement: in most setups, the freight forwarder or carrier provides multiple EDIFACT Instruction (IFTSTA) updates to the shipper or consignee, not the reverse.
3. Map the core segments to your TMS fields. At minimum you need BGM for the consignment reference and message function, DTM for the message and event date/time, TSR for transport service requirements, LOC for place/location (origin, destination, current position), and the repeating STS segment group carrying the actual status code and reason. STS segments carry status codes; LOC and DTM anchor place and time for each event. In the D.21A segment table this sits inside a repeating segment group alongside RFF (reference) and optional FTX (free text) for exception narratives.
4. Build a milestone cross-reference table. Translate the carrier's status codes into your TMS's internal states (booked, in transit, delayed, delivered, exception). No two carriers use identical code sets, even on the same directory version, so this table is the single most important artifact you'll produce in this project. Keep it in a shared spreadsheet or, better, inside your TMS's mapping module so non-technical staff can update it.
5. Send test files and confirm CONTRL acknowledgments. Every inbound IFTSTA should trigger an outbound CONTRL functional acknowledgment confirming syntax was received and parsed correctly. If CONTRL doesn't come back, don't proceed. Fix the interchange envelope (UNB) or segment terminators first.
6. Run a parallel period. For one to two weeks, keep taking the carrier's phone/email confirmations as before, but log every incoming IFTSTA event alongside them. Compare timestamps and status values. This is where you catch mapping errors: a "gated in" code that your table silently treats as "delivered" is a data quality problem, not an IT problem, and it's much cheaper to catch here than after go-live.
7. Go live and set monitoring alerts. Once matched, cut over and configure an alert for any active shipment with no status update after a defined threshold (say, 12 or 24 hours depending on lane). That threshold is your early warning system for silent EDI failures, which are far more common than loud ones.

What an actual IFTSTA payload looks like

It helps to see a real example before you start mapping fields blind. GS1's reference example shows a transport status message between a freight forwarder and a consignor, dated 4 February 2002, carrying status information on four separate consignments. One consignment is reported delivered to the named delivery party at a specific time, referencing the delivery note number that covers it, while a second is simply reported as en route, with the next scheduled status report date included. A third shows why the FTX free text segment matters: it's reported as refused by customs at London Heathrow Airport because of export restrictions. That's the level of granularity a well-mapped IFTSTA feed gives you per shipment, automatically, without anyone picking up a phone.

How you know it worked

Success isn't "we're receiving files." It's specific and measurable. Your milestone timestamps in the TMS should match the carrier's own system within an agreed tolerance (a few minutes for GPS-triggered events, longer for manually entered ones). Your operations dashboard should populate those milestones without anyone typing them in. CONTRL acknowledgments should return for the overwhelming majority of transmissions, not just most of them. And the clearest signal of all: the volume of "where's my shipment" calls to your carrier's ops desk should visibly drop within a month of go-live. If it hasn't, your mapping is incomplete somewhere, usually in the status code table.

Common failure mode: status codes that don't mean what you think

The most frequent failure isn't a broken connection, it's a semantic mismatch. Two carriers can both send valid IFTSTA on the same directory version and still use different reason codes for the same physical event, because the exact code set is defined by the carrier's own implementation guide, not by the EDIFACT standard alone. The fix is the cross-reference table from Step 4, treated as a living document rather than a one-time setup task. Re-validate it after any carrier system upgrade, ERP migration, or change of 3PL sub-contractor on a lane, since that's exactly when silent code drift happens.

A second, quieter failure: CONTRL acknowledgments stop arriving but the connection looks "up." High-volume feeds require idempotent processing and deduplication by control reference, so check first whether your translator is silently dropping duplicate control numbers before assuming the carrier has stopped sending. If that's not it, check AS2 certificate expiry next, that's the single most common cause of EDI channels going quiet without an obvious error message. Escalate to your EDI provider or VAN if certificates are current and files still aren't landing.

When building EDI in-house isn't worth it

If you're running a handful of core carriers on long-term contracts, building and maintaining IFTSTA mappings yourself is usually worth the effort. If you're managing dozens of regional hauliers who will never invest in a dedicated EDI implementation, a connectivity layer that absorbs the mapping work is usually the better trade-off. This EDIFACT-first pattern is common in programs where transport status flows between HQ, distribution centers, and suppliers across the EU and APAC, which is exactly the setup where a normalization layer pays for itself.

On the parcel side, the equivalent job is usually done over APIs rather than EDIFACT, through platforms like nShift, Sendcloud, or ShipStation, since parcel carriers rarely support classic EDI at all. If your transport spend spans both pallet freight and parcel, expect to run two different integration patterns side by side rather than forcing one standard across both.

Next steps

Start with one carrier and one lane before you scale the pattern network-wide. Pull that carrier's implementation guide, confirm the directory version, and get a single test IFTSTA file flowing with a clean CONTRL response before you touch a second connection. For the full segment specification when your mapping table needs more detail than this guide covers, GS1's IFTSTA reference and UNECE's UN/EDIFACT D.21A documentation are the two sources worth bookmarking. Everything else, the code tables, the exception handling, the monitoring thresholds, you'll build out through the first live carrier and reuse for every one after it.