No software can invent a weight the shipper never sent. Worth saying aloud, because a lot of order automation software is sold as though it can.
What software can do is more useful than that. When the order arrives, it can detect the missing information, which means a call to the customer instead of a driver finding out when it is too late. With incomplete orders, catching that gap as early as possible is what matters most.
Why do freight orders arrive incomplete?
Transport orders are written by people who do not plan trucks. A shipper types an email in ninety seconds between two meetings. A broker sends a rate confirmation from a template with half the fields left blank.
Each sender writes down what matters to them: loading address, date, price. The details a carrier actually needs to plan the load are precisely the ones that get dropped: gross weight, packaging and loading meters, time window, and so on.
Dispatch offices absorb this. Everyone knows that one customer never sends a time window, which is why someone makes a phone call before booking. Experienced dispatchers know what customers keep forgetting, and that knowledge works until the call volume rises or the person who holds it leaves.
Nobody agrees on what "complete" means
The tanker driver cannot use a vehicle without an ADR class and a UN number. For the general freight carrier, loading meters and stackability come first. The pharma carrier has to settle the temperature range before anything else about the order can be dealt with.
There is no common list in road freight, because each operator has its own reasons, depending on cargo, distances, and clients. That is why a list of generic mandatory fields does not always fit an operator with specific requirements.
Onyven looks at this in only one way: the operator owns the rules and provides them during integration. They can be tailored to different clients, cargo types, or lanes. It is again the operator who decides whether a missing ramp contact stops the process or not. The software simply follows these rules without inventing its own. The biggest benefit is that your operators' expertise stays in force even when they are on holiday or on sick leave.
The check runs before anyone types
Your TMS also has mandatory fields. The difference is the order of events. The TMS records the error in a log entry only after the email has been received, read, and entered into the system. The validation sees only what was transcribed, and it fires after the manual work is done.
If a field was skipped, or filled with a placeholder to get past the red asterisk, the system is satisfied and the gap rides along to the ramp. Onyven reads the inbound document itself, whether it is an email, a PDF, or another document type. The exchange posting is read and structured on arrival, and the operator's completeness rules run against what the sender actually provided, before a person has spent a minute on it.
A flagged document at 07:40 is far cheaper to fix than a phone call from a driver at 14:00.
What changes for the dispatcher
The missing time window was always going to need a call to the customer. What changes is whether that call happens in the morning, prompted by a flag, while the customer's own dispatcher is at a desk and the plan is still soft, or in the afternoon, prompted by a driver standing at a gate that security will not open without a reference number nobody sent. The operator has to solve it either way, before unwanted costs pile up.
The information gap is identical in both cases. The cost is not. A flagged order also tells the dispatcher exactly what to ask. Instead of rereading an email to work out what is usable, the morning starts with a short list of specific questions per order, measured against the operation's own rules.
The system does not paper over a gap with a guess. A blank field forces a decision. A plausible wrong value gets waved through, and a plausible wrong weight is how a vehicle ends up over the axle limit. Flagging instead of filling is a deliberate choice: the dispatcher stays the one who decides what goes into the plan.
See it on your own ruleset
Catch the missing field at 07:40, not at the gate
Onyven reads inbound orders in whatever form they arrive and checks them against completeness rules you define, before a person has spent a minute on them.
Explore OnyvenGaps you can count
An absorbed gap leaves no trace. The call gets made, the load moves, and nothing records that a particular customer's orders needed two chase-ups each this week. A flagged gap is a data point. Flags accumulate into a record of which senders drop which fields, how often, in writing.
That record has uses. Internally, it shows where a short onboarding session with a customer's shipping team would pay for itself. Externally, it changes the tone of a rate conversation. "Most of your orders last quarter needed a call-back before we could plan them" is a sentence every carrier can currently feel and almost none can prove.
Where Onyven sits
Onyven is a decision layer that works above your existing TMS, not a replacement for it. It reads inbound orders in whatever form they arrive, checks them against completeness rules you define and we implement during integration, and puts the result in front of your dispatchers, who decide what to do with it.
Nothing about how your customers send orders has to change. That is rather the point: the gaps were never going to stop arriving. What changes is when you find them.
See the check run against your own ruleset. Book a demo at onyven.com.