Lesson 1: the rate logic is too complex for the existing system
Fuel surcharges are no longer a fixed percentage. They shift weekly based on an index, differ per account or contract group, and sometimes apply per trip, per weight band, or per region. Toll charges are added on top, and last-mile surcharges for urban deliveries add yet another layer. The problem: most TMS packages are built on fixed rate structures. You can fill in a matrix, but once the logic involves more than two variables, the system breaks down. Planners know the correct surcharge, but cannot enter it in the software. So they write it on a sticky note, memorise it, or dump it into a spreadsheet alongside the system. That works as long as the planner is there. The moment they go on leave, the knowledge disappears. The structural problem is not the staff, but a data model that cannot handle the rate logic of the operation. Software for passing on variable transport costs must be able to capture that logic, per customer and per rate element, so the calculation lives in the system rather than in someone's head.
Lesson 2: manual corrections are structurally too late
The fuel index is updated monthly or weekly. That is not a problem in itself, as long as the update also takes immediate effect in the calculations for current and new trips. In practice, it does not work that way. Someone updates the table in Excel or in a separate module of the TMS. But that change is not automatically picked up by the invoicing module. Invoices go out based on the old index. It only comes to light when a customer calls, or when accounts receivable checks the figures. A credit note and recalculation follow. That costs time on both sides: internally for the correction, and externally for the customer waiting on the right invoice. What you want is for a rate change to be entered in one place and from there to take immediate effect on all relevant trips, orders, and invoice lines. That sounds obvious, but it requires TMS, rate management, and invoicing to share the same data model, or at least to communicate in real time. Many existing architectures do not have that connection.
Lesson 3: TMS and invoicing fall out of step
The third failure point is the integration itself. TMS records the trip, the load, the route, and the surcharges. Invoicing expects an invoice order with the correct lines, VAT codes, account keys, and cost types. Between those two systems sits an integration, often built with a middleware layer or a periodic export. That integration does not always synchronise in real time. Sometimes it runs once a night, sometimes it is triggered manually. In the meantime, planners have corrected trips, surcharges have been adjusted, or a customer agreement has changed. The invoice reflects the reality of yesterday morning, not today. The result: an invoice that is correct according to the TMS, but not correct for the customer. Disputes, payment delays, and administrative noise follow. The solution is not new middleware. It is an architecture in which trip registration and invoice logic consult the same source system, so there is no delay and no translation step between them.
What does this demand from the software architecture?
The three lessons point to the same conclusion: passing on variable transport costs to customers requires a system that treats rate logic as a first-class component, not as a byproduct of the TMS. In concrete terms, that means three things. One: a flexible rate model that can be configured per customer, per rate element, and per period, without needing a developer for every adjustment. Two: a single source for rates and surcharges that feeds both the planning module and the invoicing module, so corrections take effect immediately and without a manual step. Three: a connection between trip registration and invoice generation that does not depend on a nightly synchronisation, but has the correct invoice lines ready the moment a trip is closed. This is not a luxury architecture reserved for large players. It is the minimum foundation for any carrier that wants to pass on variable surcharges correctly and on time. Whether you achieve that by extending your existing TMS with a targeted AI layer through Bonsai AI Workers, or by rebuilding the core system from scratch as a Digital Twin of your operation, depends on how far your existing architecture is from that foundation.