# Proof of Delivery Processing: Matching PODs at Scale

> Why matching a POD to the right shipment among thousands of documents is the real bottleneck, and which fields make a POD hold up under a freight claim dispute.

**Canonical URL:** https://docsapi.co/resources/blogs/proof-of-delivery-processing
**Author:** Nupura Ughade — Content Marketing Lead, DocsAPI
**Author LinkedIn:** https://www.linkedin.com/in/nupura-ughade/
**Published:** 2026-09-10T00:00:00.000Z
**Updated:** September 10, 2026
**Primary topic:** proof of delivery processing
**Site:** https://docsapi.co (DocsAPI — Document AI & OCR API for SMB Lending)

---

A regional LTL carrier delivers forty pallets to a distribution center outside Chicago. Every carton arrives intact. The receiving clerk signs the driver's handheld terminal, writes "4 pallets, no exceptions" in the notes field, and the truck pulls away on schedule. Four months later, the carrier still hasn't been paid for that load, because when the broker disputed the freight bill over a separate, unrelated shortage claim on a different shipment, the carrier's operations team went looking for the signed proof of delivery and could not find it. Not because it didn't exist. It existed, sitting in a folder of nine thousand other scanned delivery receipts collected that quarter, filed under a PRO number that a piece of OCR software had misread by one digit. The document was there. It just wasn't attached to anything.

That is the actual shape of the proof of delivery problem, and it is almost never the shape vendors describe it as. Most coverage of [shipping document processing](/documents/shipping-docs) treats POD handling as a field-extraction exercise: pull the recipient name, the timestamp, the signature, the exception notes. Extraction is real work, and handwritten signatures and margin notes are genuinely hard to read. But extraction was never the part that stalls freight payment cycles. The part that stalls them is matching, taking a signed receipt that carries a smudged, cropped, or misheard reference number and correctly attaching it to one specific shipment record among the thousands moving through a mid-size carrier's system in any given month. Get the matching wrong and the extraction quality underneath it stops mattering, because nobody downstream can find the document when they need it.

## Why this is a matching problem before it's an extraction problem

Picture the scale a mid-size truckload or LTL carrier operates at. A carrier running a few hundred trucks can easily generate several thousand signed delivery receipts a month, arriving as faxes, email attachments, driver app photos, and scanned paper handed back at the dock. Each one needs to land on exactly one shipment record in the TMS. The join key that is supposed to make that possible, usually a PRO number, BOL number, or load ID, is the single field most likely to be wrong on the document, because it is the field most often handwritten by a driver standing at a loading dock rather than printed by a system.

Contrast that with how a bill of lading or a commercial invoice gets matched. Those documents are usually generated by an ERP or TMS and carry a printed, machine-generated reference number, so an exact string match against the shipment index usually works. A POD breaks that assumption twice over. First, it is frequently a paper form or a driver-facing app screen where the reference number was written by hand or selected from a truncated dropdown list, so OCR confidence on that one critical field is lower than on any other field on the page. Second, even when the number is printed clearly, drivers running multi-stop routes routinely deliver several shipments in the same afternoon that share an origin, a destination zip, and a delivery date, sometimes even the same consignee receiving two separate loads. A reference number that OCR reads with even modest uncertainty can plausibly match more than one candidate shipment in the system, and exact-string matching has no way to break that tie. It either matches on the nose or it doesn't match at all, and when it doesn't, the document drops into an exceptions queue that grows faster than any team can manually clear it.

## What actually links a POD to a shipment record

Because the primary key is unreliable, a matching pipeline that works in production has to treat the reference number as one strong signal among several, not as the only signal. The useful secondary signals are the ones a POD is required to carry anyway: the delivery date and time, the weight or piece count, the origin and destination, and the carrier or driver identifier. None of these fields is unique on its own, plenty of shipments move 1,860 pounds on a given Tuesday between the same two zip codes, but combined, they narrow a fuzzy reference-number match down to one plausible candidate almost every time.

| Match signal | Typical source format | Reliability as a standalone key | Common failure mode |
| --- | --- | --- | --- |
| PRO / BOL / load number | Handwritten, stamped, or driver-app selected | High when clean, but the single most error-prone field on the document | Digit transposition or substitution from handwriting or low-res scans |
| Delivery date | Printed timestamp or handwritten date | Moderate; narrows candidates to a single day | Handwritten dates default to the wrong month near month boundaries |
| Weight or piece count | Carried over from the BOL, sometimes re-keyed by the driver | Moderate; strong when it matches exactly, weak on its own | Partial deliveries or re-weighed loads legitimately differ from the BOL |
| Origin / destination pair | Printed address block or zip code | Low alone, since many shipments share a lane | Multi-stop routes share destination with several other loads that day |
| Consignee name | Printed or stamped on the receipt | Low to moderate; strong combined with date | Large receiving facilities can have several loads for the same consignee daily |
| Signature / recipient name | Handwritten | Not a match key; evidentiary field only | Illegible or absent; does not identify which shipment was received |

## A worked example: scoring a match when the reference number is wrong

Say a carrier's OCR pipeline reads the PRO number off a scanned POD as **0348217**. The shipment index has no exact match for that number, but it does have a load recorded under PRO **0346217**, delivered the same day, at the same weight, on the same lane. Comparing the two strings character by character shows exactly one mismatch: position four reads 8 where the record shows 6, every other digit lines up. That is a Levenshtein edit distance of 1 across a seven-character string, which gives a normalized string similarity of (7 minus 1) divided by 7, or roughly 0.857.

A single fuzzy string match at 85.7 percent similarity usually isn't enough to auto-link a document with confidence, since plenty of unrelated PRO numbers in a large enough shipment file will sit at a similar edit distance from each other purely by chance. This is exactly where the secondary signals earn their keep. If the matching logic weights the reference-number similarity at 0.5 of the total match score, and adds 0.2 for an exact delivery-date match, 0.15 for a weight match within tolerance, and 0.15 for an exact origin-destination pair match, the composite score comes out to (0.5 × 0.857) + 0.2 + 0.15 + 0.15, which is 0.4286 + 0.2 + 0.15 + 0.15, or approximately 0.929. A composite confidence of 92.9 percent clears a typical auto-match threshold set anywhere in the high 80s to low 90s, so the document links automatically to the correct shipment without a human ever opening it, even though the raw reference number never matched anything on the nose.

That is the actual mechanism that keeps a POD queue from becoming an unworkable backlog: not better handwriting recognition on the reference number alone, but a scoring model that never depends on any single field being perfect, because on a document filled out by hand at a loading dock, no single field reliably is.

## Why POD quality determines whether a carrier gets paid on a disputed freight bill

Matching the document to the right shipment only solves half the problem. The other half is whether the matched document actually holds up once someone disputes the freight bill, and federal law is specific about what that requires. The Carmack Amendment, codified at 49 U.S.C. § 14706, sets a near strict liability standard for interstate motor carriers, but it hands the shipper a three-part burden of proof before that liability attaches: the shipper must show the freight was tendered to the carrier in good condition, that it arrived at destination in damaged or short condition, and the dollar value of the resulting loss. Once those three elements are established, the burden shifts to the carrier to prove one of a narrow set of recognized defenses. The proof of delivery is the document that carries the second element of that test, the condition of the goods as they actually arrived, which means a POD that cannot be reliably matched to its shipment cannot do the one thing it exists to do in a dispute: pin down what happened, and to which load, at the moment of handoff.

This cuts both directions. A shipper trying to prove a shortage or damage claim needs a POD that ties cleanly back to the disputed shipment. A carrier trying to defend a freight bill, or trying to prove that a load it billed for was in fact delivered as agreed, needs the same thing. If a carrier can't produce a matched, legible POD when a broker or shipper disputes the bill, it has no evidence to counter the claim with, and unresolved cargo claims routinely become the reason a disputed freight invoice sits unpaid well past normal terms while the two sides sort out liability.

## The federal claims-investigation clock a POD has to survive

The Carmack Amendment doesn't operate on an open-ended timeline, and neither does the regulation governing how carriers are required to process the claims that come in. 49 CFR Part 370 sets binding deadlines on both sides of a dispute, and a POD that can't be located or produced quickly is a direct liability against those deadlines.

| Regulatory step | Citation | Requirement |
| --- | --- | --- |
| Minimum time to file a claim | 49 U.S.C. § 14706(e)(1) | Carriers must allow at least 9 months from delivery for a shipper to file a claim |
| Claim acknowledgment | 49 CFR § 370.5 | Carrier must acknowledge receipt of a written claim in writing within 30 days |
| Claim investigation | 49 CFR § 370.7 | Carrier must promptly and thoroughly investigate, supported by the bill of lading and evidence of freight charges |
| Final disposition | 49 CFR § 370.9 | Carrier must pay, decline, or make a firm settlement offer within 120 days of receiving the claim, with status updates every 60 days thereafter if unresolved |
| Deadline to sue after denial | 49 U.S.C. § 14706(e)(1) | Claimant has at least 2 years from written denial to file a civil action |

The 120-day disposition window under § 370.9 is the deadline that actually forces the matching problem into the open. A carrier that receives a damage claim on day one has 120 days to locate the matching POD, confirm what the receiving clerk actually noted at handoff, and either pay, deny, or make a firm settlement offer. If the POD is sitting unmatched in an exceptions queue on day 90, the carrier is not investigating a claim anymore, it is racing a regulatory clock with its own evidence missing. 49 CFR § 370.3(c) adds a wrinkle worth knowing here too: a bare notation of shortage or damage on a delivery receipt, standing alone, is not itself sufficient to satisfy the minimum filing requirements for a claim. A usable POD has to sit inside a properly filed claim that identifies the shipment, asserts liability, and states a dollar amount, which is one more reason the document has to be findable and legible fast, not just present somewhere in a file.

## What actually makes a POD usable as evidence, beyond just existing

A signed receipt that technically exists is not the same as one that can carry weight in a dispute. Based on what 49 CFR § 373.101 requires carriers to capture on a receipt or bill of lading, and what § 370.7 requires as supporting documentation during an investigation, a POD that actually functions as evidence needs a specific, narrow set of fields to be both present and legible:

- A reference number that ties unambiguously back to one shipment, either directly or through the fuzzy-matching signals described above
- Delivery date and time, since the Carmack burden of proof turns on condition at the moment of arrival
- Piece count or weight delivered, comparable against the figure on the originating bill of lading
- A clear indication of exceptions, damage, or shortage noted at the door, distinct from a document that is silently marked "clean" by default
- A recipient identifier, whether a signature, printed name, or stamp, establishing that someone at the consignee actually accepted the goods
- The carrier or driver identity, tying the document to the party that owned custody during transit

Miss the exceptions field specifically and a carrier loses the ability to show a clean delivery when a shipper later claims damage occurred after handoff. Miss the reference number's ability to be matched, even approximately, and none of the other fields matter, because nobody can find the document attached to the right claim inside the 120-day window that § 370.9 imposes.

## Where this fits against a disputed freight bill in practice

The scenario that opened this piece, a clean delivery that still went unpaid for months, is what happens when POD matching fails on an unrelated shipment and the resulting confusion bleeds into the carrier's ability to defend its own freight bill. A broker auditing invoices under a [freight bill audit](/resources/blogs/freight-bill-audit-automation) process will routinely request the POD as the first piece of supporting documentation before releasing payment, exactly the same document 49 CFR § 370.7 requires a carrier to produce during a claim investigation. If the carrier's own systems can't retrieve the matched receipt fast enough, the invoice sits in dispute regardless of whether the delivery itself was ever actually a problem. The same matching logic that links a POD to its shipment record is what feeds accurate delivery confirmation into [freight invoice automation](/resources/blogs/freight-invoice-automation) downstream, and it depends on the shipment first being correctly and unambiguously identified against the [bill of lading](/resources/blogs/bill-of-lading-processing) that governed the move in the first place. A POD is only as useful as the shipment record it can be reliably tied to, and at the volume a real carrier operates at, that tie is never guaranteed by a reference number alone.

Written by [Nupura Ughade](/author/nupura-ughade).

## Frequently Asked Questions

### Why is matching a proof of delivery to the right shipment harder than extracting its fields?

A POD's join key, typically a PRO, BOL, or load number, is usually the field most likely to be wrong on the document because it is often handwritten by a driver at a loading dock rather than system-generated. At the scale a mid-size carrier operates, thousands of PODs a month, an exact string match on that one field either succeeds or drops the document into an exceptions queue, since it has no way to resolve a near-miss against several plausible candidate shipments.

### What signals besides the reference number help match a POD to its shipment?

Delivery date, weight or piece count, and the origin-destination pair are the most reliable secondary signals, since a POD is required to carry them regardless of reference number legibility. None of these is unique on its own, but combined with even a partial match on the reference number, they can produce a high-confidence composite match without requiring the primary key to be perfect.

### How does the Carmack Amendment connect to proof of delivery quality?

The Carmack Amendment, 49 U.S.C. Section 14706, requires a shipper to prove three things to establish carrier liability: the freight was tendered in good condition, it arrived damaged or short, and the dollar value of the loss. The proof of delivery is the document that establishes the second element, the condition of goods at arrival, so a POD that cannot be matched to its shipment or reliably read cannot support either side's position in a dispute.

### What deadlines does 49 CFR Part 370 impose on freight claims involving a proof of delivery?

Carriers must acknowledge a written claim within 30 days under Section 370.5, and must pay, decline, or make a firm settlement offer within 120 days under Section 370.9, with status updates every 60 days if the claim remains open beyond that. Claimants must generally be given at least 9 months from delivery to file a claim, and at least 2 years from a written denial to file a lawsuit, per 49 U.S.C. Section 14706(e)(1).

### Can a shortage or damage notation on a delivery receipt alone count as a filed freight claim?

No. Under 49 CFR Section 370.3(c), a bad order report or a bare notation of shortage or damage on a delivery receipt or freight bill, standing alone, does not satisfy the minimum filing requirements for a claim. A proper claim must separately identify the shipment, assert liability, and state a specific or determinable dollar amount.

### What fields make a proof of delivery actually usable as evidence in a dispute?

A usable POD needs a reference number that can be tied to one shipment (directly or through fuzzy matching), delivery date and time, piece count or weight delivered compared against the bill of lading, a clear exceptions or damage notation, a recipient identifier such as a signature, and the carrier or driver identity. Missing the exceptions field or the ability to match the reference number undermines the document's evidentiary value even if every other field is legible.


---

**Source URL (cite this):** https://docsapi.co/resources/blogs/proof-of-delivery-processing
**Author profile:** https://docsapi.co/author/nupura-ughade
**Published by:** DocsAPI (https://docsapi.co)