Almost every forwarder in Germany runs a TMS. WinSped, Transporeon, SAP TM, or a system built in house. Order, tour, billing, all covered. Someone in dispatch still types orders out of a mail. By hand. Someone still logs into a customer portal to update status. Someone still keeps an Excel file the system does not know. The TMS runs fine. The TMS manual work is still there, every day, at the same spots.
My take, from several customer projects with all three systems: the TMS manual work does not sit inside the TMS. It sits at five spots in front of it and behind it. No matter the vendor. And it looks almost the same in every project.
This is not a review. Just a summary of vendor statements. Retrieved 2026-09-14.
WinSped from LIS is built as a set of modules. Order handling, dispatch, freight billing and staff scheduling sit at the core. Plus fleet management, telematics integration and automatic route planning. Orders come in, per the vendor, through its own interface, LISIN. Or through converters for FORTRAS, IDS and IFTMIN. Or through web entry.
Transporeon describes itself as a transportation management platform. Not a classic forwarding TMS. Four hubs sit at the center. Freight Marketplace for sourcing partners. Execution & Visibility for shipment tracking. Dock & Yard Management for time slots at the ramp. And Freight Audit for freight cost checks. The network connects, per the vendor, more than 1,500 shippers. With over 210,000 carriers.
SAP TM covers, per SAP, the full transport business. Offering, selling, demand handling, assignment, planning. Also procurement, subcontracting, steering, documenting, settling. Embedded in S/4HANA, SAP TM runs tied into master data, logistics and finance. Alongside modules like Sales and Distribution, Materials Management, Extended Warehouse Management.
Three different systems. Three different centers of gravity. Forwarding TMS, platform, enterprise system. A large system, tightly woven into SAP itself. But one shared core in all three: order, tour, billing.
The core is well covered. Every time. The edges are not.
First, orders arrive by mail or as a PDF. No customer sends a LISIN file. Or an IFTMIN message. He sends an order as an attachment. In his own format. Someone reads it. And types it into the TMS. That is how simple it stays.
Second, customer portals with no interface of their own. The customer has his portal. The TMS has its own API. The two do not meet, not without a built bridge. So someone logs in. And updates status by hand.
Third, status has to go back into the portal. The tour runs inside the TMS. The customer does not see the TMS. He sees his portal. Someone enters the status a second time.
Fourth, telematics arrival into the TMS. The position comes from the telematics provider. Not from the TMS itself. Without a built arrival detection, the arrival time stays a guess in the dispatcher's head.
Fifth, toll and fuel card reconciliation. And the dispatch plan in Excel or SharePoint. Both live next to the TMS. Because everyone there can read and edit them. Not only IT.
All five edges share one cause. They sit outside the data model a TMS can cover. A TMS knows orders, tours, freight rates. It does not know a foreign customer portal. A PDF layout. An Excel cell.
The pattern is the same at every edge. Whichever TMS sits behind it.
First, normalize the input. Mail, PDF or Excel gets turned into a fixed shape. With the same fields the TMS expects.
Second, operate the portal. A browser agent logs in. Reads or enters data. Right where no API exists.
Third, feed the result through the interface the TMS already has. Import, EDI, API. Or an import file into a mailbox. Whichever the TMS already offers. No shadow system. No separate database holding its own truth about a tour.
There is a fourth, invisible layer on top. The log. Every step gets a timestamp. So does every login. Every dropped row gets a reason too. Not because the TMS asks for it. But because an unattended process that quietly does nothing will not show up on its own. Even while it still reports success. A test mode before the first live night. An error counter with a pause after several failed runs in a row. A mail to dispatch instead of a silent gap. That belongs to the automation itself. Not as a nice extra.
One example from a live customer project. A converter reads the dispatch plan from Excel. And writes an import file for the TMS. Every 30 minutes since early June. Over 4,800 runs. 18 with an error. Roughly 99.6 percent clean, queried on 2026-09-14. More detail in the post on the dispatch-plan import. A second process operates a customer portal with no interface of its own. Login. Data pull. Logout. Every ten minutes. Both processes run next to the TMS. Neither replaces it.
A portal changes its login form overnight. A field moves. A selector stops matching. Then the process stops. Not the TMS. A good fallback catches that, a mail to dispatch instead of a silent stop. But it does not guarantee nobody steps in by hand for a moment.
A PDF layout can get parsed wrong. Especially one the customer never sent before. A number lands in the wrong column. A quantity gets read as a weight. That is why every normalization needs a review queue. Instead of a silent guess. With a reason for every dropped row. One a person can check in seconds.
Some edges truly belong inside the core system. Not next to it. If a customer orders often enough, in high enough volume, then a real EDI connection often wins. It beats a PDF reader that has to learn every new layout. The automation next to the TMS answers an edge that has no interface yet. Or one that changes too often, or too unevenly, for a fixed interface to pay off. Not every edge.
A third failure mode is the automation itself. If it quietly drops rows that should have counted, it becomes its own source of error. That is why a count belongs in every log. How many rows came through. How many did not. And why. A run that ends without an error and processes nothing is not a success. It is a silent outage. Only the count shows it, not the status.
Exasync is not a TMS vendor. We do not build our own order or dispatch system. No competing with WinSped, Transporeon or SAP TM. The core logic stays inside the TMS. What a tour is. What a freight rate costs. How an order gets dispatched. Our processes only deliver what the system itself cannot see. The foreign portal. The PDF in the customer's own format. The Excel cell. And they deliver it where the system already expects it, through an interface it already has.
That is the difference from an integration project, the option that usually comes up first. An integration project tries to bend the foreign system to fit the TMS. With a spec. With a project timeline. With a fixed interface for an edge that will change again next year. A small program next to the TMS costs less. It starts faster. And it can be swapped when the edge changes, without touching the TMS at all. No shadow database. No second truth about a tour. Just a path from A to B that used to run by hand.
Which edge costs your dispatch the most time today? The mail inbox, a customer portal, or the dispatch plan in Excel? Tell me which one. I will show you, on an anonymized example, what the process behind it looks like.
