6 min read · Updated 2026-05-05 · by TJO

What is an FWB? The IATA Freight Waybill, explained

The FWB is the IATA Cargo-IMP message that pre-alerts a shipment from forwarder/airline to handler. It starts the 21-state workflow and carries the canonical air waybill details everything downstream depends on.

On this page
  1. In one sentence
  2. What’s actually in an FWB
  3. What can go wrong with an FWB
  4. What changed with e-CSD
  5. How Skidd handles FWB
  6. Where FWB fits in the bigger picture

In one sentence

An FWB (Freight WayBill) is the Cargo-IMP message that an airline — or, more often these days, a forwarder via the airline — sends to a cargo handler to pre-alert a shipment and lock down its commercial details before the cargo arrives at the dock.

Everything downstream depends on the FWB being right: acceptance reconciliation, security screening, ULD build-up, the FFM that tells the destination station what is on the flight, and the FSU stream that keeps the airline informed all the way to delivery.

What’s actually in an FWB

A canonical FWB looks deceptively simple — a header, the AWB prefix-and-serial, and then a sequence of structured records. The fields that matter for handlers:

Field groupWhat it carries
AWB identifier123-45678901 — the airline prefix and serial that every other system keys off
Origin / destinationIATA airport codes for the routing legs
Pieces & weightPieces count and gross weight in kg or lb — the numbers acceptance reconciles against
Special handling codes (SHC)Three-letter codes — PER (perishables), VAL (valuables), AVI (live animals), DGR (dangerous goods), ICE (dry ice), RRY (radioactive), etc.
Shipper / consignee / agentParty blocks with name, address, IATA agent code
Commodity descriptionFree-text description plus optional commodity item number
Charges declarationCurrency, charge codes, prepaid / collect indicators
OCI — Other Customs InformationStructured customs and security fields, including the e-CSD security declaration for EU departures
Volume / dimensionsIf declared by the forwarder; otherwise computed at acceptance

The FWB is a flat-text TELEX-style message from the 1980s, which is why it survives every protocol upgrade: every airline ops desk on earth can still read it.

FWB pre-alert FSU/RCS accepted FFM manifested FSU/DEP departed
The FWB is the head of the chain. Everything downstream — FSU on every state change, FFM at flight cutoff — reads from the canonical model the FWB created.

What can go wrong with an FWB

Forty years of dialect drift mean that no two airlines emit a perfectly identical FWB. Common production realities:

  • Optional separators that are mandatory at one carrier and forbidden at another
  • Date formats that vary — 24APR versus 24APR26 versus 2026-04-24 — sometimes within the same carrier
  • OCI field ordering that breaks half-baked parsers when the security block lands before the customs block instead of after
  • SHC codes spelled differently (DGR vs RDG vs DG) by handler convention even though IATA defines a single set
  • Piece-and-weight mismatches between the FWB and the FHL (House Manifest), where the forwarder consolidated differently than they declared

A handler that takes FWBs in production needs a parser hardened against all of this — not a textbook implementation that throws on the first non-standard separator.

What changed with e-CSD

e-CSD — the electronic Customs Security Declaration — restructured the OCI block on FWBs for EU departures. Handlers now need to:

  1. Capture a Regulated Agent (RA) designator per station (e.g. NO/RA3/12345-01)
  2. Sign the security declaration at the point of acceptance, with operator id and timestamp
  3. Emit OCI fields on every outbound FWB whose route triggers the EU rule

If any of those steps is missing, the FWB leaves the system non-compliant and the carrier’s ops desk will reject it — or worse, the carrier won’t reject it and the audit will catch it months later.

See the e-CSD primer for the full spec.

How Skidd handles FWB

Three things are worth saying explicitly:

  1. The parser is hardened against real-world dialects. Skidd parses FWBs from the actual corpus of every major carrier — not just the IATA reference message. Optional separators, mixed date formats, OCI block ordering, SHC variants — all handled.

  2. Every FWB lands in a single canonical model. Whatever dialect the FWB came in on, Skidd normalises it to one internal shape with explicit fields for AWB, parties, pieces, weight, SHC, OCI, charges. That model is what powers the acceptance UI, the rate-card matching, the FSU emission, and the FFM that goes out at flight cutoff.

  3. Outbound FWBs guard EU departures for e-CSD. The composer reads the station’s RA designator and the captured security declaration, populates OCI fields, and refuses to emit an FWB that would land at a carrier non-compliant.

Where FWB fits in the bigger picture

The FWB starts the workflow. From there:

  • FSU messages communicate state changes back to the airline (RCS = received, BKD = booked, MAN = manifested, DEP = departed)
  • FFM is the per-flight manifest aggregating every FWB on a given flight
  • FHL is the house manifest if the FWB was a master AWB consolidating houses
  • FFR is the freight forwarder reservation
  • MVT carries flight movement data (off-blocks, airborne, arrived)

All of those are covered in the Cargo-IMP overview. And if you’re asking whether modern REST replaces all this — yes, eventually. See ONE Record.