Buying LTL software? Test the work from classification to invoice
Key Takeaways
- An LTL test is end to end only if the facts set at quote (class, weight, dimensions, pallet count and accessorials) are carried, unchanged or knowingly changed, all the way to the invoice.
- Classification is an input to test, not a feature to take on faith: ask where each class comes from, how it is checked at quote and who owns the product data behind it.
- Seed two or three changes into the test load, such as an added pallet, a liftgate the quote missed and a carrier reclassification, and watch which stage catches each one.
- A reclassification should be handled against the booked rate with evidence and an approval decision, not paid or disputed from memory.
- Wilson, by Cartage, runs LTL from quote to payment with the customer's approved carriers and approval rules, and audits each carrier invoice against what was booked.
What does an end-to-end LTL software test actually prove?
It proves that the shipment facts agreed at quote survive every handoff to the invoice, and that any change along the way is caught at the stage where it happens instead of three weeks later on the bill. A demo that shows a good quote, a clean booking and a delivered status can pass every screen and still fail that test.
LTL is unusually exposed to drift. The class and dimensions a coordinator used to get a rate may not match what the warehouse loads, what the BOL says, what the carrier's terminal measures or what the invoice charges.
The real question is whether one set of shipment facts moves from quote to invoice, and whether the software notices when those facts change. If you need a stage-by-stage demo script, bringing one LTL load to the demo lays one out. The test card below is narrower: it follows the data itself.
The nine handoffs where LTL data has to carry forward
Each stage should inherit specific fields from the previous one and add its own; the test checks both.
Classification inputs. Product description, NMFC item if you use one, class, weight per unit and dimensions. These come from the order or your product data.
Quote. Inherits class, total weight, handling units, dimensions and requested accessorials. Adds carrier, rate and quote reference.
Booking. Inherits the selected quote. Adds the rate confirmation and the carrier's acceptance.
BOL. Inherits shipper, consignee, pieces, weight, class and special instructions. The driver signs it, so a mismatch here becomes the carrier's evidence later.
Pickup. Inherits the window and location. Adds the actual pickup time and any change in pieces the driver notes.
Tracking. Inherits the PRO number. Adds terminal scans, delays and revised ETAs.
Delivery. Inherits the consignee's requirements, such as appointment or liftgate. Adds the delivered time and any exceptions noted.
POD. Adds the signed proof of delivery, including shortages or damage noted by the consignee.
Invoice. Should match the booking unless something documented changed. Adds reweigh, re-dimension, reclassification and accessorial charges.
Where class comes from, and how it should be checked
Software can only defend a class if it records where the class came from. In most companies, class reaches a shipment in one of three ways: a stored NMFC item and class on the product record, a class a coordinator types in from experience, or a density calculation from weight and dimensions. Stored classes go stale when packaging changes, typed classes copy the last similar load, and density calculations are only as good as the dimensions entered.
An illustrative density check: four pallets at 48 x 40 x 50 inches are about 55.6 cubic feet each, or 222 cubic feet in total. At 1,600 pounds, that is roughly 7.2 pounds per cubic foot. If the class on the order implies a much denser shipment, someone should see that before the quote goes out, not after the carrier measures it.
Things to test at quote:
- Is the class on the shipment shown with its source and the inputs behind it?
- If weight or dimensions change after quoting, does the quote get flagged for a refresh or does the old rate stay attached?
- Are accessorials the consignee needs, such as liftgate, residential or appointment delivery, requested at quote, or do they appear first on the invoice?
When a carrier reclassifies, it usually reweighs or measures the freight at a terminal and bills a different class. The software should place the corrected charge next to the booked rate, the class and inputs used at booking, the BOL and whatever inspection evidence the carrier provides. For how that comparison works in depth, see quote versus invoice after a reclassification.
How to judge the results
Score each handoff on whether the data carried forward on its own and whether a seeded change was caught where it happened.
- Retyping is a fail for that handoff. If someone copies weight from the quote into the BOL, the chain broke there, even if the numbers end up right.
- A change caught one stage late is a partial. An added pallet should surface at pickup or on the BOL, not on the invoice.
- A reclassification needs a decision path, not just a flag. Pass when the invoice is held against the booked rate, the evidence is attached and the decision goes to the person your rules name. Fail when it is paid without review or left in a queue without context.
- Separate data ownership from software behavior. If the class was wrong because the product record was wrong, that is a catalog fix. The software passes if it showed the inputs and made the gap visible.
- Keep classification claims honest. Ask any vendor exactly where class comes from in its workflow and who is responsible for the inputs.
The end-to-end LTL test card
Run one real LTL shipment with three seeded changes, and fill in the last column as it moves.
| Checkpoint | Must carry forward | Seeded change | Passes when |
|---|---|---|---|
| Inputs | Class, source of class, weight, dimensions, pieces | None | Class shown with its source |
| Quote | All inputs plus requested accessorials | Consignee needs liftgate, left off the order | Accessorial requested or flagged before booking |
| Booking | Quote, carrier, rate | None | Rate confirmation matches the quote |
| BOL | Pieces, weight, class, instructions | Warehouse adds a fifth pallet | BOL updated or the change raised before pickup |
| Pickup | Window, location, pieces | Same added pallet | Carrier informed; booked rate re-checked |
| Tracking | PRO number | Terminal delay | New ETA and reason recorded; configured people notified |
| Delivery and POD | Consignee requirements | Consignee notes a shortage | POD filed with the note visible |
| Invoice | Booked rate and documented changes | Carrier bills a higher class | Held against the booking with evidence; decision routed |
| Payment | Approved amount | None | Paid only within approval rules |
After the run, record three things: how many handoffs carried data without retyping, which stage caught each seeded change, and whether the final shipment history shows the class, the change and the decision in one place.
How Wilson, by Cartage, runs the chain from classification to invoice
Wilson, by Cartage, is an AI logistics agent that replaces the TMS for freight execution and runs LTL shipments from quote through invoice audit and payment. It works from the order data the company already has: ERP feed, scheduled file drop, spreadsheet, email or API. For the category, see what an AI logistics agent is.
On the test card, Wilson works from the class, weight and dimensions the shipment carries, and the company remains responsible for the accuracy of that product data. Wilson requests quotes from the customer's approved carriers and negotiates against the customer's rate targets under configured rules and approval limits. It books, produces rate confirmations, bills of lading, packing slips and pallet labels, and schedules the pickup. It tracks each load with the best available source: carrier API, GPS/ELD where available, the carrier website by PRO number, and email or calls when those don't answer.
At the end of the chain, Wilson audits and reconciles each carrier invoice against what was booked and the documented changes, and pays carriers from the Wilson Wallet under the customer's approval rules. A reclassified or unexpected charge outside those rules waits for a person. Messages, confirmations and changes are recorded in the shipment history, which is where the test card's evidence lives. Wilson starts with assisted execution.
Bring one LTL shipment that was reclassified on the invoice, with the class, weight and dimensions you booked it under, and see how Wilson carries those inputs from quote to the invoice check.
Sources
- Cartage, Wilson product FAQ and product scope, October 2026: https://cartage.ai