Who sends the FFM, and who receives it?

Per the Cargo-IMP manual's message-exchange-parties definition: the FFM is sent by the party generating the manifest (the departure station), addressed to the cargo control computer of the airline, shed operator, or handling agent receiving the consignment — or, for manual handling, to the destination station office of the receiving airline.

Does an airline send one FFM per flight, or one per destination?

Normally one FFM per airport of unloading — a flight serving several downline stations gets a separate manifest for each. A central cargo system that distributes load data to every unloading point can instead be sent a single multi-destination FFM, a series of single-destination FFMs, or a sequence of part FFMs that closes with CONT until the final segment, which closes with LAST.

What does an FFM message actually list?

Bulk cargo as a Consignment Detail line per air waybill — AWB prefix and serial number, origin/destination, piece count, weight, and a manifest description of the goods (e.g. NEWSPAPERS, MACHINE PARTS) — and ULD-loaded cargo grouped under a ULD line naming the container/pallet ID, followed by the AWBs loaded in it. A destination with nothing to unload is flagged with a Nil Cargo Indication instead of consignment lines.

What Is the FFM Message? Airline Flight Manifest

Q: What is the FFM message?

FFM (Airline Flight Manifest) is the Cargo-IMP message that notifies details of consignments loaded onto a specified flight. Its Standard Message Identifier is FFM, and it can optionally also notify onward movements of a consignment loaded on that flight, so that transfers can be pre-planned.

Q: Is FFR a flight manifest?

No. FFR is the AWB Space Allocation Request — a message to request, cancel, replace, or amend the space allocated for a consignment on one or more flights, answered by FFA. It carries booking-action codes like NN, NA, SS, HK, and HL, not a loaded-cargo list. The only flight manifest in Cargo-IMP is FFM.

What the FFM contains

FFM stands for Airline Flight Manifest — its Standard Message Identifier is literally FFM. A message opens with the SMI and a version number (FFM/8 in the manual’s own examples), then a Manifest Header carrying the flight identification — carrier code, flight number, day/month/time of scheduled departure — the airport code of loading, and optionally the aircraft registration and first point of arrival information.

Each destination served by the flight gets its own Destination Header: the airport code of unloading, plus either a Nil Cargo Indication (the manual’s own example closes a leg with LHR/NIL when nothing is being unloaded there) or the consignment content itself.

Consignments are listed two ways:

Bulk cargo — a Consignment Detail line per air waybill: the AWB identification (three-digit airline prefix, hyphen, eight-digit serial number), origin/destination airport codes, a Quantity Detail (shipment description code, number of pieces, weight code and weight), and the Nature of Goods — a plain-text manifest description such as NEWSPAPERS, MACHINE PARTS, or DIESEL ENG SPS. Special Handling Requirements can be repeated up to nine times per consignment.
ULD-loaded cargo — a ULD/ line naming the container or pallet (e.g. ULD/AVE1234AF), followed by the Consignment Detail lines of the AWBs loaded inside it.

The message closes with LAST — or, when a manifest is too long for one message and is split into parts, each part but the final one closes with CONT instead.

Who sends it and when

The Cargo-IMP manual’s message-exchange-parties definition is explicit: From — the party generating the manifest. To (computer) — the access address for the cargo control computer of the airline, shed operator, or handling agent receiving the consignment. To (manual) — the destination station office of the airline receiving the consignment. In practice that means the departure station sends the FFM ahead of (or alongside) the flight, so the receiving station and the ground handlers who will physically process the cargo know what’s coming before it lands.

The message serves two stated functions: primarily, to notify details of consignments loaded onto a specified flight; optionally, to notify the onward movements of a consignment loaded on that flight, so that transfers further down the routing can be pre-planned. The FFM only covers what’s loaded — what happens to a consignment after that (received, delivered, or anything in between) is reported back separately as FSU status updates.

A single flight can generate several manifests. Per the manual’s Multi-Airport FFM rule, a separate FFM is normally produced for each airport of unloading — but where a central cargo system controls distribution of the load information to each unloading point, that system can instead be sent a single multi-destination FFM, a series of single-destination FFMs, or a sequence of part FFMs.

FFM vs FFR

The two SMIs get confused constantly, and the mix-up matters because they do opposite jobs at opposite ends of a shipment’s life:

FFM — Airline Flight Manifest. Sent after cargo is loaded, to say what’s actually on the flight.
FFR — AWB Space Allocation Request, not a flight manifest report. Sent before loading, to request that space on one or more flights be allocated for a consignment — or to cancel, replace, or amend an existing allocation, or add/change/delete booking information. Its message examples carry booking-action codes: NN (alternative flight not acceptable), NA (alternative acceptable), SS (sale reported), XX (cancellation), HK (confirmed), HL (waitlisted), HN (no answer received, request repeated). None of that is manifest content — it’s booking status.

As Cargo-IMP’s own message table confirms, FFR is answered by FFA (booking confirmation), a completely separate reply message. So: is FFR a flight manifest? No. FFR is a booking request, answered by FFA. The only flight manifest in Cargo-IMP is FFM.

Successors

FFM is frozen along with the rest of Cargo-IMP at the 34th and final edition. Following the same X-prefix mapping that turned FWB into XFWB and FHL into XFHL, its Cargo-XML successor is XFFM — the same manifest data in an XML envelope instead of Type B text. Further out, IATA ONE Record removes the standalone manifest message altogether: instead of the departure station pushing an FFM to every downline station, load information becomes part of the shared flight and shipment data every authorised party can read directly.

How Flaks handles the FFM

Flaks generates a compliant FFM (bulk and ULD content, multi-destination or split into parts) straight from the load you’ve built, and parses the FFMs your interline and handling partners send you — so downline stations and ground handlers always know what’s arriving before it does, without anyone re-typing a manifest by hand.