Why standard TMS software does not fit inland waterway transport
A standard TMS or ERP thinks in trips: fixed departure and arrival points, fixed time windows, fixed vehicles. Inland shipping works differently. A vessel sails from Rotterdam to Duisburg today, but the order of loading and unloading ports shifts based on cargo availability, water levels, and lock availability. That is not the exception — it is the daily reality. Packages that cannot handle that variability force planners to rework everything manually. The system becomes an after-the-fact registration tool rather than a planning tool that actually helps.
Bottleneck 1: variable sailing routes and lock schedules do not fit fixed trip structures
Locks on the Rhine, Meuse, or Waal operate with time windows that depend on lock frequency, water levels, and priority rules. A generic TMS has no concept of a lock passage. It has no field for lock waiting time, no logic to combine two vessels on the same route when capacity allows, and no connection to water level or lock data. Planners work around this with a spreadsheet on the side, a whiteboard, or simply from memory. Once more vessels or more routes are added, that approach no longer holds. The risk: a vessel sits waiting while a profitable cargo is available on the quay that could have been loaded just in time.
Bottleneck 2: cargo, sailing, and port planning in one real-time overview
Inland shipping involves three planning layers running simultaneously. Cargo planning determines which bulk goods, containers, or general cargo are included and the sequence in which they are loaded and unloaded. Sailing planning determines the route, speed, and fuel consumption. Port planning arranges the berth, crane time, and mandatory notification to the terminal. Generic packages treat these as separate modules that do not communicate with each other. The result: the planner sees in the TMS that a voyage is scheduled, but does not know whether the terminal has confirmed a time slot, whether the cargo is already on board, or whether there is room for additional freight. That information lives in three systems, three browser tabs, or three separate chat conversations. A real-time overview that combines cargo, sailing, and port planning is exactly what inland shipping needs — and what most standard packages do not provide.
Bottleneck 3: document flows that differ by waterway and border
An inland vessel sailing from Rotterdam to Basel passes through Dutch, German, and Swiss regulations. Each country has its own requirements for waybills, manifests, and dangerous goods. On the Rhine route, ADN regulations apply for dangerous goods, with corresponding checklists and notifications to the competent authority. When crossing into Germany or beyond, German-language manifests and customs documents are required. A standard TMS generates a CMR or a generic waybill. For a road carrier that is sufficient, but for inland shipping it falls short. The result is that staff manually adjust, translate, or reformat documents. This costs time, increases the likelihood of errors, and delays departure.
When do you choose custom inland waterway software, and when do you choose an AI layer?
The choice depends on the state of your current systems. If you are running a package that still functions reasonably well but runs into problems with documents and route variability, an AI layer around it is often the fastest path forward. Think of an AI Worker that processes incoming load orders, reads and completes documents, and presents the planner with a proposal for the most efficient sequence. The planner reviews and approves that proposal. This keeps humans in control while reducing the administrative burden. If your current system is fundamentally unsuitable for inland shipping because it cannot handle route logic, lock data, or port notifications, then rebuilding is the more honest choice. A domain-specific system built from the ground up for inland shipping works better than a generic package with ten custom workarounds bolted on. The upfront cost of rebuilding is higher, but the operational friction you eliminate often pays that back within the first year. It is not a decision to take lightly, but it is a decision that deserves to be asked honestly.