Drafting dangerous goods declarations from the SDS: what software can check, and what stays with the specialist

Every air freight forwarder knows this moment. A booking arrives by email with a commercial invoice, a packing list and a 14-page safety data sheet attached. Somewhere in that pile is the information needed to prepare the Shipper’s Declaration for Dangerous Goods. Finding it, copying it and checking it is slow, manual work. It usually falls on the few people in the office who really know the IATA Dangerous Goods Regulations.

We work on this problem with forwarders every day. Here is how we think about it, step by step.

Step 1: Read the SDS, mainly Section 14

A safety data sheet has 16 sections. For transport, Section 14 matters most. It lists the UN number, the proper shipping name, the transport hazard class, any subsidiary hazard, and the packing group.

In practice, Section 14 is less clean than it sounds:

• Some SDS list only road or sea data (ADR, IMDG) and nothing for air.
• Some are years old and refer to outdated classifications.
• Some say “not regulated”, with conditions hidden in a footnote.
• Some arrive as scans, in Japanese, German or Chinese.

Software can read all of this. It extracts the fields, notes which transport mode they refer to, and links every value to the line it came from. A person checking the draft can then see the source in one click.

Step 2: Combine it with the booking

The SDS describes the substance. It does not describe the shipment. Much of the declaration comes from the booking and the packing list: the number and type of packages, the net quantity per package, the departure and destination airports, and whether the goods can go on a passenger aircraft or only on a cargo aircraft.

So a draft declaration always combines at least three documents. That’s also where most errors begin.

Step 3: Cross-check everything against everything

This is where software saves the most time. Once the data is extracted, it checks:

• SDS vs booking: does the commodity match? Does the declared quantity match?
• Booking vs packing list: same number of packages, same weights?
• Declaration vs ASN: same items, same quantities, nothing missing and nothing extra?
• Rules: is the combination of UN number, name, class and packing group valid? Is the quantity per package within the limit for the aircraft type?

Each discrepancy gets a flag, a severity and a pointer to the source documents. The goal is simple: catch problems before cut-off, not at acceptance.

A worked example

A customer books 4 drums of paint from Tokyo to Frankfurt. The SDS gives UN1263, Paint, Class 3, packing group II.

The software drafts the declaration and runs the checks. It finds two issues:

1. The booking says 4 drums. The packing list says 5.
2. Each drum holds 20 litres. For this entry, the passenger aircraft limit is 5 litres per package. The shipment must be cargo aircraft only, but the booking doesn’t say so.

The DG specialist sees both flags, confirms the count with the customer, sets the aircraft limitation and approves the declaration. Without the checks, both issues might have surfaced at the airline counter.

What the DGR data covers, and what it doesn’t

The validity and quantity checks need the current List of Dangerous Goods from the IATA DGR. For every UN number, it gives the permitted names, classes, packing groups, packing instructions and maximum quantities per package. The DGR is licensed data, updated every year, and any system that checks against it has to use the current edition.

Even with perfect data, some things stay outside what software can confirm:

• Whether the substance was classified correctly in the first place. That’s the shipper’s responsibility.
• Whether the packaging physically meets the specification marks.
• State and operator variations that depend on the route and the carrier.
• Whether the person signing is trained and authorized.

Why the specialist always approves

Dangerous goods mistakes are not ordinary data errors. A wrong packing group or a missed aircraft limitation is a safety risk, not a typo. So we design these workflows around one rule: software drafts and checks, and a qualified person decides.

In practice this means:

• No declaration is sent or submitted automatically.
• Low-confidence fields are highlighted, never hidden.
• Every value links back to its source document.
• Every correction is logged and used to improve the next draft.

The specialist’s time moves from typing and searching to judging. That’s the part only they can do.

What we’ve seen in practice

At a European forwarder, we read dangerous goods data from customer documents and create air and sea shipments in CargoWise from customer emails. At a global LCL consolidator, we detect hazardous cargo in quote and booking emails and route it to the right desk. In both cases, the people with the expertise stay in charge. They just spend less of their day finding information.

If your DG desk spends more time searching than judging, we’d be glad to compare notes.