Building a D&D evidence file that gets disputes credited

Why the file decides the dispute

Billing desks at carriers and terminals handle D&D requests in volume. The requests that get credited quickly have the same thing in common: the person reading them can verify the claim in a few minutes without asking for anything else. The requests that stall are the ones that say "the port was congested" and attach nothing.

Part 541 and the FMC's incentive principle give billed parties real grounds to dispute. 46 CFR § 541.5 removes the obligation to pay an invoice missing required information, § 541.7 removes it for invoices issued late, and 46 CFR § 545.5 frames unreasonable D&D as charges that do not serve their incentive purpose. None of that helps without a file that proves the facts. After running audit desks for years, I think of the file in four layers.

Layer one: the invoice

Start with the invoice exactly as received: the PDF, the portal record or the EDI transaction, and every attachment. Keep the proof of when it arrived (email header, portal posting time or EDI receipt log), because § 541.7 timing and your own § 541.8 request window both run from issuance.

Run the element check against the 20 items in § 541.6 and record the result in the file: which elements are present, which are missing, and the subsection for each gap. Note the printed dates that matter most for the merits: free time start and end, container availability date for imports, earliest return date for exports, and the specific dates charged.

Layer two: the shipment documents

Next come the documents that define what should have happened. The bill of lading (master and house, if an NVOCC is involved). The arrival notice and any availability notice, with send times. The delivery order. For exports, every booking confirmation and amendment. And the rule the charge is based on: the tariff rule, terminal schedule or service contract section the invoice cites under § 541.6(c)(2), with the free time and rate it actually provides.

That last item catches more errors than people expect. An invoice that applies a tariff rate when your service contract sets different free time, or that applies the wrong tier, is a rate dispute you can win on the documents alone.

Layer three: the event record

This is where most disputes are won or lost, and where most files are thin. The event record shows what the container could and could not do on each day billed.

Carrier milestones come from EDI 315 status messages or the carrier's API: discharge, release, outgate, empty return, export ingate. Terminal records come from the terminal's website or a data provider: availability status, holds, yard location. Gate transactions are documented by equipment interchange receipts (EIRs) or gate tickets. Appointment availability and empty-receiving notices have to be captured as they appear, because the terminal's systems show current status, not history.

Every capture needs a visible timestamp and should identify the terminal, the date and the transaction type. One capture is an anecdote; captures at shift start, midday and afternoon on each disputed day are a record.

• EDI 315 or API milestones per container
• Terminal availability, hold and yard status captures
• Gate tickets and equipment interchange receipts
• Appointment system captures showing no availability
• Empty-receiving notices and rejected ingate tickets
• Carrier and terminal advisories, with send times

Layer four: communications and mitigation

The last layer shows that you tried. Keep the trucker's dispatch log and attempted bookings, any street turn request and the response, emails with the carrier's customer service about holds or return locations, and proof of freight payment and customs release where a hold is in question.

Mitigation evidence answers the billing party's most common response: that the cargo owner could have avoided the charge. A file that shows repeated attempts to book appointments, return empties or clear holds makes that response hard to sustain.

Keep the internal side too. Notes from your own import desk about when a hold was raised with the carrier, when the broker filed, and when the warehouse was ready to receive show the timeline from your end. If a billing party argues that the delay was yours, those notes, with dates, are what answer it.

Worked example: assembling the packet

Pinecrest Hardware, a 1,200 TEU importer of tools and fasteners, receives a demurrage invoice for eight 40-foot containers: 7 days each at $200 per day, for 8 x 7 x $200 = $11,200. Its file shows that on 4 of the 7 billed days the terminal's appointment system had no import slots for those containers' yard block, captured three times a day with timestamps, and that its trucker attempted bookings on each of those days.

The packet opens with a one-page summary: invoice number and issuance date, bill of lading and container numbers, the 4 disputed days, the amount disputed (8 x 4 x $200 = $6,400) and the amount accepted (8 x 3 x $200 = $4,800). The check: $6,400 + $4,800 = $11,200. The basis follows in two lines: § 545.5(c)(1) and (c)(2)(i), and the § 541.6(e)(2) certification.

Behind the summary, the exhibits run in the order a reviewer needs them: the invoice with the element check, the per-container timeline built from EDI 315 events, the appointment captures sorted by day, the trucker's attempted bookings, and the gate tickets showing pickup on the first day appointments opened. Nothing is attached that the summary does not reference.

Gaps that sink a file

Most weak files fail in predictable ways. The most common is evidence without timestamps: a screenshot of an empty appointment calendar proves nothing if it cannot be tied to the disputed day. The second is evidence for the wrong place: an appointment capture from a different terminal, or for exports when the box was an import. The third is summaries instead of sources, such as a trucker's email saying "no appointments all week" with no captures behind it.

Container-level mismatches cause quieter failures. A packet that disputes four days on eight containers, but only has evidence for six of them, invites a partial denial and a second round of correspondence. Build the timeline per container and dispute only what each container's record supports.

Finally, watch for arithmetic that does not reconcile. If the disputed amount plus the accepted amount does not equal the invoice total, the reviewer stops trusting everything else on the page. Show the sum.

Timing, retention and reuse

Send the packet inside the § 541.8(a) window, at least 30 calendar days from issuance, and diary the billing party's 30-day resolution window under § 541.8(b). Keep the file after the dispute closes. If a charge assessed by a common carrier is denied without a real answer, the same file, plus the denial, is the core of a charge complaint under 46 U.S.C. § 41310, where the carrier bears the burden of establishing that D&D charges were reasonable.

ATAHSKIA builds this file automatically: the OSRA Audit Engine handles layer one, Milestone & Gate Tracking captures layers two and three as events happen, and Automated Disputes assembles the packet in the order above. Our /resources/invoice-checklist and the free retrospective audit at /free-dd-audit are good starting points if you want to see your own files first.