EDIFACT IFTSTA: Transport Status Report

IFTSTA turns a booked consignment into a tracked one. Once the carrier has your IFTMIN, its status reports tell you when the goods were collected, when they are due, and whether they arrived. Those events feed delivery confirmation, on-time measurement and the delay alerts that let you warn a customer before they chase you.

This guide covers what IFTSTA carries, when carriers send it, the status codes, two full examples, the segments you will map, and how IFTSTA compares with the X12 214 shipment status and 315 ocean status.

What Is an EDIFACT IFTSTA?

IFTSTA is the UN/EDIFACT International multimodal status report message: "a message to report the transport status and/or a change in the transport status (i.e. event) between agreed parties." "Multimodal" means the same message serves road, rail, air and ocean, which is why one EDIFACT message covers what X12 splits across the 214 for most modes and the 315 for ocean containers.

GS1's EANCOM manual says a status message may be sent:

• as the result of a request for information about one or more consignments
• on a scheduled basis at predetermined times
• when a selected event or events happen
• when an exceptional event happens, as agreed by the partners

It can report a status that has been reached and, for exceptions, the reason.

Authoritative references for IFTSTA work:

• The UN/EDIFACT D.96A IFTSTA message from UNECE, also laid out group by group on EDIFACTORY
• The GS1 EANCOM 2002 IFTSTA specification, directory D.01B, with its principles, status codes and a worked example of delivered, en route, customs-refused and lost consignments
• Each carrier, forwarder and port community publishes its own IFTSTA guide listing the events it actually reports

Who sends it? The carrier or forwarder moving the goods, or a port, terminal or visibility platform passing events on.

Who receives it? Whoever the carrier agreed to report to: the shipper, the consignee, the forwarder that subcontracted the move, or a logistics provider acting for one of them.

When is it sent? At the events agreed during onboarding: collection, departure, arrival at hubs, out for delivery, delivery, and exceptions such as delays and damage.

Where IFTSTA Fits Among Carriers and Forwarders

A forwarder often sits in the middle: it receives status from the hauliers and carriers it subcontracts and sends its own IFTSTA to the shipper, using the shipper's references. If you receive status from several parties for the same consignment, decide which feed is authoritative before you build alerts on it.

Status Codes

The event is coded in the STS segment. In D.96A the second composite is the status event, and its code list includes:

The first composite is the status type, where 1 means the status is related to transport. In later directories, such as the D.01B base of EANCOM 2002, the status composite uses a renamed element and GS1 lists its own selection of codes, including 13 collection or pick-up completed, 21 delivery completed and 31 en route. A third composite can carry a status reason, and carriers usually publish their own list of reasons and the events they report. Load the list from your carrier's guide rather than assuming every code is used.

Example 1: Collected and En Route

The fictional forwarder Alder Freight Forwarding reports on the consignment the fictional foundry Kestrel Castings booked with IFTMIN: collected at 10:40, en route at 18:50 with an estimated arrival of 08:00 the next morning.

The consignment number in CNI is the consignor's own reference from the IFTMIN, which is what lets your system match the event to the right shipment without a lookup table. Agree during onboarding which reference the carrier will put there.

Example 2: One Delivered, One Delayed

One report can cover several consignments, each in its own CNI group. Here the first consignment was delivered and the second missed its linehaul and has a new estimated arrival.

This example gives the delay reason as free text. Many carriers send a coded reason in the third STS composite instead, which is easier to report on. If yours does, map its code list and keep the free text as a fallback.

IFTSTA Structure at a Glance (D.96A)

The STS group is mandatory inside each CNI group, so a consignment is never reported without a status. Goods items in the GID group let a carrier report a status per package, which GS1's example uses to show some cartons of a consignment delivered and one lost.

Key Segments Explained

BGM: Beginning of Message

BGM+77+AF-ST-0098812+9'

CNI: Consignment Information

CNI+1+KC-SHP-30991'

The first element is a sequence number within the message. The second carries the consignment's document number: GS1 identifies a consignment by the consignor's reference number, the same reference sent in RFF+CU on the IFTMIN.

STS: Status

STS+1+13'

DTM: When

DTM+334:202611121040:203'

Store the event time in DTM+334, not the message time in the header. A carrier that batches events may send a morning collection in an evening report, and on-time measurement should use the time the event happened.

RFF: References

RFF+AAM:AF-HWB-7740321'

Status reports are only useful if you can match them. Carriers commonly send their waybill number (AAM), and many also echo your consignor's reference (CU), your order number (ON) or a booking reference (BN). Ask for every reference you will need to look the shipment up.

IFTSTA vs the X12 214 and 315

The status codes themselves do not map one to one. Build a translation table per carrier from its guide, rather than mapping by name.

Where IFTSTA Sits in the Flow

A delivered status from the carrier and a RECADV from your customer answer different questions. IFTSTA says the goods reached the dock. RECADV says what the customer accepted, line by line.

Common IFTSTA Errors and How to Prevent Them

IFTSTA Implementation Checklist

1. Get the carrier's guide: directory, events reported, status and reason code lists.
2. Agree the references in CNI and RFF so every report matches a shipment.
3. Agree which events you want: collection, departure, delivery and exceptions at minimum.
4. Map status codes to your own milestones, per carrier.
5. Store event times from DTM+334 and keep estimates separate from actuals.
6. Agree time zones and how a late correction to an earlier event is sent.
7. Set alerts on exceptions, such as delayed or not delivered, not on every event.
8. Test with real shipments, including a delay, a partial delivery and a failed delivery.

Where OrderSync Fits

A status report tells you where a shipment is. Whether it is the right shipment, going to the right place with the right order numbers, was decided earlier, when the order was entered. Orders that arrive as PDFs, emails or spreadsheets and get keyed by hand carry their mistakes all the way to delivery.

OrderSync reads inbound orders in any format, from EDI 850s and 875s to PDFs, emails and spreadsheets, matches customers, items and units to your catalog, and outputs clean ERP data or valid X12. Paste any IFTSTA into the free EDIFACT inspector to see it parsed segment by segment, use the free EDI inspector for X12 214s and 315s, or book a 15-minute walkthrough to see your own orders processed.

Frequently Asked Questions

Related guides

• EDIFACT IFTMIN: the transport instruction that starts the move
• EDI 214 shipment status and EDI 315 ocean status: the X12 counterparts
• EDIFACT DESADV and EDIFACT RECADV: what was shipped and what was received
• EDIFACT explained and EDIFACT message types: syntax and the full catalogue

Sources

• UN/EDIFACT D.96A IFTSTA message, UNECE: definition and structure
• IFTSTA in directory D.96A, EDIFACTORY: segment groups and status event codes
• EANCOM 2002 S3 IFTSTA status report message, GS1: principles, code lists and example
• EANCOM 2002 Syntax 3, GS1

Check any IFTSTA or IFTMIN in the free EDIFACT inspector.