Overview
The IFTSTA (International Forwarding and Transport Status Report) message communicates the current status of a shipment as it moves through the transport chain. It is sent by the party performing or managing the transport (carrier, freight forwarder, logistics provider) to the party who initiated the transport (shipper, consignor) and potentially to other interested parties such as the consignee or a customs broker. Each IFTSTA message reports one or more status events that have occurred since the last update.
IFTSTA provides the data backbone for shipment tracking and visibility. Every milestone in a shipment's journey — pickup, departure, arrival at hub, customs clearance, out for delivery, delivered — can be communicated via IFTSTA events. This information feeds into track-and-trace systems, customer portals, supply chain control towers, and exception management workflows that modern logistics operations depend on.
The message supports all transport modes and can track consignments, containers, transport equipment, and individual goods items. It handles both planned events (scheduled departure, estimated arrival) and actual events (actual departure, delivered), allowing recipients to compare expected versus actual performance and manage exceptions proactively.
Message Structure
The IFTSTA identifies the consignment or transport being tracked, then reports one or more status events. Each event has a status code, date/time, location, and optional details such as reason codes for delays or exceptions. Multiple events can be reported in a single message, covering the full history or just the latest updates.
Key Segments
| Segment | Name | Purpose |
|---|---|---|
BGM | Beginning of Message | Status report number and type |
DTM | Date/Time/Period | Report generation date/time |
NAD | Name and Address | Carrier, shipper, consignee, status report sender/recipient |
RFF | Reference | Consignment number, booking reference, bill of lading number, transport instruction reference |
CNI | Consignment Information | Identifies the specific consignment being tracked |
STS | Status | Status event code (e.g., collected, in transit, delivered, held at customs) |
DTM | Date/Time (event) | Date and time when the status event occurred |
LOC | Place/Location | Location where the status event occurred |
RFF | Reference (event) | POD (proof of delivery) reference, exception reference number |
FTX | Free Text | Additional details about the event (delay reason, delivery instructions followed) |
EQD | Equipment Details | Container or vehicle identification associated with the event |
GID | Goods Item Details | Item-level status when different items in a consignment have different statuses |
Status Event Codes
The STS segment uses coded values to identify the type of event. While specific code lists vary by carrier and industry, common transport events include:
- Booking confirmed: The carrier has accepted the transport booking.
- Collected/Picked up: Goods have been collected from the shipper's premises.
- Departed: The transport has left the origin or an intermediate point.
- Arrived at hub: Goods have arrived at a sorting hub, terminal, or transshipment point.
- In transit: General status indicating the goods are being transported.
- Customs clearance: Goods are undergoing customs processing (import or export).
- Held: Goods are held at a location (customs hold, inspection, damage assessment).
- Out for delivery: Goods are on the final delivery vehicle heading to the consignee.
- Delivered: Goods have been delivered to the consignee. May include proof-of-delivery details.
- Delivery attempted: Delivery was attempted but unsuccessful (address not found, no one present).
- Returned: Goods are being returned to the sender after failed delivery.
Common Use Cases
- Shipment tracking: Carriers send IFTSTA messages at each milestone, feeding the shipper's track-and-trace system with real-time visibility into shipment progress.
- Exception management: When a shipment is delayed, damaged, or held, the IFTSTA with an exception status code triggers alerts in the shipper's system for proactive management.
- Proof of delivery: The final IFTSTA with "delivered" status includes the delivery date/time, signatory name, and POD reference — serving as electronic confirmation of delivery.
- Container tracking: In ocean freight, IFTSTA tracks container events from stuffing through vessel loading, transshipment, discharge, and final delivery.
- Customer communication: E-commerce companies use IFTSTA data from carriers to send delivery status emails and SMS notifications to end consumers.
- Performance measurement: IFTSTA data feeds KPI dashboards measuring carrier performance — on-time pickup rate, transit time adherence, delivery success rate.
Example Snippet
UNH+1+IFTSTA:D:96A:UN'
BGM+77+STA-2024-05678+9'
DTM+137:202403201430:203'
NAD+CA+4000000000011::9++Fast Freight GmbH'
NAD+CZ+5412345000013::9'
RFF+BN:TRANS-2024-01234'
CNI+1+CONS-2024-01234'
STS++1:::Collected'
DTM+334:202403200915:203'
LOC+5+DEBERL'
FTX+AAA+++Collected 25 cartons per instruction'
STS++3:::In transit'
DTM+334:202403201000:203'
LOC+5+DEBERL'
LOC+8+DEHAM'
UNT+14+1' Implementation Considerations
Status code mapping is one of the biggest challenges. Each carrier may use their own internal event codes, which must be mapped to a common set of codes in your tracking system. When integrating with multiple carriers via IFTSTA, create a standardized internal event taxonomy and map each carrier's codes into it. Document the mappings carefully, as carriers periodically add or change their event codes.
Event sequencing and deduplication require attention. Carriers may send multiple IFTSTA messages for the same consignment as events occur, and the same event may appear in consecutive messages (as historical context). Your system should process events idempotently — applying each unique event only once, using the combination of event code, date/time, and location as a natural key.
For real-time tracking requirements, agree on IFTSTA transmission frequency with your carriers. Some carriers send IFTSTA in near-real-time (within minutes of an event), while others batch events and transmit periodically (e.g., hourly or twice daily). If your business requires faster updates than a carrier provides via IFTSTA, you may need to supplement with API-based tracking.