One bad row should not stop the freight plan.

By the Autowhat AI team · 7 October 2026 · Filed under FreightPlan

A logistics analyst we would recognise anywhere keeps the rate cards for a plant-to-depot network in several spreadsheets: one per carrier, one for fuel surcharges, another for tolls, plus a demand file from sales. Every month the plan is rebuilt from these. And most months, something breaks. A depot name is spelled differently in two files. A rate is typed as text. A new lane appears with no carrier. The model stops, the analyst spends days hunting, and the business ends up running on last month’s plan.

The spreadsheet is not the problem

It is tempting to say the answer is to stop using spreadsheets. In practice, carriers send rate cards as spreadsheets, finance shares demand as spreadsheets, and people are fast with them. The format is not the issue. The issue is how a planning system treats a file with one bad row in it.

Most homemade models are all-or-nothing. Either every row is clean and the plan runs, or one row is wrong and nothing runs. That makes the whole plan hostage to the worst row in the worst file, which is why the plan is so often late.

A smaller version you may recognise

Think of a bakery chain whose central kitchen sends bread and cakes to a dozen outlets each morning, using two or three local transporters. The person planning the vans keeps a sheet of outlet addresses, a sheet of transporter rates and a sheet of daily orders. If one new outlet is missing its rate, the sensible thing is to flag that outlet and plan the other eleven, not to stop planning altogether. Nobody would hold back the whole morning’s dispatch over one missing cell. Yet that is how many monthly freight models behave.

What row-by-row validation changes

FreightPlan loads eight datasets as CSV: plants, depots, lanes, carriers, fleet, rate cards, demand and the trip log. Each is validated row by row. A bad row is rejected with the reason and the fix; the rest of the file loads. Before anything is committed, a staged upload shows row counts, missing columns and the effect of upserting versus replacing the existing data. Every upload is kept in the audit trail.

The same idea, inside the optimiser

The philosophy carries through to the plan itself. In FreightPlan, unserved demand is a penalised slack, so you always get a plan back, plus the exact shortfall. If a plant cannot make enough or the fleet cannot cover every lane, the result does not simply fail. It tells you which depot is short and by how much, and the shortfall is reported, never hidden. That is the planning equivalent of loading the good rows and naming the bad ones.

Habits we would keep, whatever the tool

1. Agree one name for every plant, depot and carrier, and use it in every file.
2. Store rates as numbers with units, never as notes like “approx” or “same as last”.
3. Check new lanes for a carrier and a rate before the month starts.
4. Look at what a replacement upload will change before you commit it.
5. Keep every version, so a surprising plan can be traced to the file that caused it.

None of this is glamorous, and that is the point. The optimiser and the variance analysis get the attention, but they are only useful if this month’s data reaches them. For how the budget is built once the data loads, see freight budget planning for plant-to-depot networks; for what happens at month-end, freight variance analysis. Everything else is on the FreightPlan guides page.

See it on your own data. FreightPlan — Budget freight, explain the gap. Book a 30-minute working session with an engineer.

General guidance, current as of the date above. Figures and examples are illustrative unless a source is linked.