# EDIFACT IFTSTA: Transport Status Report

> EDIFACT IFTSTA explained: CNI consignments, STS status codes for collected, en route, delivered and delayed, two D.96A examples and the 214 and 315 map.

<QuickAnswer>
EDIFACT IFTSTA is the international multimodal status report, the UN/EDIFACT counterpart of the X12 214 and 315. A carrier or forwarder sends it to report where a consignment is in the transport chain: collected, en route, delayed, delivered or lost. Each consignment sits in a CNI group, and each event is an STS status code with a date and time.
</QuickAnswer>

**IFTSTA turns a booked consignment into a tracked one.** Once the carrier has your [IFTMIN](/guides/edi/edifact-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](/guides/edi/214-transportation-carrier-shipment-status) and [315 ocean status](/guides/edi/315-status-details-ocean).

<EDIGuideCTA
  badge="For EDIFACT IFTSTA"
  transactionType="IFTSTA"
  headline="Read a carrier's status feed event by event"
  body="Paste an IFTSTA into the free EDIFACT inspector to see each consignment, status code and timestamp, with UNT and UNZ counts checked. Late deliveries often start with an order keyed wrong: OrderSync reads orders in any format, from EDI 850s to PDFs and emails, matches customers, items and units, and sends clean data to your ERP."
  secondaryHref="/edifact-inspector"
  secondaryLabel="Try the free EDIFACT inspector"
/>

## 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](https://service.unece.org/trade/untdid/d96a/trmd/iftsta_c.htm) from UNECE, also laid out group by group on [EDIFACTORY](https://www.edifactory.de/edifact/directory/D96A/message/IFTSTA)
- The [GS1 EANCOM 2002 IFTSTA specification](https://www.gs1.org/sites/default/files/docs/eancom/s3/iftsta.pdf), 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

| Party | Sends IFTSTA to | Typical events |
|---|---|---|
| Road carrier or groupage network | Shipper, forwarder | Collected, en route, delivered, delayed |
| Freight forwarder | Shipper or consignee | Events from its own network and from subcontracted carriers |
| Ocean carrier | Shipper, forwarder, consignee | Container events from empty pickup to empty return |
| Port or terminal community system | Carriers and forwarders | Gate-in, loaded, discharged, released |

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:

| Code | Status event (D.96A) | Typical use |
|---|---|---|
| `1` | Arrived | Means of transport arrived at a location |
| `13` | Collected | Picked up from the consignor |
| `20` | Delayed | Delayed in the course of transportation |
| `21` | Delivered | Delivered to a location or party in the transport chain |
| `22` | Delivery completed | Delivery completed as per instructions |
| `23` | Delivery not completed | Delivery not completed as instructed |
| `24` | Departed | Means of transport departed from a location |
| `31` | En route | In the normal course of transportation |

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.

<EdifactSample
  title="Collected and en route"
  description="One consignment with two STS events: collected (13) at 10:40 and en route (31) at 18:50, with the forwarder's waybill number and an estimated arrival."
  label="UN/EDIFACT D.96A"
  raw="UNA:+.? '
UNB+UNOC:3+ALDERFWD:ZZZ+KESTRELCAST:ZZZ+261112:1905+AFS0098812++IFTSTA'
UNH+1+IFTSTA:D:96A:UN'
BGM+77+AF-ST-0098812+9'
DTM+137:202611121905:203'
NAD+FW+++Alder Freight Forwarding Ltd'
NAD+CZ+++Kestrel Castings Ltd'
CNI+1+KC-SHP-30991'
STS+1+13'
RFF+AAM:AF-HWB-7740321'
DTM+334:202611121040:203'
STS+1+31'
RFF+AAM:AF-HWB-7740321'
DTM+334:202611121850:203'
DTM+132:202611130800:203'
UNT+14+1'
UNZ+1+AFS0098812'"
/>

| Segment | What it says |
|---|---|
| `BGM+77+AF-ST-0098812+9'` | Status report (`77`, consignment status), report number AF-ST-0098812, original |
| `NAD+FW` / `NAD+CZ` | Report from the freight forwarder, about a consignment from this consignor |
| `CNI+1+KC-SHP-30991'` | Consignment 1, identified by the consignor's shipment reference |
| `STS+1+13'` | Transport status: collected |
| `RFF+AAM` | The forwarder's waybill number |
| `DTM+334` | Status change date/time: 12 November at 10:40 |
| `STS+1+31'` | Transport status: en route, at 18:50 |
| `DTM+132` | Estimated arrival: 13 November at 08:00 |

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.

<EdifactSample
  title="One consignment delivered, one delayed"
  description="Two CNI groups in one report: delivered (21) with a receipt note, and delayed (20) with a new estimated arrival and the reason in free text."
  label="UN/EDIFACT D.96A"
  raw="UNA:+.? '
UNB+UNOC:3+ALDERFWD:ZZZ+KESTRELCAST:ZZZ+261113:1620+AFS0098907++IFTSTA'
UNH+1+IFTSTA:D:96A:UN'
BGM+77+AF-ST-0098907+9'
DTM+137:202611131620:203'
NAD+FW+++Alder Freight Forwarding Ltd'
NAD+CZ+++Kestrel Castings Ltd'
CNI+1+KC-SHP-30991'
STS+1+21'
RFF+AAM:AF-HWB-7740321'
DTM+334:202611130746:203'
FTX+AAI+++Received by goods-in, dock D07'
CNI+2+KC-SHP-31004'
STS+1+20'
RFF+AAM:AF-HWB-7740388'
DTM+334:202611131510:203'
DTM+132:202611160800:203'
FTX+AAI+++Missed linehaul departure, rebooked on next trunk'
UNT+17+1'
UNZ+1+AFS0098907'"
/>

| Segment | What it says |
|---|---|
| `CNI+1` / `STS+1+21'` | Consignment KC-SHP-30991 delivered at 07:46 on 13 November |
| `FTX+AAI` | General information: who received it |
| `CNI+2` / `STS+1+20'` | Consignment KC-SHP-31004 delayed, reported at 15:10 |
| `DTM+132` | New estimated arrival: 16 November at 08:00 |
| `FTX+AAI` | The reason, in free text |

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)

| Area | Segment or group | Status | What it holds |
|---|---|---|---|
| Header | `UNH` | M | Message reference and type |
| Header | `BGM` | M | Document code, report number, function |
| Header | `DTM` | C | Message date |
| Header | `TSR` | C | Transport service requirements |
| Header | `NAD` group (SG1) | C | Parties, with contacts |
| Header | `RFF` group (SG3) | C | References for the whole report |
| Header | `LOC`, `FTX`, `CNT` | C | Locations, free text, control totals |
| Detail | `CNI` group (SG4) | C | One consignment, with `LOC` and `CNT` |
| Detail | `STS` group (SG5) | M | One status: `RFF`, `DTM`, `DOC`, `FTX`, `NAD`, `LOC`, `PCI` |
| Detail | `TDT` group (SG6) | C | The transport the status relates to |
| Detail | `EQD` group (SG7) | C | Equipment, such as a container or trailer, with seals |
| Detail | `GID` group (SG9) | C | Goods items, with measurements and package marks |
| Trailer | `UNT` | M | Segment count and message reference |

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'
```

| Element | Name | Example | Notes |
|---|---|---|---|
| 1001 | Document name code | `77` | Status report covering consignment status. The code list also defines `23` (status information), and `44` (transport status report) appears in later directories and in EANCOM's list |
| 1004 | Document number | `AF-ST-0098812` | The report number |
| 1225 | Message function | `9` | Original |

### 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'
```

| Composite | Content | Example |
|---|---|---|
| Status type (C601) | Category of status | `1` transport |
| Status event (C555) | What happened | `13` collected, `31` en route, `21` delivered |
| Status reason (C556) | Why, for exceptions; can repeat | Carrier's or UN code list |

### DTM: When

```
DTM+334:202611121040:203'
```

| Qualifier (2005) | Meaning |
|---|---|
| `334` | Status change date/time: when the event happened |
| `132` | Arrival date/time, estimated |
| `178` | Arrival date/time, actual |
| `35` | Delivery date/time, actual |
| `137` | Document/message date/time (header) |

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

| Data | EDIFACT IFTSTA | X12 214 | X12 315 |
|---|---|---|---|
| Modes | Any (multimodal) | Truck and most other modes | Ocean |
| Unit reported | Consignment (`CNI`), optionally goods items and equipment | Shipment, with `LX` loops | Container or shipment |
| Status code | `STS` status event | `AT7` status code | `B4` status code |
| Reason code | `STS` status reason | `AT7` reason code | Per carrier guide |
| Event time | `DTM+334` | `AT7` date and time | `B4` date and time |
| Location | `LOC` or `NAD` in the `STS` group | `MS1` | `B4` and `R4` |
| Equipment | `EQD` | `MS2` | `B4` container number |
| References | `RFF` | `L11` | `N9` |
| Trailer count | `UNT` | `SE` | `SE` |

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

| Step | Message | Direction | X12 equivalent |
|---|---|---|---|
| 1 | [IFTMIN](/guides/edi/edifact-iftmin) (with IFTMBF and IFTMBC in ocean) | Shipper to carrier or forwarder | [204](/guides/edi/204-motor-carrier-load-tender) or [304](/guides/edi/304-shipping-instructions) |
| 2 | **IFTSTA**, at each agreed event | Carrier to shipper | [214](/guides/edi/214-transportation-carrier-shipment-status) or [315](/guides/edi/315-status-details-ocean) |
| 3 | [RECADV](/guides/edi/edifact-recadv), after the consignee books the goods in | Consignee to supplier | [861](/guides/edi/861-receiving-advice) |
| 4 | Freight invoice | Carrier to payer | [210](/guides/edi/210-motor-carrier-freight-invoice) or [310](/guides/edi/310-freight-receipt-and-invoice-ocean) |

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

| Problem | What happens | Prevention |
|---|---|---|
| Status cannot be matched to a shipment | Events pile up unassigned | Agree the reference in `CNI` and `RFF` during onboarding |
| Message time used as event time | On-time figures wrong | Read `DTM+334` for the event |
| Unknown status code treated as delivered | Shipments closed too early | Map codes explicitly and hold unknown ones for review |
| Duplicate events from several parties | Conflicting timelines | Choose one authoritative feed per consignment |
| Estimated arrival not updated | Customers told the old time | Overwrite the estimate from each new `DTM+132` |
| Time zone assumed | Events hours out | Agree whether times are local to the event or a fixed zone |

## 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](/edifact-inspector) to see it parsed segment by segment, use the [free EDI inspector](/edi-inspector) for X12 214s and 315s, or [book a 15-minute walkthrough](/book-call) to see your own orders processed.

## Frequently Asked Questions

<div className="not-prose">

### What is the X12 equivalent of IFTSTA?

The 214 shipment status message for truck and most other modes, and the 315 status details for ocean containers. IFTSTA is multimodal, so one EDIFACT message covers both.

### What does STS+1+21 mean?

`STS` is the status segment. `1` says the status is related to transport, and `21` in the D.96A status event list means delivered. The time of the event is in the `DTM+334` that follows.

### What is the CNI segment in IFTSTA?

`CNI` (consignment information) opens one consignment in the report, with a sequence number and the consignment's reference. Every `CNI` group must contain at least one `STS` status group.

### Can one IFTSTA report on several consignments?

Yes. Each consignment gets its own `CNI` group, and each can carry several status events. GS1's example reports four consignments in one message, with different statuses.

### Who sends IFTSTA, the carrier or the forwarder?

Either. A carrier reports on what it moves, and a forwarder often collects status from its subcontracted carriers and sends its own IFTSTA to the shipper. Ports and visibility platforms send it too.

### How is IFTSTA different from RECADV?

IFTSTA comes from the transport side and reports events such as collected, en route and delivered. RECADV comes from the customer and reports what was received and accepted after checking the goods. A delivered status does not mean every line was accepted.

### Which directory does IFTSTA use?

The one your carrier specifies. D.96A is common with road carriers and forwarders, EANCOM 2002 uses D.01B, and ocean carriers often publish guides in later directories. The status codes and segment groups are similar but not identical.

</div>

## Related guides

- **[EDIFACT IFTMIN](/guides/edi/edifact-iftmin)**: the transport instruction that starts the move
- **[EDI 214 shipment status](/guides/edi/214-transportation-carrier-shipment-status)** and **[EDI 315 ocean status](/guides/edi/315-status-details-ocean)**: the X12 counterparts
- **[EDIFACT DESADV](/guides/edi/edifact-desadv)** and **[EDIFACT RECADV](/guides/edi/edifact-recadv)**: what was shipped and what was received
- **[EDIFACT explained](/guides/edi/edifact)** and **[EDIFACT message types](/guides/edi/edifact-message-types)**: syntax and the full catalogue

## Sources

- [UN/EDIFACT D.96A IFTSTA message](https://service.unece.org/trade/untdid/d96a/trmd/iftsta_c.htm), UNECE: definition and structure
- [IFTSTA in directory D.96A](https://www.edifactory.de/edifact/directory/D96A/message/IFTSTA), EDIFACTORY: segment groups and status event codes
- [EANCOM 2002 S3 IFTSTA status report message](https://www.gs1.org/sites/default/files/docs/eancom/s3/iftsta.pdf), GS1: principles, code lists and example
- [EANCOM 2002 Syntax 3](https://www.gs1.org/edi/eancom/s3), GS1

Check any IFTSTA or IFTMIN in the free [EDIFACT inspector](/edifact-inspector).