An FWB is the electronic message that carries air waybill data from a forwarder to a carrier's system. Converting an air waybill into an FWB means reading every field off the document, validating it against real air-freight rules, and emitting a structured FWB/16 or FWB/17 message — not retyping the waybill into a carrier portal.
An air waybill — the PDF, the scan, the photo from a phone — is laid out to be read by a person. An FWB is the opposite: a positional EDI message a computer ingests, field by field, with no room for a stray character. The distance between those two is the whole job. Bridge it by hand and someone keys fields into a portal or a per-carrier template, one shipment at a time; a single mis-keyed weight or airport code can land downstream as a rejected message or a mis-billed charge.
What "AWB to EDI" actually converts
Three things are in play, and it helps to keep them separate:
- The source document — the master air waybill, however it arrives: a scan, a PDF, a photo, or an email attachment.
- The structured record — one clean, validated set of fields extracted from that document. This is the thing everything else reads from.
- The output message — the FWB/16 or FWB/17 EDI text, generated from the record so it reflects exactly what was validated.
Because every format reads from the same record, they can't disagree with each other: the JSON, the FWB EDI, and the spreadsheet all describe one shipment, not three slightly different versions of it.
With , you can turn a captured MAWB straight into a carrier-ready FWB message.
Start hereExtract, then validate — before you emit
Extraction reads the fields; validation is where a wrong field gets caught before it becomes a wrong message. The air waybill number is checked with the IATA MOD-7 check digit, the airline prefix and airport codes are checked for shape and consistency, and the weights and piece counts are cross-checked against air-freight logic. A field that fails surfaces as an exception rather than flowing silently into the FWB.
# master air waybill 999-12345675 · CONTOSO FREIGHT · HKG → JFK awb_number = "999-12345675" # prefix 999 · serial 1234567 · check 5 check_digit = valid # 1234567 mod 7 = 5 origin = "HKG" dest = "JFK" pieces = 12 gross_weight = "480.0 KG" # one validated record → many formats, all reading from it: emit FWB/17 ready # or FWB/16 on request emit JSON ready emit CSV ready
Validating first means the FWB reflects a record that already passed its field checks. When something doesn't add up — a check digit that doesn't resolve, a weight that reads implausibly — it's flagged for a person to look at instead of being emitted as a message a carrier would reject.
Generated, not transmitted
AWBGuru returns the FWB/16 or FWB/17 message text; sending it to a carrier is your step, over your own connection. It holds no airline credentials. You get a clean, validated message on your existing rails — the transmission stays entirely in your hands.