Voyage and Chartering Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the laytime scope get underestimated so often?

Because laytime looks like arithmetic and is actually contract interpretation. A specification that says calculate laytime and demurrage is usually paired with a data model holding a laytime allowance, a demurrage rate and a few flags, and that model cannot express the terms that decide real cases.

Consider what actually governs a calculation. How notice of readiness may be tendered and when it becomes valid. Turn time. Whether time counts whether in berth or not. Weather working days and how the specific term used treats holidays and Sundays. Whether laytime is reversible across ports. Whether shifting counts. Any pumping warranty that shifts responsibility for slow discharge from charterer to owner. These come from a negotiated recap amending a standard form, and the amendments are exactly where the disputes live.

This is specific to chartering because the counterparty is reading the same clause and reaching a different conclusion, then paying or not paying accordingly. Most business software calculates against rules only one party holds. Here every number you produce is an opening position in a negotiation.

The fix is to capture the clause set as structured terms linked back to the recap text, so the calculation states which term produced each decision and an operator can put the clause next to the arithmetic in front of a counterparty. Where a term cannot be modelled, the system must stop and ask for a human decision, recording who made it and why, rather than quietly applying a default. Claims defended with a calculation that cites its own clauses settle faster and lower, and internally it means a new operator can work a voyage they did not negotiate.

What goes wrong with the statement of facts and historical voyage data?

Two data problems, and they are different in character.

The live one is the statement of facts. Events arrive as agent documents in inconsistent formats, sometimes handwritten, frequently disagreeing with the master's own record. Somebody transcribes them into a spreadsheet. That transcription is the slowest step in the whole claim process and it is the step that pushes claims past the bar. It is also where errors enter, because a stoppage the master recorded as awaiting shore tanks and the terminal recorded as vessel pumping issue is the difference between demurrage and an owner's cost, and a transcriber flattening both into one line has destroyed the argument before it started.

The historical one is migration. Operators want to bring in years of completed voyages, and most of that data is worth less than it looks. Freight and result figures were adjusted outside the system. Port costs sit in disbursement accounts that were never coded consistently. The genuinely valuable material is narrow: noon reports and voyage outcomes that let you calibrate speed and consumption curves, and disbursement history that seeds real port cost estimates rather than a generic table.

The fix on the live side is document extraction into a draft event sequence with times, ports and remarks mapped to your event taxonomy, presented for an operator to confirm rather than retype, with discrepancies against the master's report shown side by side. This is one of the few places we recommend document extraction without hesitation. The fix on the historical side is to migrate deliberately for calibration rather than completeness, and to resist importing results nobody can reconstruct.

Why do the integrations that matter here break after launch?

Because the inputs arrive from parties with no obligation to you and no release notes.

Agent documents come by email in whatever format the agent used last time, and a new agent at a new port breaks whatever pattern your extraction learned. Noon reports come from vessels via a reporting tool or, on some fleets, as an email template a master edits, and a master who adds a line changes your parser. Distance and weather routing services change payloads and pricing. Bunker delivery notes arrive as scans.

The accounting integration breaks for a different reason: voyage accounting has to reconcile to a general ledger that was not designed for it. A voyage crosses periods, accrues costs against a result that keeps moving, and settles months after completion. If the interface posts finals only, finance sees nothing until late. If it posts accruals without a reversal discipline, the ledger fills with duplicates. That is a design conversation with your financial controller, not a mapping exercise, and skipping it is why so many voyage systems end up feeding a spreadsheet that feeds the ledger.

The fix is to treat every external input as untrusted and build an exception queue rather than a silent parser. A document that does not map cleanly goes to a human within minutes, not to a log file. And agree the accounting posting model with finance before the first line of interface code.

What happens when the time bar and carbon cost are not covered?

The time bar is the omission that costs the most and appears in the fewest specifications. Every charter party carries a period within which a claim must be presented, often with documentary requirements attached, and it is computed from terms that vary per fixture. If that date is not held per voyage and escalated as it approaches, the system is a very accurate way of losing money slowly.

Build it as a visible clock: the bar date derived from the fixture terms, the documents required to present a valid claim listed against it, and escalation that reaches a named person rather than a shared inbox. The other half is completeness, since a claim presented without the supporting documents the clause requires can be rejected on that basis alone.

Carbon cost is the newer gap and it belongs in the estimate rather than in a separate compliance spreadsheet. The extension of the European emissions trading system to maritime transport and the fuel intensity requirements introduced under the European fuel regulation both attach a real cost to a specific voyage. An estimate without that line is quoting the wrong number on European trades, and the error is systematic rather than random, so it favours the counterparty every time.

Treat carbon as a cost element with its own assumptions and its own update path, sitting alongside bunkers in the estimate and reconciled after the voyage like any other cost. Operators who keep it in a compliance workbook find the commercial team never sees it at the moment it would change a decision.

Should you build custom or configure what you already own?

If you run a conventional trade at moderate scale, license rather than build. For a dry bulk operator with under about six vessels on standard voyage charters, Veson Nautical IMOS or Dataloy will fit closely, the vendor's model matches how you actually work, and a build would recreate their functionality less well. We say that plainly because the market standard is the market standard for good reasons, and Q88 serves real segments well too.

There is a genuine middle path. Buy the platform and build only the edge if you are content with the core but have one commercially critical thing it will not do, such as a bespoke pool distribution rule or an in house cargo position view. Building that alongside a licensed system is usually the right economics.

Build when the model itself is the mismatch. Parcel tanker operators with many grades and complex freight allocation, contract of affreightment heavy businesses with liftings split across vessels and periods, pool managers with their own distribution rules, and commercial desks whose estimate must reflect a cargo position rather than a freight rate all describe businesses where the vendor structure is a tax. The test is simple: find 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.

How do hidden costs get into the quote?

Trade count is the first driver and it beats fleet size. Tanker, dry bulk and gas carry different freight conventions, and a parcel trade with multiple grades and allocated freight is harder than all of them. A proposal priced for one trade will not stretch to three.

Contracts of affreightment and pool arrangements are the second, because allocation and distribution are bespoke commercial agreements rather than features, and each one has to be read and modelled. Accounting integration is the third for the reasons above. Market data is the fourth: rate feeds, distance tables and weather routing services carry licence costs and integration work that often sit outside the software quote entirely.

The fifth is the one operators consistently underestimate, which is their own time. Capturing estimate assumptions, allocation rules and clause handling needs sustained attention from the people who are also doing the fixing, and that is the real constraint on the schedule.

What separates a build that works from one that fails here?

Ask the developer 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, because that relationship shapes everything. 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. Every decision should cite the term that produced it, and every term that cannot be modelled should force a recorded human decision. An engine that produces a number with no 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. 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 agents actually send.

Ask how bunkers are held. Remaining on board should be derived from an inventory of movements per vessel per grade, not reported as a number, otherwise consumption against warranty can never be reconciled. Then settle ownership before kickoff: the repository, the cloud accounts, the estimate model and all voyage data. Your performance curves and historical results are competitive assets built from your own fleet's behaviour, and they should not sit in a supplier environment. At Digital Heroes the client owns the code and the data from the first commit.