5 charter party clauses every voyage optimisation platform should model

A voyage can look perfect on the screen and still end in a dispute. That is the blind spot in a lot of voyage optimisation software. The route avoids the worst weather. Fuel burn is down. ETA looks manageable. Then the commercial questions start. Was the vessel still within the speed and consumption warranties? Did the ETA drift out of the laycan into the cancellation window? Was the Notice of Readiness valid? Did the weather justify a deviation according to the liberty clause? That is the real test of a voyage optimisation platform.

In shipping, a charter party, sometimes written charterparty, is the written contract between the shipowner and the charterer that sets out the terms of the vessel’s employment, freight and ports involved. If a platform cannot turn that charter party agreement into live operating logic, it is not really optimising the voyage. It is simply plotting a more efficient route.

In practical terms, every credible voyage optimisation platform should model at least 5 clauses in these groups: speed and consumption, laycan and cancelling and weather working days, safe port and berth, liberty and deviation, bunker-related clauses, and modern carbon clauses such as slow steaming and CII. Those are the terms that decide whether a fuel-saving decision is commercially sound or simply moves the risk somewhere else.

1. Speed and consumption warranties

If there is one clause family that most clearly connects voyage planning with claims risk, it is speed and consumption. Performance clauses often hinge on guaranteed speed, fuel consumption and the definition of “good weather”. But what does “about 14 knots” mean and when is it “good weather”? This is why these disputes can become so technical so quickly. That matters because a platform cannot treat vessel performance as a rough average over a voyage. It has to compare actual daily performance against the contractual benchmark, on the same basis the clause uses precisely. That means weather filters, draft or displacement, fuel type, engine mode, route condition and timing all need to be part of the model.

For software, the implication is simple. A platform cannot rely on a generic vessel’s speed-consumption curve (also called SFOC) and call it done. It needs to model the contractual speed, the contracted consumption, ballast versus laden condition, relevant tolerances from the “abouts”, fuel type and the weather filters that determine whether actual performance should count against the warranties. An operator does not need another report explaining yesterday’s shortfall. They need a system that shows, before the order is sent, how far they can adjust speed without drifting into a performance dispute.

2. Weather working days and port-weather evidence

This is where a lot of performance disputes stop being theoretical and start costing money. A voyage optimisation platform should therefore model weather twice. First, it needs accurate weather for routing and compliance at sea. Second, it needs weather to support operational decisions in port. Those are related, but they are not the same task. The platform has to know not only what weather the vessel will meet, but also which conditions fall inside or outside the contractual definition, how those conditions affected speed and consumption over the relevant period and how those conditions affected speed and consumption over the relevant period.

In practice, this is also where a platform starts losing credibility and value to its users. If the system can model a North Atlantic route to the decimal but cannot help with rain, swell or wind interruption at load or discharge, it will be seen as incomplete.

3. Safe port, berth and deviation clauses

A shorter route is not always the better routeA cheaper bunker call is not always the better bunker call. A faster passage is not always the safer or easier-to-justify passage if it is later challenged. Safe port and safe berth obligations add another layer of risk allocation, and West P&I notes that where there is no safe port or berth warranty, owners may not have a safe port claim, while the scope of a safe berth warranty can be narrower than a full safe port obligation.

This is where optimisation software often becomes too abstract. It treats routing as a mathematical problem and forgets that a voyage is still being executed inside a contractual and safety framework. A route recommendation that ignores safe-port implications, liberty wording or navigational constraints is not “optimal” in any commercially useful sense. To help users optimise their cost, these clauses have to be included in the modeling. That does not mean software should replace judgement. It means the software should make the judgement easier, earlier and better documented.

4. Bunker, TCE and bonus-or-penalty clauses

Routing decisions and bunkering decisions belong in the same commercial conversation.

A bunker decision changes cost, but it can also change route, timing, deviation risk and ultimately TCE. The same goes for performance-linked financial clauses. What looks like a saving in one column can become a loss once the whole charter party agreement is taken into account. The question is whether the bunker stop is permitted, what it does to ETA, whether it changes laytime or demurrage exposure and whether the economic gain survives after the contractual knock-on effects are priced in.

This is one of the clearest commercial gaps between basic planning software and a complete voyage optimisation platform with all charter party integrations backed by T.VOS. Planning software may tell the desk where bunkers are cheaper. A clause-aware optimisation platform should tell the desk whether cheaper bunkers still produce the better voyage.

5. CII, slow steaming and other carbon clauses

Environmental performance is no longer something vessel operators report after the voyage. It is increasingly something operators chose to manage, during the voyage. EU-ETS and FuelEU simply can make sailing “in the blind” hoping for the best, very expensive. Carbon performance has already moved into the charter party itself. So any voyage optimisation platform that still treats emissions as a side module is behind the curve. The engine needs to weigh fuel use, ETA, commercial exposure including the costs of emissions and CII performance together, because that trade-off is happening in real time, not after arrival.

The real test is simple: can the platform turn contract wording into structured, live constraints?

At a minimum, it should be able to ingest charter party data as fields rather than store it as a static attachment, combine that with metocean data, ship performance, port conditions, CII position and bunkering inputs and then compare multiple voyage scenarios against commercial outcomes.

That matters because a voyage is not optimised when fuel cost is lowest. It is optimised when route, speed, ETA, TCE, emissions and charter party compliance still hold together when the ship is halfway across the ocean. T.VOS is a multi-objective voyage optimisation solution that can translate charter party terms into computational logic, assess hundreds of thousands of voyage possibilities, and keep updating the commercial picture during transit. That is not just better voyage planning. It is contract-aware voyage optimisation.