Automating Air Waybill (AWB) and House Waybill (HAWB) Data Extraction for Air Cargo Freight Forwarders

Ask an air cargo operations manager which single document controls more of their day than any other and the answer is immediate: the Air Waybill. Every shipment that moves through a freight forwarder's warehouse is built around one — a Master AWB tying the consolidation to a carrier flight, a House AWB per shipper underneath it, a cargo manifest tying the MAWB to the aircraft, a Shipper's Declaration for Dangerous Goods if any of the freight is regulated, a Certificate of Origin, a commercial invoice, a packing list, screening certificates, and — depending on the destination — an Export Declaration, an ISF filing, or a customs pre-alert. Somewhere north of a dozen documents per shipment, hundreds of shipments per day at a mid-sized forwarder, thousands per day at a global one.

And almost every one of those documents still arrives as a PDF. Sometimes an image scan of a paper waybill photographed on the loading dock. Sometimes a system-generated e-AWB PDF from a shipper's TMS. Sometimes a screenshot pasted into an email at 2 a.m. Every one of them has to be keyed into the forwarder's freight management system before the shipment can be manifested, screened, and tendered to the airline.

This guide walks through what an air waybill actually is, why AWB and HAWB data entry has resisted every automation attempt so far, what a good outcome looks like, and how to build a production-grade extraction pipeline using DocumentIQ — one that survives the format drift, ties every HAWB back to its MAWB, checks screening status against TSA and IATA rules, and turns days of manual reconciliation into minutes of exception review. This is the kind of workflow modern LLM-based document extraction was built for, and the payoff on the air freight side is unusually large because the manual baseline is unusually painful.

What an Air Waybill Actually Is

The Air Waybill is the contract of carriage between the shipper and the air carrier. Unlike a bill of lading in ocean freight, it is non-negotiable — it does not transfer title to the goods, and there is no consignee copy that acts as a receipt of ownership. It exists to say: these goods, from this shipper, to this consignee, under these terms, on this flight, at this rate.

In practice, "the air waybill" is not one document — it is a stack, and the structure matters:

Master Air Waybill (MAWB) — issued by the operating airline (or by an issuing agent under an IATA CASS arrangement) for a consolidated shipment. The MAWB number is 11 characters: a 3-digit IATA airline prefix, followed by a 7-digit serial, followed by a check digit. 157-12345675 is a Qatar Airways MAWB. 020-98765432 is Lufthansa Cargo. The MAWB governs the movement of the whole consolidation from origin airport to destination airport.
House Air Waybill (HAWB) — issued by the freight forwarder for each individual shipper inside a consolidation. HAWB numbering is proprietary to the forwarder — often the forwarder's IATA code plus a serial (ABC-000012345) — and there can be dozens of HAWBs under a single MAWB. The HAWB is the contract between the forwarder and the underlying shipper; the MAWB is the contract between the forwarder-as-consolidator and the airline.
Cargo Manifest — the airline-format listing of every MAWB on a specific flight, with total pieces, weight, and dangerous-goods indicators per MAWB.
Shipper's Declaration for Dangerous Goods (DGD / Shipper's Dec) — the IATA-format form (currently DGR 66th edition) declaring UN number, proper shipping name, class/division, packing group, packing instruction, and quantity per package for any regulated freight.
Screening Certificate / CSD (Consignment Security Declaration) — the record that the freight has been screened by a Certified Cargo Screening Facility (CCSF in the US) or a Regulated Agent (RA) under ICAO Annex 17, with the screener's identity, screening method (X-ray, ETD, physical search, canine), and screening timestamp.

Every one of those documents has to survive the flight to origin airport terminal, the ground handler's warehouse, the flight itself, the destination ground handler, customs, and the consignee's delivery agent — and every hand-off along the way expects the paperwork to be internally consistent with what is stapled to the freight and what is sitting in the airline's cargo management system.

That's a lot of surface area for typos.

Why AWB and HAWB Data Entry Is So Painful Manually

The pain has four layers.

1. The volume is relentless and time-boxed

An air cargo shipment moves fast. A shipper hands the freight to the forwarder in the morning; the forwarder consolidates by mid-afternoon; the airline's cutoff for the evening flight is typically 4–6 hours before wheels-up. Every HAWB has to be keyed, every consolidation manifest built, every screening record captured, every DGD reviewed and signed off, every pre-alert transmitted to the destination station — all before that cutoff. A single missed cutoff bumps the freight to the next flight, which can mean a 24-hour delay to a shipper that paid a premium precisely to avoid delays. That premium then gets refunded, and the forwarder eats the loss.

At a mid-sized forwarder handling 500–2,000 HAWBs per day per gateway, the ops team is measured on cutoff performance to the minute. Every extra second per document is a bottleneck.

2. Every format is different, and format drift never stops

A "House Air Waybill" is a specific IATA form layout — but nobody uses the pure IATA form anymore. The forwarder's own TMS generates a branded HAWB PDF. The shipper's ERP-generated commercial invoice sits next to it. The shipper's spreadsheet-based packing list sits next to that. The ground handler's warehouse receipt is a barcode-heavy dock label. The origin station's screening record is a Word-template PDF with the CCSF stamp scanned in. The airline's MAWB e-copy is a system-generated e-AWB. Every OEM airline (Emirates SkyCargo, Qatar Airways Cargo, Lufthansa Cargo, Cathay Pacific Cargo, Turkish Cargo, FedEx, UPS) has its own e-AWB layout with its own placement of the shipper, consignee, agent, and rate boxes.

Even within a single forwarder, a HAWB PDF from the Frankfurt station looks different from a HAWB PDF from the Los Angeles station because they built their TMS templates independently ten years ago and never harmonized them. Every station change, every carrier onboarding, every acquisition drags a new document format into the pipeline. This is precisely the kind of environment where templates fail and LLM-based extraction wins.

3. The interlocks across documents are what actually matter

An AWB by itself is a piece of paper. The value is that the AWB, the HAWB, the commercial invoice, the packing list, the DGD, and the screening record all have to agree with each other and with the freight. A gross weight on the HAWB that does not match the sum of the piece weights on the packing list. A consignee on the HAWB that does not match the consignee on the commercial invoice. A UN number on the DGD that is not permitted on a passenger aircraft when the MAWB was tendered to a passenger flight. A screening timestamp that predates the pickup timestamp — meaning the freight was screened before it arrived at the CCSF, which is impossible and voids the screening.

Every one of those inconsistencies is either a customs hold at destination, a screening rejection at origin, a fine from the TSA/DfT/EASA regulator, or a cargo claim from the shipper. And the only way to catch them manually is a person opening every PDF, reading every field, and cross-checking every value against every other document. At 500 HAWBs a day, no ops team catches all of them.

4. The regulatory stakes are real and getting stricter

Air cargo screening is regulated. In the US, since ACSSP 100% screening went fully into force, every piece of cargo on a passenger aircraft has to be screened at the piece level by a TSA-approved CCSF. Every screening record has to be retained for 30 days and produced on demand during a TSA audit. In the EU, Regulation (EC) 300/2008 and its implementing regulations require Known Consignor / Account Consignor / Regulated Agent handling, with CSD records travelling with the consignment. The IATA Cargo iQ standard now expects "quality shipment" milestones from pickup to delivery to be reported electronically. AN OEM airline that finds a forwarder's screening records don't tie out during a spot check will suspend that forwarder's status.

The AWB and its supporting documents are the audit trail. If the paperwork doesn't hold up, the operating certificate does not either.

Why the Existing Tools Do Not Fix This

Every forwarder has tried a variant of the same solutions. Each has a fatal flaw.

Direct manual keying into the freight management system

The historical baseline. Ops clerks open every HAWB PDF and key the fields into CargoWise, WiseTech, Descartes, Magaya, Riege, or whatever TMS the forwarder runs. A skilled clerk keys a HAWB in around 3–5 minutes. That's tolerable for 20 shipments a day and catastrophic at 500. Error rates on manually-keyed weights, dimensions, and consignee addresses run 2–4% because clerks fatigue, transpose digits, and confuse metric and imperial units under time pressure. Every one of those errors is a downstream rework loop — reissue the HAWB, retransmit the FWB/FHL to the airline, resend the pre-alert.

Airline e-AWB adoption

The IATA push to eliminate the paper MAWB by requiring FWB (Freight Waybill message) and FHL (Freight House Manifest) transmissions has made real progress. On many trade lanes, e-AWB penetration is now above 80%. But e-AWB solves the carrier hand-off — it does not solve the forwarder intake problem. The forwarder still has to receive HAWBs and shipping documents from thousands of individual shippers, most of whom do not have an EDI relationship with the forwarder and never will. The FWB message the forwarder sends to the airline is only as good as the data the forwarder captured from the shipper's paperwork upstream. Garbage in, garbage on the flight.

Template-based OCR products

The most common failed attempt. A forwarder buys a Rossum, ABBYY, or Kofax product, trains a template per major shipper's HAWB layout, and runs it in production. It works on the top-20 shippers whose formats never change. It silently fails on every shipper below that — which is the 80% of shipments and the 60% of the volume — because building 5,000 templates for a long-tail shipper base is not economically viable. Template accuracy on IATA MAWB forms specifically is another well-known failure mode: the boxes are cramped, the print on the pink airline copy is often faint, and rotation by a few degrees on a scanned copy shifts every coordinate.

We have written before about why template approaches break down on documents with layout variance — see OCR vs LLM Document Extraction: What's the Difference? and the parallel operational problem for ocean freight in Automating Bill of Lading Processing with AI.

Offshore data entry

The other common approach. A BPO in Manila or Mumbai keys every HAWB into the TMS. Per-HAWB cost runs $1.50–$4.50, turnaround is 4–24 hours depending on the SLA, and error rates on regulated fields (UN numbers, packing groups, HS codes, consignee tax IDs) run 3–8% because the offshore team is measured on throughput, not on downstream shipment integrity. Every offshore hand-off is also a data-privacy exposure — HAWBs contain shipper contact details, commercial invoices contain pricing, DGDs contain regulated goods identifiers.

For time-critical express freight, the 4–24 hour offshore SLA is simply incompatible with the airline cutoff. The forwarder ends up keying express shipments in-house and offshoring only the deferred lanes, defeating half the cost case.

Shipper portals

A handful of large forwarders have built shipper self-service portals where the shipper types the HAWB data directly. Adoption is patchy — small shippers do not use them, medium shippers use them inconsistently, and even large shippers frequently type wrong data because their AP clerks are not the same people who prepared the paperwork. Portals shift the keying to a party with even less incentive to get it right.

What "Getting AWB Extraction Right" Actually Means

Before showing how DocumentIQ handles this, it is worth being precise about what a good outcome looks like. For every incoming shipment — a MAWB PDF plus one or more HAWB PDFs plus supporting documents — a modern extraction pipeline needs to produce structured, queryable, cross-checked answers to these questions.

Master Air Waybill (MAWB)

MAWB number (11 characters, airline prefix + serial + check digit) with check-digit validation against the IATA rule (mod-7 of the 7-digit serial equals the check digit).
Issuing airline (derived from the 3-digit prefix against the IATA carrier prefix table).
Airport of departure and airport of destination (3-letter IATA codes).
Flight number(s) and flight date(s) — routed, transhipped, or direct.
Issuing agent name, IATA agent code, and CASS participant number.
Total pieces, total gross weight, chargeable weight (dimensional if applicable), volume in cubic meters/feet.
Nature and quantity of goods (per the IATA description).
Rate class, commodity item number, and total charges (weight charge, valuation charge, other charges pre-paid vs. collect).
Currency of settlement.
Handling information / SSR / SPX (Screened Passenger) / SCO (Screened Cargo-Only) / OSI codes.
Dangerous goods indicator (CAO — Cargo Aircraft Only, or general DG).
Signature of shipper/agent and signature of issuing carrier.

House Air Waybill (HAWB)

HAWB number in the forwarder's proprietary format.
Reference to parent MAWB number (this is the interlock — every HAWB must trace to exactly one MAWB).
Shipper name, address, contact, EORI / Tax ID.
Consignee name, address, contact, EORI / Tax ID.
Notify party (may be different from consignee — e.g., customs broker).
Airport of departure and destination.
Number of pieces, gross weight, chargeable weight, volume, dimensions per piece.
Nature and quantity of goods, HS tariff heading if declared, HS code if pre-classified.
Declared value for carriage and declared value for customs.
Insurance amount (or "NIL" / "NVD" — No Value Declared).
Terms of shipment / Incoterms.
Signature of shipper.

Cross-document — cargo manifest

The MAWB number appears exactly once on the manifest for the operating flight.
Total pieces and total gross weight on the manifest match the MAWB total.
Dangerous goods flag on the manifest matches the DGD presence.

Cross-document — commercial invoice and packing list

Shipper on the commercial invoice matches shipper on the HAWB.
Consignee on the commercial invoice matches consignee on the HAWB.
Sum of gross weights on the packing list matches the HAWB gross weight (within a small tolerance for packaging).
Total value on the commercial invoice matches the declared value for customs on the HAWB.
HS codes on the commercial invoice line items are all valid HS-2022 codes.

Cross-document — Shipper's Declaration for Dangerous Goods

The DGD is present if and only if the HAWB or MAWB carries a DG indicator.
Every UN number on the DGD is valid against the current IATA DGR list and appears with its correct proper shipping name, class/division, and packing group.
The packaging instruction (PI) selected matches the mode of transport (CAO vs. passenger) on the MAWB.
Net quantity per package is within the "Y" (limited) or general per-package limit for the PI.
The DGD is signed and dated within a valid window before flight departure.

Cross-document — screening records

Every piece on the HAWB has a screening record from a valid CCSF / RA identifier.
Screening method (X-ray, ETD, physical, canine) is present.
Screening timestamp is after freight pickup and before airline tender.
The screening operator's certificate number resolves in the forwarder's or authority's operator registry.

Rating and revenue

The MAWB rate calculation ties out: weight × rate + other charges = total charges.
The MAWB currency of settlement matches the CASS billing currency for the airline.
The sum of the HAWB revenue values under a MAWB matches the consolidation profitability model in the forwarder's TMS.

Compliance flags

The consignee is not on the OFAC SDN list, the EU consolidated sanctions list, or the UK OFSI list.
The commodity is not on the ITAR, EAR-controlled, or dual-use list without the corresponding export license reference on the HAWB.
The destination is not embargoed for the shipper's country of origin.

That last block is exactly where the whole thing stops being a data-entry exercise and starts being an operating discipline. Individual field extraction is table stakes. It is the cross-document reconciliation across the MAWB, HAWB, invoice, packing list, DGD, and screening record that turns air freight paperwork from a bottleneck into a controlled process — and it is the piece no template-based tool has ever been able to deliver.

How to Build It in DocumentIQ

DocumentIQ handles this workflow using the same primitives every extraction pipeline uses: projects, extraction fields with per-field prompts, annotations for few-shot examples, and cross-document reasoning through the chat assistant. The pattern that works for air freight is to structure the workflow as one DocumentIQ project per document class per gateway, with a shared consolidation orchestration layer that ties the extracted data together.

Step 1: One project per document class

Create a DocumentIQ project per air-freight document type:

awb-mawb — Master Air Waybills
awb-hawb — House Air Waybills
awb-manifests — Cargo manifests
awb-dgd — Shipper's Declarations for Dangerous Goods
awb-screening — CCSF / RA screening records and Consignment Security Declarations
awb-commercial-invoices — Commercial invoices (shipper-issued)
awb-packing-lists — Packing lists per shipment

Splitting by document class is not incidental. It matters because the prompt hierarchy in DocumentIQ is per-project, and each of these document classes has fundamentally different extraction logic. A MAWB project's system prompt establishes IATA MAWB vocabulary (rate class Q, N, M, C; CAO indicator; SSR codes). A DGD project's system prompt establishes IATA DGR vocabulary (UN numbers, packing groups I/II/III, packing instructions 966/967/968 for lithium batteries specifically). A commercial invoice project understands HS codes and Incoterms. Trying to run a single flat schema across all of them dilutes accuracy on every one.

At the organization level, set a shared org-level system prompt that encodes the operating context: "Documents are air cargo shipment paperwork handled by a certified freight forwarder operating under IATA CASS, TSA CCSF certification (US origins), and EU Regulated Agent status (EU origins). All rate references follow IATA TACT rules. All dangerous goods references follow IATA DGR 66th edition. All screening references follow ICAO Annex 17." Every project inherits this context from the prompt hierarchy before layering document-specific instructions on top.

Step 2: Define extraction fields, deeply

Here is a partial House Air Waybill schema in DocumentIQ terms. Every one of these fields carries its own custom extraction prompt that encodes the operational rule the ops team actually applies when reading the document:

hawb_number (text) — "Extract the House Air Waybill number. This is the forwarder's proprietary reference, usually in the top-right of the HAWB. May appear as 'HAWB No.', 'H/AWB', 'House AWB', or just 'Reference'. Return the value exactly as printed — do not strip prefixes, dashes, or leading zeros."
mawb_number (text) — "Extract the parent Master AWB number this HAWB is consolidated under. Format is 3 digits, a hyphen, then 8 digits (e.g., 157-12345675). Look for labels 'MAWB', 'Master AWB', 'Consolidated under', or 'Airline AWB'. If absent, return null — many HAWBs are keyed before the MAWB is issued, and the ops team assigns MAWB later."
shipper (object) — "Extract the shipper block: name, address_line_1, address_line_2, city, postal_code, country (2-letter ISO), contact_name, phone, email, tax_id_or_eori. If the shipper block spans multiple lines with inconsistent formatting, infer address components from context rather than positional parsing."
consignee (object) — "Extract the consignee block using the same structure as shipper. Consignee may be marked 'To Order' or 'TO ORDER OF' with a bank name — capture the exact text in name in that case."
notify_party (object) — "Extract the notify party block if present. This is often a customs broker or import agent — different from the consignee. If the HAWB says 'Same as consignee', return null."
airport_of_departure (text) — "Extract the 3-letter IATA code for the departure airport. If only a city name is shown, return the primary airport IATA code for that city (JFK for New York, LHR for London Heathrow unless otherwise specified)."
airport_of_destination (text) — "Extract the 3-letter IATA code for the destination airport, applying the same rule."
pieces (number) — "Extract the total number of pieces. Look for 'No. of Pieces', 'Total Pieces', or 'PCS'. Return as an integer."
gross_weight_kg (number) — "Extract the total gross weight. If the document uses pounds (LB), convert to kilograms (1 lb = 0.4535924 kg) and return kilograms. Always return kilograms."
chargeable_weight_kg (number) — "Extract the chargeable weight. If not explicitly shown, calculate as max(gross weight, volumetric weight) where volumetric weight = volume_cm3 / 6000. If volume is not shown either, return null and flag chargeable_weight_source as 'missing'."
volume_m3 (number) — "Extract the total volume. If shown in cubic feet, convert to cubic meters (1 ft³ = 0.02831685 m³). If shown as dimensions per piece (L × W × H) with piece counts, compute the total."
nature_and_quantity_of_goods (text) — "Extract the goods description exactly as printed. Do not summarize or normalize."
hs_code_declared (text) — "Extract the HS tariff code if declared on the HAWB. Return the 6-, 8-, or 10-digit code as printed. Do not attempt to classify goods that are not classified on the document."
declared_value_for_carriage (object) — "Extract the declared value for carriage as {amount, currency}. If 'NVD' (No Value Declared) is printed, return {amount: null, currency: null, nvd: true}."
declared_value_for_customs (object) — "Same structure as declared_value_for_carriage. Return {nvd: true} for 'NVD' or 'AS PER INV' (value follows commercial invoice)."
incoterms (text) — "Extract the Incoterms 2020 term (EXW, FCA, CPT, CIP, DAP, DPU, DDP, FAS, FOB, CFR, CIF). Return the 3-letter code and the named place (e.g., 'FCA JFK', 'DAP Frankfurt Warehouse')."
dangerous_goods (boolean) — "Return true if any of the DG indicators are present: 'DGR', 'Dangerous Goods', 'CAO', a UN number in the description, or a class/division reference. Otherwise false."
shipper_signature_present (boolean) — "Return true if the shipper signature block contains a visible signature, name, and date. Return false if the block exists but is empty. This is a compliance-critical field."

Every one of these prompt bodies encodes an operational rule the ops team already knows. The whole point of DocumentIQ's per-field extraction_prompt column is to move that institutional knowledge from a training document nobody reads into the extraction pipeline itself.

Add a parallel schema for the MAWB project — MAWB number with explicit check-digit validation in the prompt ("Verify that the 7-digit serial mod 7 equals the check digit; if not, flag mawb_check_digit_valid as false"), issuing airline resolved from the prefix table, flight number, flight date, rate lines, total charges, currency, and every SSR/SPX/CAO code in the handling information block. Add the DGD schema — UN number, proper shipping name, class/division, packing group, packing instruction, quantity per package, net quantity, aircraft type indicator (CAO or passenger), signatory name and date. Add the screening record schema — CCSF/RA identifier, screening method, screening timestamp, operator name and certificate number, seal number if applicable.

Step 3: Feed it a few carefully-chosen annotations

The single biggest accuracy lever on air freight paperwork is few-shot annotation via DocumentIQ's PDF annotation layer.

Take a canonical HAWB PDF from each of your top-10 shipper account groups and each of the layouts your own gateway TMS templates produce (usually 5–15 layouts to cover 90% of your daily volume). Open each in the DocumentIQ PDF viewer, drag a bounding box around the HAWB number, and map it to the hawb_number field. Repeat for shipper name, consignee name, gross weight, chargeable weight, and value blocks — around 8–12 annotations per layout is usually enough.

Do the same for the MAWB project — one annotation per top airline family covers most of the format variance. Emirates SkyCargo puts the flight information block on the top-right; Lufthansa Cargo puts it on the top-left; FedEx puts SSR codes in a completely different section from the IATA standard. A few carefully-placed annotations per airline eliminate the systematic misreads.

For the DGD project, this pays off even more. Annotate one canonical DGD per packing instruction family — lithium batteries (PI965/966/967, PI968/969/970), radioactive materials (Class 7), infectious substances (UN2814/UN2900) — and DocumentIQ carries the annotation forward as a few-shot example on every subsequent DGD in the same PI family. Recognition accuracy on packing group and net quantity per package jumps from around 75% (unaided LLM) to 96%+ (LLM with a canonical annotation library).

Ninety minutes of thoughtful annotation at project setup pays back within the first week of production traffic.

Step 4: Wire the intake pipeline

For every shipment that arrives, an orchestration layer routes each document into the corresponding DocumentIQ project.

HAWBs, MAWBs, DGDs, commercial invoices, and packing lists arrive by three channels: shipper email attachments (parsed by a mailbox integration), shipper portal uploads (posted directly), and TMS-generated PDFs (pushed by the TMS as soon as the ops team assigns a HAWB number in CargoWise / WiseTech / Descartes).
A lightweight classifier (either a rule-based prefilter on filename and a first-page hash, or a first-pass LLM call on the first 200 characters of the document) routes each incoming PDF to the correct project.
Each project's Celery worker picks up the document, runs the DocumentIQ chunking pipeline, extracts every declared field via per-field extraction mode, and writes the structured output back to your freight management system via its API (CargoWise's eAdaptor, WiseTech's REST API, Descartes' web services, Magaya's SOAP interface).
The extraction batch is sized to hit the airline cutoff — a mid-afternoon batch typically has 3–4 hours to complete before the tender deadline, so per-field mode is comfortably feasible even on 500-HAWB days.

For time-critical express shipments, run a single-shot pipeline: HAWB PDF arrives → extraction runs immediately → structured record posted to TMS → ops team gets an exception queue only for records that failed a validation check. Median end-to-end latency on a single HAWB is 15–40 seconds depending on the model tier chosen.

Step 5: Run the cross-document consistency checks

This is where the pipeline stops being an extraction exercise and starts being a shipment-integrity system. For every incoming shipment package, once every document has been extracted:

HAWB → MAWB link. Confirm every HAWB has a mawb_number that resolves to an extracted MAWB record in the same operating window. If the MAWB is not yet issued (many HAWBs are keyed first), flag for the consolidation planner to assign at cutoff.
MAWB check-digit validation. Verify the MAWB check digit programmatically. A single mistyped digit at intake propagates through the FWB message to the airline and blocks the flight tender — catch it at ingest.
Weight reconciliation. Sum HAWB gross weights under a MAWB and confirm they equal the MAWB total gross weight (within a 2% tolerance for consolidation packaging). Flag any deviation over the threshold.
Consignee/shipper reconciliation. Confirm the shipper block on the HAWB matches the shipper block on the commercial invoice using fuzzy string matching on name + address. Flag mismatches for ops review.
Weight reconciliation across HAWB and packing list. Sum piece weights on the packing list and confirm they equal HAWB gross weight within tolerance.
HS code validation. Confirm every HS code on the commercial invoice is a valid HS-2022 code and appears in your customs classification catalogue for the destination country.
Value reconciliation. Confirm commercial invoice total ≈ HAWB declared value for customs (unless NVD/NCV declared).
DGD interlock. If any DG indicator is present on the HAWB or MAWB, confirm a corresponding DGD document exists with matching UN number, proper shipping name, PI, and quantity. If the MAWB is on a passenger aircraft, confirm no CAO-only substance is on the DGD.
Screening interlock. For every piece on every HAWB going out on a US-origin flight (or any passenger flight under EU rules), confirm a screening record exists from a valid CCSF/RA identifier, with a screening timestamp after pickup and before tender.
Sanctions and controls screening. Confirm consignee, shipper, and notify party are not on any sanctions list. Confirm HS code against ITAR/EAR/dual-use catalogue.

Each of these checks is a database query or a lightweight rule against structured data DocumentIQ extracted. Ten to fifteen checks that used to take an ops clerk 12–20 minutes to walk manually per consolidation now run in under a second and produce a pass/fail exception list per shipment.

Step 6: Use chat as the operational query layer

Once the structured data is in place, the DocumentIQ chat assistant becomes the query layer for the entire consolidation database. Real questions that come up in an air cargo operations control tower:

"For flight EK202 on July 15, list every HAWB where the shipper's declared value differs from the commercial invoice total by more than $500."
"Show me every HAWB in the last 30 days going to LHR that had a DG indicator but no matching DGD document at ingest."
"Which of my CCSFs is screening the highest share of lithium-ion battery shipments this month, and what is the average time between pickup and screening completion?"
"List every consignee shipped to in the last quarter whose EORI is null on the HAWB and whose commercial invoice value exceeded €1,000 — these will hit customs holds."
"For MAWB 157-12345675, produce the full document trail: HAWBs, invoices, packing lists, DGDs, screening records, and manifest inclusion — with pass/fail for every consistency check."

Each of these becomes a natural-language query that returns a cited, source-linked answer with confidence scores and page references — because the underlying data is structured, indexed, and traceable back to the source PDF.

The Payoff

The gain on air cargo document intake is unusually large because the manual baseline is unusually painful.

A conservative model for a mid-sized freight forwarder handling 500 HAWBs per gateway per day, with an average ops clerk cost of $65,000 fully loaded ($34/hour), an average manual HAWB keying + cross-check time of 5.5 minutes per HAWB across all supporting documents, and a rework-loop rate of 12% (each HAWB touching keying more than once due to typos, missing fields, or DGD mismatches):

Manual annual cost per gateway: 500 HAWBs/day × 260 operating days × 1.12 × 5.5 minutes × ($65,000 / 2,080 hours / 60) ≈ $407,000 / year in ops clerk time on HAWB keying alone.
Automated pipeline cost per gateway: 500 × 260 × 1.12 × per-field extraction credits (typically 6–8 documents × ~$0.06 per document in LLM cost) ≈ $70,000–$95,000 / year in extraction cost, plus infrastructure.
Ops time redirected to genuine exception handling — the 3–5% of shipments where the automated cross-checks correctly flag something a human should look at.

Beyond the direct cost, the operational upside is larger:

Cutoff performance improves. Median time to structured HAWB record drops from 5–7 minutes to under a minute. Airline tender deadlines that used to be met by 89% of shipments start being met by 97%+.
Airline chargebacks drop. Weight discrepancies, MAWB check-digit errors, and manifest-versus-tender inconsistencies that trigger airline correction fees drop by an order of magnitude.
Screening compliance holds up to audit. Every screening record is machine-verified against every piece on the HAWB at ingest. TSA and Regulated Agent audit reviews become a database query, not a warehouse dig.
Customs holds decrease at destination. Fewer HAWB-vs-invoice-vs-packing-list mismatches means fewer destination customs holds, which means fewer detention and demurrage charges billed back to the forwarder.

We ran the numbers alongside our ROI calculator for a Tier 2 forwarder with three gateways last quarter, and the payback period on the switch was under seven weeks — including annotation setup time and TMS integration work.

Where AWB Extraction Fits into a Broader Logistics Automation Program

Air freight documentation does not live in a vacuum. The same forwarder that handles air also runs ocean, road, and rail, and the document classes overlap materially. The MAWB/HAWB pattern maps 1:1 onto ocean freight's Bill of Lading and House Bill of Lading pattern. The commercial invoice, packing list, and Certificate of Origin are common across every mode. Customs declaration workflows — ISF 10+2 for ocean, ENS for EU air, ACI for Canadian air — sit downstream of every consolidation, air or ocean.

Once a forwarder has an LLM-based extraction pipeline running against air freight paperwork, extending it to ocean bills of lading, freight audit workflows (see freight invoice audit), proof of delivery (see POD processing), warehouse receiving, and customs pre-alerts is largely a matter of adding new DocumentIQ projects to an already-working pipeline. The logistics solutions overview walks through the full document map, and the customs and trade compliance function page walks through the compliance side specifically.

What to Do Next

If you are running an air cargo forwarder ops team, or a station manager measuring cutoff performance, or a compliance manager preparing for a TSA / Regulated Agent audit, the practical next step is small and cheap:

Pick one document class — HAWBs are usually the highest-value, highest-volume starting point — and set up a single DocumentIQ project for it.
Feed in 30 recent HAWBs across your top-5 shipper account groups.
Define the extraction fields from the list above.
Annotate 5–10 canonical documents to teach the model your gateway's TMS-generated HAWB layouts and your top shippers' formats.
Compare the extracted output against your existing manually-keyed TMS records for the same 30 shipments.

You will see the accuracy floor for yourself in an afternoon, and you will see whether the cross-document interlock checks — which are the entire value — hold up against your real traffic.

For the parallel document classes (MAWB, DGD, screening record, commercial invoice, packing list), the setup pattern is identical — one project per class, per-field extraction, a small annotation library per format family, and the same interlock check layer glued on top.

If you want a walkthrough for your specific station mix, airline base, or consolidation model, get in touch with the Algoscale team — we have rolled this pattern out for freight forwarders and 3PLs across the US, EU, and APAC gateways, and we can share the field schemas, annotation libraries, and interlock check rules we have found actually hold up in production.

Related reading:

Related DocumentIQ pages:

Related Algoscale services: