US Demurrage & Detention in 2026: What Changed After the Court Decision—and What Still Applies

Most demurrage and detention (D&D) losses don’t come from a single dramatic failure. They come from routine friction: invoices that don’t include enough detail, timelines that are missed, and disputes that start too late because the proof is scattered across emails, portals, and spreadsheets.

For US importers, exporters, forwarders, and NVOCCs, 2026 brings an important clarification: a federal court set aside one specific part of the Federal Maritime Commission’s (FMC) D&D billing rule, and the FMC removed that section from the CFR—while the rest of the rule remains in effect.

That distinction matters. It changes how teams should think about “who gets billed,” but it does not remove the operational discipline required to validate invoices, track timing, and run a repeatable dispute workflow.

This post lays out what changed, what didn’t, and the practical steps logistics and finance teams can standardize now to reduce paid-but-disputable charges.

The 60-second timeline (why this is a 2026 topic)

If you only remember one thing, remember this: one provision was set aside; most requirements still apply.

Key milestones

May 28, 2024: FMC’s D&D Billing Requirements rule took effect.
September 23, 2025: A US appellate court set aside only the “properly issued invoice” provision that specified who an invoice may be sent to (46 CFR § 541.4).
December 29, 2025: FMC removed § 541.4 from the Code of Federal Regulations (CFR). The rest of Part 541 remains in effect.

For 2026 operations, that means D&D management is still about execution:

invoice completeness
invoice timing
dispute timing
evidence readiness
internal handoffs

What still applies in 2026 (the requirements teams can operationalize)

Even after § 541.4 was removed, the remaining rules still define a practical baseline for how D&D invoices should be issued, what they should contain, and how disputes are handled.

1) Minimum invoice contents still matter

The rule specifies minimum information an invoice must include so the billed party can identify:

which container(s) the charges apply to
what time period is being billed
how the amount was calculated
who to contact and how to request mitigation/refund/waiver

The practical implication: invoice validation is no longer “nice to have.” Teams should be able to quickly answer:

Do we have the identifiers to match this invoice to our shipment record?
Do the dates and “free time” fields match what actually happened?
Is the charge period clearly and explicitly listed?

2) Invoice issuance timing still matters

Part 541 also sets timeframes for issuing invoices. Operationally, this is where teams tend to lose leverage: if invoices arrive late or get reissued, the clock and process can become muddled unless you have a clear intake workflow.

A strong 2026 practice is to capture three dates the moment an invoice hits your inbox or portal:

date received
invoice date
“charges last incurred” date (as described or inferable from the billed dates)

3) Dispute and resolution timeframes still matter

The rule also provides a standardized dispute window (mitigation/refund/waiver requests) and a standardized “attempted resolution” timeline.

In practice, this means two things:

Disputes need to be filed quickly and consistently.
Billing parties must have a defined point of contact and process, and you should use it—rather than defaulting to informal email escalation.

What changed in 2026 (and what it means operationally)

The change: the “who may be invoiced” limitation was removed

The section set aside by the court (and later removed from the CFR) was the rule’s “properly issued invoice” provision that specified who an invoice may be sent to.

What to do with that in 2026: avoid simplistic assumptions.

Don’t assume “we can’t be billed” or “only X can be billed” based on a rule section that has been removed.
Instead, treat “proper party” as something you validate using your contracting relationships, service terms, and documentation chain.

The operational consequence: internal invoice routing must be deliberate

This is where many organizations bleed time and money: invoices get routed by habit, not by a defined “party of interest” logic.

A practical approach:

Define one internal owner for D&D intake (often finance ops or a shared services function).
Define a standard “match logic” for each account type (shipper direct, forwarder as contracting party, NVOCC pass-through, etc.).
Log who received the invoice and why, every time, so you can defend your position later.

The invoice checklist (turn requirements into a 2-minute validation step)

Below is a practical checklist you can use to validate D&D invoices before they enter payment workflow. It is designed to reduce “we paid it because it was easier” outcomes.

Category	What to verify (minimum)	Why it matters
Identifiers	Bill of lading number, container number, port of discharge (imports), and a stated basis for why the billed party is liable	Enables fast matching to shipment records and reduces “orphan invoices”
Timing fields	Invoice date, invoice due date, allowed free time (days), free time start/end, container availability date (imports) or earliest return date (exports), and the specific billed date(s)	Determines whether the billed window and free time are being interpreted correctly
Rate math	Total amount due and enough rate detail to understand how the total was calculated	Prevents paying charges you can’t reconstruct
Dispute path	Clear contact and clear process to request mitigation/refund/waiver	Ensures disputes go through the right channel and within the time window

Operational tip: make this checklist the gateway. If key fields are missing, the invoice should not proceed to “approve for payment” until it’s corrected or clarified.

The timing workflow (where teams gain or lose leverage)

Most D&D losses are timing losses: late intake, late dispute submission, or late evidence collection.

A simple workflow that works across shippers and forwarders:

Step 1: Intake (Day 0–1)

Record date received and invoice metadata.
Match invoice to shipment/container record.
Assign an “owner” for review (ops for event verification; finance for payment gating).

Step 2: Validate (Day 1–3)

Verify key milestone dates (availability, gate-out, earliest return, empty return, holds).
Confirm free time rules applied match the account’s service terms and any documented concessions.

Step 3: Decide (Day 3–7)

Pay if valid and within policy.
Dispute/mitigation request if not valid, unclear, or unsupported.

Step 4: Resolve (Day 7–30)

Track dispute status.
Document outcomes and update playbooks (which terminals, carriers, or depots repeatedly generate friction).

Why this matters: the rule standardizes dispute timelines, but internal teams often lose the window because the evidence is scattered and approvals are slow.

The “dispute-proof pack” (what to collect before you argue)

Disputes are won or lost based on proof and sequence. The most effective teams treat evidence collection as a standard package—not a one-off scramble.

A dispute-proof pack typically includes:

Milestone evidence

Terminal availability notice (or portal screenshot)
Gate-out / gate-in confirmations
Empty return acceptance (where applicable)
Appointment records or denials (if relevant)

Hold and constraint evidence

Customs holds, exams, or documentation holds (timestamps and release notices)
Terminal congestion notices or restricted gate notices
Chassis unavailability confirmation (where documented)
Weather or force majeure operational notices (when applicable)

Communication evidence

Email or portal confirmation of any free-time extension or concession
Named contact and time-stamped approval trail

Internal record evidence

TMS milestones as recorded
Delivery attempts and exceptions (timestamps, location, reason codes)

Important: the best evidence is time-stamped and sourced from systems of record. A narrative summary helps, but it rarely substitutes for objective timestamps.

Practical implementation: a 30-day SOP rollout

If January is your governance reset month, this is a realistic rollout plan that doesn’t require a full transformation program.

Week 1: Define the gate

Who owns D&D intake?
What fields must be present before an invoice enters payment workflow?
What is the escalation path (ops → finance → account owner → legal/compliance when needed)?

Week 2: Standardize event definitions

Teams often dispute the meaning of “availability” or “return date” more than the math itself.

Define what counts as “available”
Define what counts as “returnable”
Define how holds change the operational interpretation

Week 3: Build a dispute tracker

A simple tracker is enough if it is consistently used:

invoice received date
dispute submitted date
evidence pack status
outcome (waived/reduced/paid/denied)
root cause classification (holds, terminal constraints, appointment, documentation)

Week 4: Close the loop

Identify top recurring causes by terminal, carrier, inland node, and customer
Update SOPs and customer communications accordingly
Decide what should be automated (alerts on availability/free time, missing invoice fields, dispute deadlines)

Common pitfalls to avoid in 2026

1) Treating “what changed” as “everything changed”

Only one provision was removed. Most operational requirements remain.

2) Letting free-time changes live only in inboxes

If an extension or concession isn’t captured in your system of record, teams will behave as if it never happened. That leads to avoidable disputes—and avoidable payments.

3) Paying first, disputing later, without a playbook

Some environments push “pay-to-release” behavior. Even then, teams should:

capture evidence immediately
submit mitigation/refund requests within the standard window
track resolution outcomes systematically

4) Assuming the same logic applies to every account type

Shipper-direct vs forwarder-contracting vs NVOCC pass-through workflows differ. The invoice routing, validation logic, and documentation chain need to be explicit per customer segment.

Where a visibility layer helps (without replacing the discipline)

A D&D playbook is only as strong as the team’s ability to pull milestones quickly and consistently.

A visibility layer (whether inside a TMS or via a dedicated platform like TRADLINX) helps most when it:

consolidates container-led milestones into one timeline
reduces “status hunting” across portals
enables early alerts on high-risk milestones (availability, gate-out delays, return windows)

The value is not “more tracking.” It’s faster exception handling and cleaner proof packages when invoices arrive.