Demurrage and Detention Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the "build our own container tracking" scope failure happen so often?

Because tracking is the visible half of the problem. Your team refreshes eleven terminal websites, so a project that consolidates those into one screen feels like the answer, and scraping a terminal is genuinely easy for about a fortnight.

Then a terminal changes its page structure, a carrier rate limits you, and the feed that your last free day alerts depend on is now silently wrong. You have taken on permanent maintenance across dozens of sources with no competitive value in any of it, and the money you were trying to recover is still sitting in the part you never built.

The division that works is consistent across this domain. Buy the container event data from a visibility provider, because Terminal49, Vizion and Container xChange do that job well and cheaper than the engineers it takes to keep scrapers alive. Build the obligation model on top: what your contract entitles you to, what the clock actually says, what you owe right now, and what you can prove. Visibility tells you the state of the box. Only your own system can tell you the state of your obligation, because that lives in contracts you signed, not in terminal data.

What goes wrong with contract and tariff data?

Free time is not a fact about the port. It is a term of your service contract, varying by carrier, by trade, sometimes by commodity, and amended more often than anyone tracks. Whether weekends and holidays count varies. Whether demurrage and detention run concurrently or sequentially depends on the arrangement, and merged charges behave differently again.

The failure is that none of this is written down in one place. It sits in PDFs across procurement, logistics and legal, so the operations team works from a rule of thumb, usually the most common carrier's terms applied to everyone, and is wrong precisely at the edges where the money is.

Two fixes, and the first one is not software. Assemble the current set of service contracts with their amendments before the project starts, because you cannot model terms nobody has gathered and this is the most common schedule risk in the category. Then model free time as a versioned rule per carrier, per contract, per lane, with effective dates, so a historic charge is evaluated against the terms that applied at the time rather than today's. Document extraction earns its place here: contract amendments and tariff notices arrive as PDFs, and an extraction pass that proposes the changed terms for a human to confirm beats requiring someone to read every notice.

Why do the terminal, carrier and drayage integrations break after launch?

Even with purchased visibility, the connections that matter degrade quietly. A terminal starts publishing availability under a slightly different status code and your clock keeps counting from discharge when it should be counting from availability. A carrier's event feed goes quiet for one service and nobody notices, because containers arriving late look the same as containers not arriving.

Drayage is its own integration per partner, and it is the one most often descoped. When your drayage carrier works in their own system, the record of what happened arrives as a narrative email written under time pressure, which is not evidence and cannot be queried.

Three design answers. Store every inbound event with the timestamp you received it and the raw payload, so a disputed timeline can be reconstructed rather than argued. Alert on the absence of expected events per terminal and carrier, since a stopped feed is the failure that actually costs you. And take a structured feed from your drayage partner rather than an inbox, treating each partner as its own small project with its own timeline. When integration budget is tight, cut a terminal before you cut the drayage feed, because the drayage record is where your defence comes from.

What happens when evidence capture is not covered?

This is the gap that turns a system into a reporting tool. It will tell you accurately that you were charged, and it will not help you get the money back.

The strongest dispute is not a legal argument, it is a record. You tried to book an appointment at six in the morning, at eleven and at four, on three consecutive days, and none was offered. The terminal had no slots for that container's line. The empty return was restricted, so your driver could not turn the box in. Each is a complete defence and each is currently a memory, because terminal appointment systems exist to allocate slots rather than to build your case, and a screenshot taken today proves nothing about a page as it was last month.

Capture the attempt, not just the outcome. Every appointment search, every failed booking, every restriction notice, timestamped and attached to the container as it happens. Where terminals expose data, poll it and store what you saw at the time you saw it. Then the dispute generates as a packet: container, tariff applied, contract terms, event timeline, attempt log, and the specific days contested with a reason for each. Under the Federal Maritime Commission billing rule following the Ocean Shipping Reform Act there are defined invoice contents and windows for raising disputes, and you should confirm current detail with counsel. The practical effect is that a hard window protects everyone except the party whose evidence takes three weeks to assemble.

Should you build custom or configure what you already own?

Buy and stop here if you move under roughly 1,500 containers a year. A visibility subscription with last free day alerts plus one organised person captures most of the available value, and your annual exposure probably does not justify an engineering project. Terminal49 and Vizion are the right purchase at that scale and the spreadsheet around them is not shameful, it is proportionate.

Before building, get more from what you already pay for. Most importers running a visibility tool have never configured alerting thresholds properly, never mapped their carriers' free time into the alert lead time, and never assigned an owner to the alerts. That configuration work is a week and it tells you how much of the remaining gap is genuinely structural.

Build when two or more of these are true. You move over roughly 5,000 containers a year across multiple ports. Your finance team can quote the demurrage number and dislikes it. You dispute less than half of what you are billed because assembling evidence takes too long. Your free time terms differ meaningfully across carriers and nobody can state them from memory. Or you are a forwarder wanting to sell prevention as a service, which is a product decision rather than an internal tooling one.

How do hidden costs get into the quote?

Contract gathering is the first and it lands on you rather than the vendor. If service contracts are scattered across three teams' inboxes, assembling the current set with amendments is discovery work that has to finish before modelling starts, and it is the single most common reason these projects start late.

Port and terminal count is the next, because every terminal exposes data differently and some expose almost nothing, so coverage is not uniform and the gaps need manual handling designed for them.

Then carrier count, since each contract structure is its own rule set rather than a row in a table. Then drayage partner integration, priced per partner. Then the accrual posting into finance, which sounds like a report and is a ledger integration with dimensions for site, supplier, carrier and cause. And the visibility subscription itself, which is an ongoing operating cost that belongs in the business case rather than surfacing after go live as a surprise line.

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

The builds that work make the number visible daily to the person who can act on it. When a warehouse manager sees that today's inability to unload is generating a specific figure across nine containers, prioritisation changes without a policy meeting, and the first measurable reduction usually comes from nothing more sophisticated than that. Prevention is the larger half of the return, and it needs no clever technology, only a number in front of the right person in time to matter.

The builds that fail deliver an accurate monthly report of money already lost.

Ask a developer where the clock starts. If they cannot immediately discuss discharge versus availability and why the distinction matters per tariff, they will count from the wrong event and every number the system produces will be right only by accident. Ask how free time is modelled, where the only acceptable answer is a versioned rule per carrier and contract with effective dates rather than a number in a settings page. Ask how evidence is captured, where storing a screenshot on request is not an answer. Then settle ownership before kickoff, including the evidence archive, since that archive is the asset that wins disputes and you may need to rely on records from two years ago.