Leermoment 1: de tarieflogica is te complex voor het bestaande systeem
Brandstoftoeslag is geen vast percentage meer. Hij verschuift wekelijks op basis van een indexering, verschilt per relatie of contractgroep, en geldt soms per rit, soms per gewichtsband, soms per regio. Tolheffingen komen er bovenop, en last-mile toeslagen voor binnenstedelijke leveringen voegen weer een extra laag toe. Het probleem: de meeste TMS-pakketten zijn gebouwd op vaste tariefstructuren. Je kunt een matrix invullen, maar zodra de logica meer dan twee variabelen heeft, houdt het systeem op. De planners kennen de correcte toeslag wel, maar kunnen hem niet kwijt in de software. Dus schrijven ze hem op een post-it, of onthouden ze hem, of gooien ze hem in een Excel naast het systeem. Dat werkt zolang de planner er zit. Zodra hij vakantie heeft, verdwijnt de kennis. Het structurele probleem is niet het personeel, maar een datamodel dat de tarieflogica van de operatie niet aankan. Software voor het doorberekenen van variabele transportkosten moet die logica kunnen vastleggen, per klant en per tariefelement, zodat de berekening niet in iemands hoofd zit maar in het systeem.
Leermoment 2: handmatige correcties komen structureel te laat
De brandstofindex wordt maandelijks of wekelijks bijgewerkt. Dat is op zichzelf geen probleem, zolang die update ook direct doorwerkt in de berekeningen voor lopende en nieuwe ritten. In de praktijk werkt het anders. Iemand past de tabel aan in Excel of in een losse module van het TMS. Maar die aanpassing wordt niet automatisch opgepikt door de facturatiemodule. Facturen gaan eruit op basis van de oude index. Pas als een klant belt, of als de debiteurenadministratie de aantallen controleert, valt het op. Dan volgt een creditnota en een herberekening. Dat kost tijd aan twee kanten: intern voor de correctie, en extern voor de relatie die wacht op de juiste factuur. Wat je wil, is dat een tariefswijziging op één plek wordt ingevoerd en van daaruit direct doorwerkt op alle relevante ritten, orders en factuurregels. Dat klinkt vanzelfsprekend, maar het vereist dat TMS, tariefbeheer en facturatie hetzelfde datamodel delen, of in ieder geval in realtime met elkaar praten. Veel bestaande architecturen hebben die koppeling niet.
Leermoment 3: TMS en facturatie lopen uit de pas
Het derde breukpunt is de koppeling zelf. TMS registreert de rit, de lading, de route en de toeslagen. Facturatie verwacht een factuurorder met de juiste regels, btw-codes, relatiesleutels en kostensoorten. Tussen die twee systemen zit een integratie, vaak gebouwd met een middleware-laag of een periodieke export. Die integratie synchroniseert niet altijd in realtime. Soms wordt er één keer per nacht gesynchroniseerd, soms handmatig getriggerd. Ondertussen hebben planners ritten gecorrigeerd, zijn toeslagen bijgesteld, of is een klantafspraak gewijzigd. De factuur reflecteert de werkelijkheid van gisterochtend, niet van vandaag. Het resultaat: een factuur die klopt volgens het TMS, maar niet klopt voor de klant. Disputes, betalingsvertragingen en administratieve ruis zijn het gevolg. De oplossing is geen nieuwe middleware. Het is een architectuur waarbij de ritregistratie en de factuurlogica hetzelfde bronsysteem raadplegen, zodat er geen vertraging en geen vertaalslag tussen zit.
Wat vraagt dit van de software-architectuur?
De drie leermomenten wijzen naar hetzelfde: doorberekening van variabele transportkosten aan klanten vraagt om een systeem dat tarieflogica als eerste klasse onderdeel behandelt, niet als bijvangst van het TMS. Dat betekent concreet drie dingen. Eén: een flexibel tariefmodel dat per klant, per tariefelement en per periode geconfigureerd kan worden, zonder dat je een ontwikkelaar nodig hebt voor elke aanpassing. Twee: een enkelvoudige bron voor tarieven en toeslagen die zowel de planningsmodule als de facturatiemodule voedt, zodat correcties direct en zonder handmatige stap doorwerken. Drie: een koppeling tussen ritregistratie en factuurvorming die niet afhankelijk is van een nachtelijke synchronisatie, maar op het moment dat de rit wordt afgesloten de juiste factuurregels klaarstaan. Dit is geen luxe architectuur voor grote partijen. Het is de minimale basis voor elk transportbedrijf dat variabele toeslagen correct en tijdig wil doorberekenen. Of je dat bereikt door je bestaande TMS uit te breiden met een gerichte AI-laag via Bonsai AI Workers, of door het kernsysteem volledig opnieuw te bouwen als een Digital Twin van je operatie, hangt af van hoe ver je bestaande architectuur van deze basis afzit.