Dangerous Goods Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the "build our own rules database" scope failure happen so often?

It looks tractable from the outside. You already have the books, your safety adviser knows the entries you actually ship, and the first hundred UN numbers go into a table in a fortnight. What that fortnight does not reveal is the maintenance curve: packing instructions get renumbered, quantity limits shift, entries are added, and state and operator variations sit on top of everything and change without a schedule.

Six months after go live the table is stale, and stale is worse than absent, because a spreadsheet everyone knows is old gets double checked and a system nobody suspects does not.

The fix is a hard architectural line drawn before the first sprint. Licence maintained regulatory content from a specialist source and build only the workflow around it: your substance master, your order entry, your load building, your evidence trail. Put the content behind an interface you own, so an edition change is a content update rather than a code change and so you can change supplier later without rewriting your operation. If a developer offers to build the rules, that is a disqualifying answer, not a negotiating position. It will not be cheaper and you will own the liability.

What goes wrong with the substance master data?

Your ERP (Enterprise Resource Planning) holds a material number, a description and a weight. Dangerous goods needs a UN number, proper shipping name, class and subsidiary risk, packing group, flashpoint, marine pollutant status, concentration and whether the packaging in use is authorised. Those attributes live in a safety data sheet library or a spreadsheet, keyed by product name rather than by the material number your orders reference, which means a mapping step, which means a person.

The failure that follows is quiet. A formulation changes concentration nine months ago, the safety data sheet was updated, and nothing linked that update to the classification your shipping dock uses. Nobody was negligent. There was simply no mechanism.

What works is making the dangerous goods attributes a first class, versioned part of the material record with effective dates, owned by the safety function and visible to everyone. A concentration change then triggers a classification review as a task rather than surfacing as a surprise at a terminal. Document extraction has one clear job here: supplier safety data sheets arrive as PDFs in every layout imaginable, and an extraction pass that reads the transport section and compares it against what you currently hold raises a difference for a human to approve. It does not classify anything. It notices that a supplier changed something quietly.

Why do the ERP, order entry and warehouse integrations break after launch?

The integration risk in this domain is not that a feed stops. It is that a feed keeps running while the meaning underneath it changes. A new pack size is created in the ERP and inherits nothing about hazard attributes. A material is reactivated after two years with a classification tied to a rule edition that no longer exists. A warehouse system is upgraded and the pallet build event you were subscribing to now fires at a different point in the process, so segregation is evaluated after the pallet is wrapped instead of before.

Order entry integration has its own hazard. The determination has to run against the mode and route being quoted, which means the integration needs the intended mode at a point in the process where sales often has not committed to one.

Design for it explicitly. Every determination stores the rule edition and version that produced it, so a stale answer is detectable rather than merely wrong. New or reactivated materials are blocked from dangerous goods order lines until classification exists, rather than defaulting to non regulated. Subscribe to warehouse events by business meaning, not by technical trigger, and re verify after any upgrade. And alert on the absence of expected traffic, because in a compliance system a check that stopped running looks exactly like a week with no hazardous shipments.

What happens when segregation and competence are not covered?

Any tool will tell you whether a single substance is shippable. The risk is created when substances are combined, and that combination only exists at the moment a load is built. Sea freight carries explicit segregation requirements between classes. Road has load compatibility rules and quantity thresholds that change placarding and driver qualification. The failure that catches people out is aggregation: four consignments each individually below a limit, consolidated onto one truck, collectively above it.

Competence is the other half. After an incident the questions are consistent: who classified this, against which edition, were they trained and current, what packaging was specified, who packed it and who signed the declaration. If those answers live across an email chain, a training spreadsheet and a filing cabinet, the finding tends to be about your system rather than the shipment.

Two fixes, both structural. Evaluate segregation and aggregate thresholds at the point the pallet or container is built, inside the tool the warehouse already uses, so a blocked combination is refused before wrapping rather than discovered at a terminal. And bind competence to action: the system refuses to let an untrained or lapsed user sign a declaration because it knows their training record, rather than recording the violation after the fact.

Should you build custom or configure what you already own?

Buy and stop here if you ship a limited set of UN numbers by road only, from one or two sites, at volumes where a trained person can genuinely check every consignment. Labelmaster DGIS, Exis Technologies Hazcheck, IATA DG AutoCheck and DGOffice all carry maintained regulatory content and are good at what they were designed for, and a build at that scale would be indulgent. The same applies if you are a forwarder whose role is checking other people's declarations rather than originating them, because that is precisely the job those tools exist to do.

Before concluding a tool has failed you, be specific about which failure you have. If your pain is document accuracy on consignments you present, the incumbent products address it directly and you should invest in using them properly. If your pain is that checks run too late, or that mixed loads are wrong, or that your substance master and your orders disagree, that gap sits inside your own systems and no external validator can reach it.

Build when two or more of these are true. You ship across more than one mode and the same material behaves differently by mode. Your substance data does not live with your orders. You consolidate mixed loads. Multiple sites apply the rules inconsistently. Or a carrier or regulator has already raised a finding, which turns this into a licence to operate question rather than an efficiency one.

How do hidden costs get into the quote?

Mode count is the line most often understated. Air, sea and road each carry their own document set, their own limits and their own exception handling, so a second mode is real scope rather than a configuration flag. Ask for each mode to be priced separately and the quotes become comparable.

Multi leg movements are the next. A consignment that flies then drives must satisfy both regimes with the strictest constraint governing, and modelling that properly is more work than modelling either mode alone.

Then the substance master itself, which is discovery work before it is engineering work. Most operations find during discovery that one commercial product carries different classifications by concentration or pack size and that nobody has reconciled the record for years, and the safety function needs real time to review and sign it off. Then label and marking generation, which is fiddly physical work with size and durability requirements. Then the content licence, which is an ongoing operating cost that belongs in the business case rather than appearing after go live. And finally the maintenance line, because an edition change every January is a scheduled event you should be funding, not absorbing.

What separates a build that works from one that fails here?

The builds that work move the check upstream. Determination runs at order entry against the mode and route being quoted, and returns a decision with reasons rather than a document: this line is acceptable as cargo aircraft only, this quantity needs a different packing instruction, this destination requires an operator variation the chosen carrier does not accept. The late check at the dock stays as a final gate, but it stops being the only gate. In our delivery experience this single change removes most of the four o'clock arguments, because the argument has already happened at ten in the morning when better options existed.

The builds that fail treat compliance as a per line check and discover in production that the risk was in the combination.

When you interview developers, ask three questions and weight them heavily. Do they intend to build the rules content, in which case end the conversation. How is a determination stored, where the only acceptable answer is immutable with the rule edition, the inputs, the user and the timestamp, not a status field on the order. And can they explain segregation without prompting. Then settle ownership before kickoff: the repository, the infrastructure and the freedom to change content supplier, in writing, because here you are also protecting the evidence trail you may need years from now.