How to Automate OS&D Claims Processing End-to-End

OS&D — Over, Short, and Damaged — is the broadest category of freight exceptions and the single largest source of recoverable revenue most shippers leave on the table. Industry data puts manual OS&D recovery rates at 35–45%, while automated workflows hit 70–85%. The gap is not a tooling gap. It is a process gap: too many eligible claims never get filed, and too many filed claims get denied for documentation that already exists in your order system.

This guide walks through the seven-step workflow to automate OS&D claims processing across LTL, FTL, parcel, and ocean — covering the exception triggers, documentation requirements, carrier-specific filing channels, and the follow-up loop that drives recovery from 40% baseline to 80%+.

TL;DR: OS&D Automation Outcomes

What Is an OS&D Claim?

An OS&D claim is a formal request for compensation filed against a carrier when freight arrives in an unexpected state. The three sub-types:

• Over — the consignee received more units, weight, or pieces than the bill of lading lists. Often signals a misrouted shipment or a mislabeled pallet.
• Short — pieces are missing on arrival. The most common subtype is "concealed shortage," where the outer packaging is intact but units are missing inside.
• Damaged — the freight arrived but is unusable. Subdivides into visible damage (apparent at delivery) and concealed damage (discovered after the consignee accepts the shipment).

Each subtype has different documentation, different filing windows, and different denial profiles. A working automation system handles all three through one workflow with branching logic, not three separate processes.

Why OS&D Claims Are Hard to Automate

Most claims tools fail because they treat the claim as a form to fill out, when the real work is upstream and downstream of the form. Three structural reasons OS&D resists naive automation:

1. Documentation lives in five different systems. The BOL is in the TMS. The POD is in the carrier portal. The invoice is in the ERP. Damage photos are in a phone gallery or email attachment. The claim form is a PDF on the carrier's website. A working automation has to pull from all of them, which is why CorePiper's cross-platform case management approach matters here.

2. Each carrier has its own filing protocol. FedEx and UPS run portal-based claim submission with API hooks. Major LTL carriers (Old Dominion, Saia, XPO, Estes) take email submissions. Smaller carriers route through FreightClaims.com or paper. Parcel carriers want photos uploaded directly to the portal. Ocean carriers want notarized letters of protest. Generic claims tools that "support all carriers" almost always mean a single email template, which gets denied for non-compliance.

3. The deadline window varies by 50x across carriers and exception types. Concealed parcel damage at FedEx: 60 days. LTL concealed damage federal default: 9 months. Visible damage notation requirement: at delivery, before the driver leaves. An automation that does not encode these windows per carrier will silently miss filing deadlines on 30–40% of eligible claims.

The 7-Step OS&D Automation Workflow

Step 1: Define the OS&D event triggers

Map every signal that should fire a claim workflow. The high-confidence triggers:

• TMS exception codes (MercuryGate, McLeod, Project44 all expose these)
• Carrier tracking statuses: Damaged, Lost, Refused, Delivery Refused
• Warehouse receiving scans showing short or over counts vs. the BOL
• Consignee email or portal notifications referencing damage or shortage
• A ticket in Zendesk or Salesforce flagged with a claim category

Each becomes an event source the automation listens to. The first 30 days of running this is mostly tuning false positives — a carrier marking a shipment "Damaged" when only the outer carton scuffed, for instance — but after the tuning period the trigger map becomes the SOP that drives everything downstream.

Step 2: Connect document sources

Wire up the systems that hold the documentation. Typically:

• TMS for the BOL and shipment data (carrier, mode, freight class, dimensions, declared value)
• Order management (NetSuite, SAP, Shopify, Brightpearl) for the commercial invoice and product cost data
• Cloud document store (S3, SharePoint, Google Drive) for photos and the signed delivery receipt
• Email for consignee correspondence, freight bills, and adjuster communication

Connections should be read-only at this stage — the automation pulls, does not push. Any writes back into systems of record happen at Step 7 once the claim closes.

Step 3: Build the documentation assembler

Configure the agent to pull the BOL, POD, invoice, and photos and combine them into a single PDF claim package per the carrier's required template. The standard package includes:

• Bill of lading (original, with carrier pickup signature)
• Delivery receipt with consignee notation of the exception
• Commercial invoice showing the freight value
• Photographs (visible damage at delivery, concealed damage when discovered)
• Repair or replacement quotes
• Written claim narrative
• Carrier-specific claim form (prefilled)

The assembler runs validation: missing any of these blocks the claim from filing and triggers a human review task. This single check eliminates the 40–50% denial rate from documentation gaps.

Step 4: Configure carrier-specific filing

Set the filing channel for each carrier. The four main patterns:

• Portal API — FedEx, UPS, DHL Express. Claims submit via authenticated API call; status updates flow back via webhook.
• Email-with-attachment — Old Dominion, Saia, XPO, Estes, R+L Carriers. Claim PDF emails to a carrier-specific claims address; updates come back via email reply.
• Web form — most regional LTL carriers. The agent fills the form using browser automation.
• Third-party portal — FreightClaims.com handles small carriers and brokers without a direct claims process.

The automation handles channel selection per carrier without operator intervention. Add new carriers by configuring the channel once.

Step 5: Add a filing deadline guard

Encode each carrier's filing window as a structured rule. Examples:

• FedEx concealed damage: 21 days from delivery for inspection request, 60 days for formal claim
• UPS visible damage: 60 days from delivery
• LTL federal default (Carmack): 9 months for damage and shortage, 2 years for loss
• Most LTL carriers' notation requirement: at delivery, on the POD, or claim is barred
• Ocean carrier: 3 days from delivery for visible damage, 15 days for concealed

The agent flags any claim approaching its deadline (typically with a 30%/50%/80% time-elapsed alert) so it gets filed before expiry. Missed deadlines become rare exceptions instead of routine losses.

Step 6: Set up the follow-up loop

Most carriers acknowledge claims within 30 days but stall on settlement. The automation runs scheduled check-ins:

• Day 14: confirm carrier received and assigned an investigator
• Day 30: check status; escalate if not yet acknowledged (Carmack requires 30-day acknowledgement)
• Day 60: request settlement update; escalate to a regional claims manager if needed
• Day 90: prepare for legal escalation if the carrier still has not paid

The follow-up loop is what drives recovery from 45% to 80%. Carriers settle stalled claims faster when they see systematic follow-up than when claims sit silently in their queue.

Step 7: Wire payout tracking and reconciliation

When the carrier issues a settlement, the agent records the recovery amount, matches it against the original claim value, calculates the recovery rate, and creates a finance record so AR can apply the payment to the correct account.

The reconciliation step closes the loop in two directions:

• Operational metric — recovery rate per carrier, per mode, per claim type — feeds the next cycle's tuning
• Financial entry — settlement payment shows up in your AR system tied to the original claim and shipment

Without this step, recovered claims drift in carrier check format and never get reconciled to the right account, which is how teams "lose" recoveries even after winning the claim.

Carrier-Specific OS&D Filing Requirements

A working automation must encode the differences across carriers. The high-volume patterns:

These patterns drift over time — a carrier rolls out a new portal, an LTL carrier shortens its filing window — so the rule set has to be reviewed quarterly. Automation systems that hardcode rules and never refresh them silently fail.

Common OS&D Denial Reasons (And How Automation Eliminates Them)

The five reasons that explain 80%+ of OS&D denials, and how each gets eliminated:

Documentation gap (40–50% of denials). Missing the BOL, POD, invoice, photos, or notation. Automation pulls all of these from systems of record and validates the package before filing. Any missing doc blocks the claim and triggers human review.

Missed filing deadline (20–25%). The claim was eligible but filed after the window. Automation encodes the window per carrier and files within it.

Missing exception notation on POD (15%). The driver delivered, the consignee signed clean, then noticed damage afterward — but without notation, most carriers deny. Automation prompts the consignee at delivery to mark the POD with the specific exception code.

Wrong claim form or wrong filing channel (10%). The shipper emailed a claim that the carrier requires by portal, or used last year's form. Automation maintains current forms and channels per carrier.

Insufficient damage evidence (5–10%). Photos exist but don't show the damage clearly, or quotes are estimates instead of binding. Automation requests specific photo angles at delivery and binding repair quotes when the claim value crosses a threshold.

ROI of OS&D Automation

For a typical mid-market shipper running 500 OS&D claims per year, the math:

• Manual recovery rate: 40% × $1,200 average claim × 500 = $240,000 recovered
• Automated recovery rate: 80% × $1,200 average × 500 = $480,000 recovered
• Net annual uplift: $240,000
• Plus operational labor savings: 500 claims × 8 hours saved × $35/hr = $140,000
• Total annual benefit: $380,000

The ROI compounds. Year 2 recovery rates climb further as the rule set tunes and follow-up cadences tighten. Most teams hit a steady-state recovery rate of 80–85% by month 6.

SOP Template Starter

Use this skeleton to write your team's OS&D claims SOP — it maps directly to the seven-step automation flow above:

1. Trigger: TMS exception code OR consignee notification OR warehouse scan variance
2. Verify: confirm carrier liability (Carmack-eligible exception, not consignee error)
3. Assemble: pull BOL, POD, invoice, photos, quotes — run completeness check
4. File: route to carrier-specific channel within filing window; record submission timestamp
5. Track: acknowledge receipt by Day 5; investigator assigned by Day 14
6. Follow up: check-in cadence at Day 30, 60, 90; escalate stalls
7. Reconcile: record settlement amount; match to AR account; close case

This SOP is the input to a SOP-driven AI agent — every step becomes an automated tool call, every branch becomes an exception the agent surfaces for human judgment. The result is the 80%+ recovery rate without adding claims headcount.

Related Reading

• The 2026 State of Freight Claims Report — industry benchmarks for denial rates, cycle times, and recovery
• 10-Step Freight Claims Automation Workflow — broader claims workflow beyond OS&D
• Cross-Platform Case Management — why claims need orchestration across TMS, ERP, and helpdesk
• Logistics Claims Solution — CorePiper's approach to logistics claims automation

About the author: Mustafa Bayramoglu is the founder of CorePiper. He previously co-founded a YC W19 logistics company and has spent the last decade building automation for freight, claims, and B2B operations.