Data quality is the actual bottleneck of logistics automation, not the code. Early September, a fuel card reconciliation ran for a customer for the first time. 538 lines from the card statement. 340 of them matched to a vehicle in the master data. 63 percent. A solid start for an automation that someone otherwise runs by hand in a spreadsheet. Four days later, the same workflow ran again. Almost the same line count, 544 instead of 538. This time, six lines matched. Just over one percent. The workflow status still read "success". No error. No warning in the system. Just one number buried in the metrics that almost nobody reads anymore, because the status line stayed green.
The agent had not changed. The vehicle master data behind it had.
That is the thesis of this piece: most automation projects in logistics do not fail on the code. They fail on the data the code runs against.
A matching step needs two things: a line from the raw file and a vehicle master record to check it against. The line is almost always readable, plate, date, amount, quantity, all there. The problem sits almost always on the other side.
Plates arrive in three spellings: with a hyphen, without one, with a space instead. Sometimes there is a letter O where the master record has a zero, because someone typed it wrong once. Loading points have a street address but no coordinates, even though geofencing needs exactly that. Customer numbers exist twice because a branch got entered a second time. Drivers sit in the system without a current vehicle assignment, because the last handover was never logged. Fuel cards run on vehicles that were deregistered months ago. Subcontractor vehicles show up in telematics or on a fuel card. Never in the company's own vehicle master. Because they were never supposed to be there in the first place.
Any one of these six categories alone is enough to stall a matching step. In practice, they show up together.
The runs come from our own operational log. Queried live. After the first two runs at 63 percent match rate, the ratio collapses. From 10 September onward, it sits between zero and just over one percent, across five more runs through 14 September. Seven of the nine runs still report "success" or "warning", not "error". The "duplicate" drop category grows from zero to 348 lines over the same period. The "not-in-master" category stays close to flat, 174 to 175 lines, run after run.
That is the core problem: a run without an error is not proof that something happened. It is only proof that nothing crashed. For a process meant to match money to a vehicle, that is the wrong evidence. (And the growing duplicate count here is not a sign of worse raw data. It is a sign that the matching logic itself started checking against a stale state. Not the current assignment. That is still a master data problem, just one layer down.)
The fix is not more intelligence in the matching step. It is a fixed order of operations before any matching happens at all.
First, the canonical form. Every plate gets normalized on read: no hyphen, no space, uppercase, letter O and zero told apart explicitly. The master record is held in the same canonical form. That way the matching step always compares like with like, whatever spelling the source delivers.
Second, the reason column. Every line that cannot be matched does not disappear. It lands in a review queue with a fixed reason: passenger car, duplicate, not-in-master, or another fixed category. The same principle carries the order capture from mail and PDF piece: the match rate on its own is not the result that matters. The reason column on the lines that failed is. It shows where the master data lags reality, not just that it does.
Third, someone actually has to work the queue. A list of reasons nobody looks at is not progress over silent discarding. It is only better documented.
An automation rate on a single day says little. One run can match 90 percent on a good day and one percent on a bad day without a single line of code changing. What matters is the ratio over weeks, with the reason column explaining every dip.
If "not-in-master" spikes in a given week, a new subcontractor probably came on board whose vehicles are still missing. If "duplicate" spikes, something in the matching logic itself likely broke, as in the example above. If "passenger car" stays flat, that is not an error, it is a normal share of raw data that never belonged in the fleet in the first place. Without the categories, all three situations look like the same number: fewer matched. With the categories, a drop becomes a diagnosis instead of an alarm.
In most forwarders today, the vehicle master data has no owner with a clear trigger to maintain it. It gets updated whenever there is time, usually by dispatch, because dispatch needs it for its own work anyway.
That stops being enough once several automations read the same master data in parallel. Three triggers need a fixed rule. Not just good intentions. First, registering or taking over a vehicle. Second, deregistering or selling one. Third, onboarding a new subcontractor. Each of these three should update the master record on the same day, not sometime before the next report is due. Fleet is the first to know the trigger happened. Billing is the last to notice the gap, usually only once a fuel card or toll statement does not add up.
A canonical form and a review queue do not fix "not-in-master" by themselves. They only reliably show that the vehicle is missing. Someone still has to enter it. The automation shortens the path to the finding, it does not replace the person who maintains the master data. And a review queue nobody works through becomes its own kind of master data clutter, just moved to a different place. Adding a reason column without naming who processes it produces a better symptom, not a better result.
How clean is your vehicle master data really, checked against plates from three different sources? Send me one anonymized week of fuel card or toll data, and I will show you the match rate and the reason column behind it.
