Demurrage and Detention Software: How to Stop Paying for Days You Could Not Move

Why demurrage is a data problem wearing a finance costume

An invoice lands on the first Tuesday of the month. It covers 41 containers, most cleared weeks ago, with charges from $150 to $400 per container per day and one line at $6,800 because a box sat over a holiday weekend. The import manager pulls the container numbers. For 12 she roughly remembers what happened. For the rest there is a chain of emails with the drayage carrier, a screenshot of an appointment page that no longer exists, and a message from a driver saying the gate was closed. She has days to dispute and no evidence, so she codes most of it to freight expense and moves on.

That is the mechanism. Demurrage and detention are not really billing errors, they are the price of an information gap. The clock starts on the terminal's data and stops on the terminal's data, both of which you receive late and neither of which you control. Meanwhile the actual determinants of whether you could have moved the box are things nobody records: whether the container was actually available on the stack, whether an appointment existed to be booked, whether the chassis pool was empty, whether the empty return was restricted at every terminal that would take that carrier's equipment that week.

The stakes scale brutally, because the charges are per container per day, so one week of terminal congestion across a few hundred boxes is a number that gets a chief financial officer's attention. Under the Federal Maritime Commission billing rule that followed the Ocean Shipping Reform Act, invoices must carry defined information and there are windows for issuing charges and raising disputes. Confirm the detail with counsel. The practical effect is that you have a real basis to dispute and a hard clock in which to do it, and if your evidence takes three weeks to assemble, the rule protects everyone but you.

Problem 1: the clock is running before anyone knows the box exists

Free time is counted from discharge or from availability depending on the tariff, and the difference matters enormously. Your team usually learns about a container when the forwarder sends an arrival notice, often after discharge. By the time the box reaches your spreadsheet, a day or two of free time has gone, and nobody knows it because the start date is when someone typed it in.

Terminal49, Vizion and Container xChange solve a real part of this and solve it well, pulling terminal and carrier events into one place instead of a person refreshing eleven websites. The honest limit is that visibility data tells you the state of the box, not the state of your obligation. Knowing a container discharged on Tuesday does not tell you which tariff applies, how many free days that carrier gives you under that service contract, whether weekends count, or what the accrued liability is right now. That calculation depends on your contracts, so it is yours to hold.

What a custom build does: create the container record at booking or at bill of lading issue, not at arrival notice, then attach event data to it as it arrives. The clock is computed rather than typed, and the last free day is a derived field that updates when events change. The dashboard everyone actually wants is one screen: every box you own right now, days remaining, and accrued exposure in dollars. Most importers have never seen that number in real time, and seeing it changes behaviour within a week.

Problem 2: free time rules are contractual and nobody has modelled them

How many free days you get is not a fact about the port. It is a term of your service contract, varying by carrier, by trade, sometimes by commodity, and frequently amended. Whether weekends and holidays count varies. Whether demurrage and detention run concurrently or sequentially depends on the arrangement, and merged charges behave differently again. Storage at the terminal and per diem on the equipment are separate meters people routinely confuse.

None of this exists in a visibility tool because none of it is in the terminal data. It sits in PDFs in a procurement folder. So the operational team works off a general rule of thumb, usually the most common carrier's terms applied to everybody, and is wrong on the edges where the money is.

What a custom build does: model free time as a rule per carrier, per contract, per trade lane, with effective dates, so the clock reflects your actual agreement instead of a memory of it. This is the second place where document extraction pays for itself: contract amendments and tariff notices arrive as PDFs and email attachments, and an extraction pass proposes the changed terms for a human to confirm rather than requiring someone to read every notice. Once the rules are modelled, the invoice check becomes automatic: this carrier billed six days, your contract gives five free and the box was available on the fourteenth, so two days of this invoice are wrong.

Problem 3: you cannot prove you tried

The strongest dispute is not a legal argument, it is a record. You tried to book an appointment at 6am, 11am and 4pm 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 of those is a complete defence, and each is currently a memory.

Drayage carriers often keep better records than their customers, but the record lives with them and arrives as a narrative email under time pressure. Terminal appointment systems do not give you a durable history of failed attempts, because their job is allocating slots, not building your case.

What a custom build does: capture the attempt, not just the outcome. Every appointment search, every failed booking, every restriction notice, timestamped and attached to the container. Where terminals expose data, poll it and store what you saw at the time, because a screenshot of a page taken today proves nothing about last month. Where your drayage partner works in their own system, take a structured feed from them instead of an email. Then a dispute is generated as a packet: container, tariff applied, contract terms, event timeline, attempt log, and the specific days you contest with the reason for each. In our experience the win rate on disputes roughly doubles when the packet is produced automatically in the first week rather than assembled manually in the fourth, and the biggest driver is simply that more disputes get filed at all.

Problem 4: nobody owns the number until it is too late

Demurrage sits in a gap between operations and finance. Operations does not see cost, they see boxes and appointments. Finance sees a cost line weeks later and has no ability to influence it. The result is an expense that everyone treats as weather.

The behavioural fix is boring and effective: make the accrual visible daily, attributed to whoever can act on it. When a warehouse manager sees that today's inability to unload is generating a specific dollar figure across nine containers, prioritisation changes without any policy meeting.

What a custom build does: post a daily accrual per container into the same ledger structure finance uses, with dimensions for site, supplier, carrier and cause. The monthly invoice becomes a reconciliation against a number you already knew rather than a surprise, and the first measurable reduction usually comes from nothing more sophisticated than visibility.

Problem 5: root cause is a category, not a story

Once you have a year of data with causes captured, the picture usually surprises people. It is rarely one big failure. It is a customs hold pattern on one commodity, a supplier whose documents arrive late, one terminal whose appointment scarcity is structural, and a warehouse that cannot take deliveries after 2pm. Each has a different owner and a different fix, and none is visible while the data is anecdotal.

What a custom build does: force a cause code at dispute or write-off, then report exposure by cause, lane, supplier and terminal. That report justifies the project internally in year two, because it turns a cost line into a list of actions with dollar values attached.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this category prices as follows. A focused first release, meaning container records created at booking, event ingestion from your visibility provider, computed free time clocks with last free day alerting, and an evidence log, runs $60,000 to $130,000 and ships in 10 to 14 weeks. A full platform adding contract and tariff modelling per carrier, appointment attempt capture, empty return restriction tracking, automated dispute packet generation, daily accrual posting and cause analytics runs $150,000 to $350,000 phased over 6 to 10 months.

What pushes the number up: the number of ports and terminals you touch, since every terminal exposes data differently and some expose almost nothing. The number of carriers, because every contract structure is its own rule set. Drayage partner integration, which is a project per partner. And your own document quality, because if service contracts are scattered across three teams' inboxes, gathering them is discovery work before modelling starts.

What holds it down: buy the container event data rather than building scrapers. Terminal49 and Vizion exist and are cheaper than maintaining your own terminal integrations, which break constantly. Build the obligation model, the evidence capture and the dispute engine on top of purchased visibility. That division is almost always the right one.

Build versus buy, and where the line sits

Buy if you move under roughly 1,500 containers a year. A visibility subscription with last free day alerts plus one organised person will capture most of the available value, and your annual demurrage exposure probably does not justify an engineering project.

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

Our position: this is one of the clearest positive return builds in logistics, because the saving is measured in the same units as the cost and shows up within one billing cycle. The failure mode is scope. Teams build container visibility, which is a solved and purchasable problem, then run out of budget before the obligation model, which is the part that recovers money.

How to choose a developer for demurrage work

Ask them where the clock starts. If they cannot immediately discuss discharge versus availability and why the distinction matters per tariff, they will build a counter from the wrong event and every number the system produces will be defensible only by accident.

Ask how they model free time. The answer must be a versioned rule per carrier and contract with effective dates, not a configuration number in a settings page. Contracts change mid-year and you need historic charges evaluated against the terms that applied then.

Ask how evidence is captured. Storing a screenshot on request is not evidence. The system must record what it saw at the time it saw it, automatically, so a dispute filed in March can rely on a terminal state observed in February.

Ask who owns the code and get it in the contract before kickoff. You should hold the repository, the cloud accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit, and in this domain you also want to own the evidence archive outright, since it is the asset that wins disputes.