Voyage and Chartering Software: Why Demurrage Claims Die in the Statement of Facts

Why the money is lost after the fixture, not during it

A clean products tanker discharges at two ports. The statement of facts from the second port arrives from the agent as a scanned PDF with handwritten times in the margin. Notice of readiness was tendered at 04:10, but the berth was occupied until 19:30 and the charter party makes the notice valid whether in berth or not. Laytime ran during shifting at one port and not the other. There was a four hour stoppage the master recorded as awaiting shore tanks and the terminal recorded as vessel pumping issue, which is the difference between demurrage and an owner's cost. The operator who understood this voyage left the company in March. The claim is assembled in August by someone reading a PDF, and the charter party time bar has already passed.

This is where voyage results actually diverge from the estimate. The fixture is negotiated by capable people who know the market. The estimate was reasonable. What erodes the result is the accumulation of post fixture detail: laytime computed loosely, demurrage claimed late or not at all, bunker consumption never reconciled against the warranty, port disbursements accepted without challenge, and a profit and loss that gets actualised so long after completion that nobody can act on what it says.

Veson Nautical IMOS is the market standard and it is genuinely deep, Dataloy and Q88 both serve real segments well. The honest criticism is not that they lack capability. It is that they encode an opinionated model of how a voyage works, priced for scale, and operators with unusual trades find themselves working around the model. Parcel tankers with many grades and complex freight allocation, contracts of affreightment with liftings split across vessels and periods, pool arrangements with their own distribution rules, and in house trading desks that need the estimate to reflect a cargo position rather than a freight rate all end up with a critical spreadsheet alongside the system. That spreadsheet is where the commercial thinking lives.

Problem 1: the estimate encodes your assumptions or somebody else's

A voyage estimate is a model: distance and routing, speed and consumption by condition, bunker prices at intended stem ports, port costs, canal transit, cargo quantity with any deadfreight risk, freight or a Worldscale derived figure for tankers, and the resulting time charter equivalent. Every element carries an assumption, and the assumptions are where a commercial team's judgement lives.

What a custom build does: make the estimate model explicit and yours, with performance curves derived from your own noon reports and voyage history rather than typed in, and port costs seeded from your own disbursement history rather than a generic table. The estimate then improves as the fleet trades, and the comparison that matters becomes possible: for each completed voyage, the estimate against the actual, decomposed into which assumption was wrong. Operators who run that comparison monthly discover their systematic biases within two quarters, and correcting a systematic bias in speed or port time assumptions is worth more than any single negotiation.

Problem 2: the charter party is a legal document and the system holds a summary

Laytime depends on clauses: how notice of readiness may be tendered and when it becomes valid, turn time, whether time counts in berth or not, weather working days, exclusions for holidays and Sundays depending on the term used, whether laytime is reversible across ports, shifting, and any pumping warranty that shifts responsibility for slow discharge. These terms come from a negotiated recap that amends a standard form, and the amendments are where the disputes live.

What a custom build does: capture the clause set as structured terms linked to the recap text, so the laytime calculation states which term produced each decision and the operator can show the counterparty the clause alongside the arithmetic. Where a term cannot be modelled, the system asks for a human decision and records who made it and why, rather than quietly applying a default. Claims defended with a calculation that cites the clause settle faster and lower, and internally it means a new operator can work a voyage without having been in the negotiation.

Problem 3: the statement of facts is a PDF and the clock is running

Laytime calculation cannot begin until the events are in structured form, and the events arrive as agent documents in inconsistent formats, sometimes handwritten, often disagreeing with the master's own record. Somebody transcribes them. The transcription is the slowest step in the claim process and it is the step that pushes claims past the time bar written into the charter party, after which the merits of the claim no longer matter.

What a custom build does: this is where document extraction genuinely earns its place, and it is one of the few AI applications in this domain we recommend without hesitation. An inbound statement of facts becomes a draft event sequence with times, ports and remarks parsed and mapped to your event taxonomy, presented for an operator to confirm rather than type. Discrepancies against the master's report are surfaced side by side rather than discovered later. In our builds this collapses the transcription step from hours to minutes, which matters less for the time saved than for the fact that claims now get assembled while the facts are fresh and the agent still answers emails.

The second half of this is a claim clock. Every voyage carries its time bar computed from the charter party terms, and the system escalates as it approaches. A claim lost to a time bar is a pure, avoidable loss, and it is the most infuriating line in any post voyage review.

Problem 4: bunkers are the largest cost and the loosest data

Bunker stems, prices, quantities delivered against the note, quality disputes, remaining on board at delivery and redelivery, consumption against the charter party warranty, and hedged positions against physical purchases. Each of these is tracked somewhere and they rarely reconcile. Under performance and over consumption claims depend on weather routing evidence and good noon data, and most operators do not pursue them systematically because assembling the evidence costs more than the average claim.

What a custom build does: hold bunkers as an inventory per vessel per grade with movements, so remaining on board is derived rather than reported, and reconcile consumption against the warranty using the same noon and weather data automatically. Claims become a by product of the record rather than a project. Emissions cost is now part of the same picture: the extension of the European emissions trading system to maritime transport and the fuel intensity requirements introduced under the European fuel regulation mean the carbon cost of a voyage belongs inside the estimate, not in a separate compliance spreadsheet. Operators still estimating without a carbon line are quoting the wrong number on European trades.

Problem 5: the profit and loss actualises too late to be useful

A voyage result that appears four months after completion is history rather than management information. It appears late because it waits for final port disbursements and the demurrage settlement, so the accounting close and the commercial feedback loop become the same slow process.

What a custom build does: separate them. Maintain a live voyage result that updates as facts arrive, with each line marked as estimated, accrued or final, so a commercial team sees a converging number throughout the voyage rather than a surprise later. The accounting close still needs finals, but the trading decision does not. Being able to see, mid voyage, that the result is drifting from the estimate because port time at the load port ran long changes what you do about the next fixture, which is the entire point.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape for voyage and chartering platforms. A first release covering the estimator with your own performance and cost model, structured fixture capture, and laytime calculation with statement of facts extraction runs $120,000 to $280,000 and ships in 16 to 24 weeks. Adding post fixture operations, bunker inventory and claims, disbursement control, live voyage profit and loss and emissions cost modelling takes the total to $350,000 to $800,000 across 9 to 18 months.

What drives the number up in shipping specifically: the number of trades, because tanker, dry bulk and gas each carry different freight conventions and a parcel trade is harder than all of them. Contracts of affreightment and pool arrangements, since allocation and distribution rules are bespoke commercial agreements rather than features. Accounting integration, because voyage accounting has to reconcile to a general ledger that was not designed for it. Market data, if you need rate feeds or distance and weather routing services. And any requirement to migrate historical voyages, which is worth doing only for the estimate calibration data and rarely for anything else.

Build versus buy, and where Veson genuinely wins

Buy if you run a conventional trade at moderate scale. For a dry bulk operator with under about six vessels on standard voyage charters, IMOS or Dataloy will fit your business closely, the vendor's model matches how you actually work, and a build would recreate their functionality less well. We say this plainly because the market standard is the market standard for good reasons.

Buy the platform, build the edge, applies to operators who are happy with the core but have one commercially critical thing the platform will not do, such as a bespoke pool distribution or an in house cargo position view. Building that alongside a licensed system, reading its data, is usually the right economics.

Build when the model is the mismatch. Parcel tanker operators, contract of affreightment heavy businesses, pool managers, and commercial operators whose estimate must reflect a trading position rather than a freight rate all describe businesses where the vendor structure is a tax. Also build when the licence and services cost has grown to a level where owning the system outright pays back inside three years, which happens sooner than most operators expect once fleet count rises. The test we suggest is simple: identify the spreadsheet your commercial team would refuse to give up. If it holds the estimate model or the allocation logic, that spreadsheet is your requirement document and it is describing a build.

How to choose a developer for voyage management software

Ask them to model a voyage on a whiteboard. A team that has done this separates estimate, fixture with its clause set, voyage with itinerary and port calls, cargo, bunker inventory, and the result with estimated, accrued and final lines. They will ask early how a contract of affreightment lifting relates to a voyage. A team that draws shipments and invoices has built a freight forwarding tool and will not survive a laytime dispute.

Ask how the laytime engine explains itself. The correct answer is that every decision cites the term that produced it and every unmodellable term forces a recorded human decision. An engine that produces a number without a trail is worse than a spreadsheet, because at least the spreadsheet's author remembers what they did.

Ask what they would do with a handwritten statement of facts. Document extraction into a draft event sequence with human confirmation is the right answer. Anything promising fully automated interpretation without review has not seen the documents that actually arrive from agents.

Ask who owns the code and the voyage data, and settle it in writing before kickoff. You should own the repository, the cloud accounts and the right to move firms. Your estimate model and your historical voyage performance are genuine competitive assets, and they should not sit in a supplier environment. At Digital Heroes the client owns the code and the data from the first commit, and a developer who hedges is treating your commercial edge as a bargaining chip.