How demurrage claims software works: from document collection to settlement

Why getting the process right pays

A demurrage claim is money already owed. The rate was agreed at fixture; the vessel really did wait. The only open question is whether the claim is collected in full, and in time.

The arithmetic is rarely the hard part. A capesize sits three days beyond its laytime at a congested discharge berth. At a demurrage rate of, say, $22,000 a day, that is $66,000 owed on a single port call. Multiply that across a fleet and a year, and demurrage becomes one of the largest recoverable lines in voyage operations.

How a claim moves from port call to settlement

Every demurrage claim, run by hand or by software, follows the same path. The steps do not change; only the amount of manual effort at each one does.

1. Collect the documents: The statement of facts, notice of readiness, pumping logs, letters of protest and bill of lading come in from the agent, master, terminal and surveyor.

2. Digitise the statement of facts: The SOF is turned from a scanned document into a structured, machine-readable timeline of the port call.

3. Calculate laytime against the contract: Each event is measured against the charterparty terms to work out how much laytime was used and demurrage is owed.

4. Review and approve: The calculation is checked against the contract clauses and signed off before it leaves.

5. Share, dispute and settle: The claim goes to the counterparty with its evidence attached; they accept, query or settle.

Step 1: Collecting the documents

Document collection is the first stage of the demurrage claims process, and a claim is only as good as the evidence behind it. Collection begins when the vessel leaves the berth — the point at which the port call is complete and the documents exist.

The bundle is specific. For a discharge call it typically includes:

• Notice of readiness (NOR) — the master’s declaration that the vessel has arrived and is ready to work, which is what starts laytime.

• Statement of facts (SOF) — the chronological record of the port call, often in several versions from the agent, vessel, terminal and surveyor.

• Pumping logs — on discharge calls, and the bill of lading on loading calls.

• Letters of protest — issued and received, recording anything either side disputed.

• Ullage or on-board-quantity reports and tank certificates — where the cargo requires.

Getting them is the slow part. Agents are busy, and a document that is not chased does not arrive. So this stage is mostly follow-up — daily emails, the occasional phone call — until the bundle is complete. Before anything is calculated, the key timestamps are cross-checked for consistency: arrival, commencement of sea passage (COSP), and the notice of readiness against the statements of fact.

This is the stage Marcura Claims automates through PDMS, its port-document collection service. Collection is triggered by AIS the moment the vessel sails; daily auto-follow-up emails and periodic calls chase the agent until the bundle is complete; and every document is validated before any laytime calculation begins. Run this way, it removes up to 34% of the operator time otherwise spent chasing and verifying port documents.

Step 2: Digitising the statement of facts

The statement of facts arrives as a scan or a PDF — a photograph of a document, not data. Before laytime can be counted, it has to become a structured timeline: each event, its date and time, in a form a calculation can read.

This is where accuracy is won or lost. A good SOF digitisation does three things:

• Reconciles the multiple versions. The agent’s SOF, the vessel’s and the terminal’s rarely match to the minute; the differences have to be resolved, not averaged away.

• Preserves the original text of every row, so a figure can always be traced back to the words it came from.

• Captures every event, not only the ones that affect the calculation, so nothing is quietly dropped.

Done by hand, this is transcription — someone retyping times from a scanned page into a calculator at the end of a long day. It is exactly the kind of work that is both dull and unforgiving: a single mistyped time changes the answer, and no one notices until the counterparty does.

In Marcura Claims this is the drag-and-drop step: you drop in the statement of facts and the claim populates in seconds. OCR reads the document, a model trained on statements of fact interprets the event sequence, and a maritime QA team corrects the output before it enters the calculation — reconciling the multi-source versions, flagging the events to disregard, and preserving the original text on every row.

Step 3: Calculating laytime against the contract

With a structured SOF, the calculation applies the charterparty terms to the timeline. This is the part people picture when they think of demurrage — and the part that is genuinely mechanical, once the inputs are right.

The contract decides how each hour is counted. Laytime — the time the charterparty allows for cargo operations — runs down against terms such as:

• SHINC or SHEX — whether Sundays and holidays are included in laytime or excepted from it.

• Weather working days, where the clock stops when the weather stops the work.

• Notice time and turn time before laytime begins, and shifting time between berths.

• Parcels, pro-rates and reverses, where a cargo is split or the calculation runs backwards.

Every decision is tied back to a clause, and the remarks on the SOF are read against that clause rather than ignored. The output is a laytime statement: how much laytime was allowed, how much was used, and — once it runs out — how much demurrage is owed. The standard charterparty forms each carry their own rules, whether that is Gencon in dry bulk or Asbatankvoy, BPVOY4 and SHELLVOY6 in tankers, which is why a claim built against the wrong form is worse than no claim at all.

Marcura Claims auto-calculates against the specific charterparty terms — BPVOY4, SHELLVOY6 and the rest — and covers the full range of claim types: owners, contract, EU barge, expense and deviation. As the calculation is built, AI flags inaccurate data, time-bar issues and calculation errors, and the in-house Claims team reviews it against the contract clauses before it reaches you for approval.

Step 4: Review, sharing and settlement

A calculation is not a claim until someone stands behind it. Before it goes out, it is checked against the contract clauses — the judgement step that catches an unusual exception or a disputed reading the maths cannot.

From there the workflow is about evidence and version control:

• The claim is approved or returned with remarks, and every revision is kept, so it can be compared across versions and against the counterparty’s counter-claim.

• It is shared as a PDF or a link, with each figure still tied to the document that proves it.

• The counterparty’s acceptance — or dispute — is captured back against the claim, not lost in an email thread.

Run through Marcura Claims, this comes back as an audit-ready laytime statement within 2–5 days, backed by AI-assisted accuracy and full version control. Where both sides sit on the platform, the inter-company Claims Hub Exchange passes a claim straight from owner to charterer without it ever leaving the system.

Then the clock matters. The whole package has to reach the counterparty within the charterparty’s time bar — often around 90 days in the tanker trade, with many forms requiring all supporting documents, not just the calculation. Miss it and a correct claim is barred in full. That deadline is worth understanding on its own terms, which we do in demurrage time bars.

Where the manual version breaks down

Nothing in the process is optional. What varies is how much of it is done by hand — and by hand, it leaks at every stage.

Documents are chased by email until someone gives up. Statements of fact are retyped into a calculator, errors and all. Deadlines live in a spreadsheet no one owns. And the one step that genuinely needs an expert — reading an awkward clause, judging a contested exception — arrives last, if there is time left for it at all.

The costs are real; the visibility is not. A claim that is never raised leaves no trace. Neither does one under-calculated by a missed exception. The portfolio looks fine right up until someone adds up what was never collected.

What the software changes

Software does not change the process. It removes the manual work inside it — which is most of it.

That is the whole case for Marcura Claims. Each step above — the AIS-triggered collection, the drag-and-drop SOF, the contract-aligned calculation, the tracked deadline — takes a piece of manual work off the desk without changing what the claim is. Put together, they mean the claim is largely built, evidenced and checked before an analyst opens it, and every figure still links back to the document that proves it.

It is deliberately not just a faster calculator. The maths was never the bottleneck; the collecting, transcribing and chasing were. Run it as a fully managed service worked by specialists, keep it in-house with that manual work lifted off your team, or blend the two — the same capability, offered three ways. Across the network it handles more than 20,000 claims a year, with each statement of facts read against a corpus of over 600,000 the model has learned from.

The result is the same claim you would build by hand, minus the parts that quietly go wrong: the document that never came, the time typed in wrong, the deadline no one was watching.

A laytime calculator vs demurrage claims software

A laytime calculator and demurrage claims software are not the same tool. A calculator does the laytime maths once you hand it a structured timeline and the contract terms. Demurrage claims software does the whole process around that number — collecting the documents, digitising the statement of facts, checking the figures against the contract, and tracking the claim to settlement. Task by task:

Frequently Asked Questions