Freight Document Fraud: Edited BOL, Delivery Order and POD PDFs

A hypothetical, not a customer story: picture a freight factoring desk on a Tuesday morning. A small carrier the factor has funded for months uploads a packet for a load that delivered last Friday: the broker’s rate confirmation, the bill of lading, a signed proof of delivery and the carrier’s invoice. The invoice carries a detention charge and a lumper fee on top of the linehaul. The POD shows the delivery date, the receiver’s signature and the piece count the invoice depends on. The underwriter checks that the carrier is who it says it is, matches the invoice total to the rate confirmation plus accessorials, and approves the advance.

What nobody on that desk asks is whether the POD PDF is the same file the driver app produced on Friday, or a copy that someone opened in an editor on Monday night and changed by one line.

Carrier vetting answers ‘is this carrier real?’ The packet review answers ‘do these numbers agree with each other?’ Neither asks whether a specific PDF was rewritten after it was issued. That question often has an answer, and it lives in the file.

Scope: the file, not the carrier

This article is about freight paperwork that arrives as a PDF and that someone pays against: the factor advancing on a carrier invoice, the broker or 3PL settling with a carrier, the claims team paying out on a shortage, the freight audit and pay team or shipper AP releasing a payment. The question a structural PDF check answers is narrow: has this file been edited since it was issued?

It complements carrier vetting rather than replacing it. Vetting is about who sent the packet; a file check is about the file they sent. Neither does the other’s job.

Plenty of freight fraud never touches a PDF edit, and a file-layer check has nothing to say about it:

• Double brokering. The U.S. regulator itself notes that the term is not defined by statute or regulation and that people use it for several different activities. Whatever the variant, it is about who moved the load and who got paid, not about an edited document.
• Carrier identity theft and MC/DOT number hijacking. Impersonating a real carrier is an identity problem. It belongs to carrier vetting and onboarding.
• Fictitious pickups and cargo theft via fake carriers. Same territory: who showed up at the dock.
• Electronic bills of lading on eBL platforms that are not PDFs. Out of scope.
• Legal validity and negotiability of a BOL as a document of title. Whether a bill is negotiable or nonnegotiable is a legal question about its wording and its holder, not about its file structure.
• Duplicate financing. The same genuine BOL or invoice pledged to several factors. The file was never altered, so a structural check has nothing to find.
• Content truth. Weights, piece counts, consignee, release numbers. Confirm those with the issuer or the booking system. Structural checks don’t read values.

What is left is the paper this check is built for: documents issued by one party and edited by another before they reached you.

Where a freight packet gets edited

Generic invoice-fraud patterns are covered in types of invoice fraud schemes. This section goes through the freight packet document by document.

Bill of lading

The BOL is the record of what was tendered: shipper, consignee, commodity, pieces, weight, sometimes seal numbers and special instructions. The edits that matter to someone paying against it are the ones that move money or move liability: a consignee name changed, a weight or piece count adjusted to match an inflated invoice, a pickup date shifted so a load fits a rate confirmation it was never booked under.

A BOL issued by a carrier or TMS portal and changed afterwards in a PDF editor often leaves structural traces of that second write. They come back as named modification markers on the result.

Delivery order

A delivery order is the instruction that releases cargo to a named trucker or party – in drayage and import work, for example. The in-scope case is narrow: a delivery order that was genuinely issued and then edited afterwards, such as a changed release party, pickup window or container reference.

Whether the party named on a delivery order is entitled to the cargo is a different question. Release fraud and impersonation of a trucking company are identity problems, and the answer comes from the issuing line or forwarder, not from the file.

Proof of delivery

Most of the money in a factoring or settlement workflow hinges on the POD, because it is what turns a load into a payable invoice. The alteration patterns are mundane:

• a delivery date moved, so a late load reads as on time or a detention clock looks longer than it was;
• a receiver’s name or signature swapped;
• a piece count inflated to match an invoice, or exceptions and shortage notes removed;
• a POD from another load relabelled for this one.

Each of these is a document edited after it was produced. When the edit happens in a PDF editor on top of the file the driver app or carrier system issued, it often leaves traces in the file’s structure – independent of how convincing the page looks.

Carrier invoice and accessorials

The invoice is where an edit pays off. Linehaul stays as booked; detention hours, lumper fees, layover or TONU charges grow. The general case of an altered invoice is covered on our fake invoice detection page, and the same check inside an AP workflow – which is where freight audit and pay, or shipper AP, sit – on the accounts payable page. The freight-specific point is that an accessorial is often supported by another document in the same packet – the POD’s in and out times, a lumper receipt – so when an accessorial looks high, check the document that supports it as a file too, not only the invoice.

What each verdict means on freight paperwork

The API returns one of three verdicts – intact, modified or inconclusive – and freight paperwork produces all three. These are the cases you will see at intake.

Fillable-form BOLs. A BOL completed as a fillable PDF form usually comes back inconclusive with status_reason filled_form_origin. Expected for a form, but not a clean bill: the check can’t vouch for the values a form shows. Treat the values as unconfirmed and check them against the issuer or the booking system.

Fill & Sign on a BOL or POD. A document completed with a Fill & Sign tool usually returns inconclusive with fill_sign_origin. The check can’t vouch for what a Fill & Sign tool put on the page. Some forms of tampering still produce modified, but don’t read inconclusive here as ‘no edit found’.

Scanned or photographed PODs. A scan or photo cannot return intact; it usually comes back inconclusive with scanned_document or unverifiable_metadata. A scan can still come back modified when the file itself carries signs of editing. An inconclusive scan is not grounds for withholding carrier pay, declining an advance or denying a claim.

Merged packets. Don’t expect intact on a packet merged from separate files. It can come back modified – often naming HTPBE_PAGES_FROM_MULTIPLE_SOURCES or the tool that assembled it – or inconclusive. Either way the verdict is about the packet file, not whether any single page is genuine: a merge of genuine documents can still come back modified. Where you can, ask for the component files and check each one. Treat the packet verdict as a routing signal, not a fraud finding.

TMS and carrier-system exports. An unaltered system export can return intact. Some systems’ output reads as inconclusive instead, depending on how they generate the PDF. A field changed afterwards often leaves structural traces, reported as named markers such as HTPBE_EDITING_TOOL_FINGERPRINT.

Word and Excel documents. A document built from scratch in office software usually returns inconclusive with consumer_software_origin. For a document that claims to come from a carrier’s system, that origin is a reason to route it for review, and a later edit can make it modified. The limit of scope runs the other way too: a document that was false when it was issued can come back intact. intact means no sign of change after creation, not that the contents are true.

Cryptographically signed PDFs. A PDF that carries a certificate-based digital signature and was edited after signing comes back modified with HTPBE_POST_SIGNATURE_EDIT and modification_confidence certain – our strongest class of finding. ‘Signed’ here means a certificate signature, not a Fill & Sign mark or a pasted signature image. A normal multi-party signing workflow is not by itself reported as tampering. A document with a signature drawn on the page usually returns inconclusive with visible_signature_origin. HTPBE? does not check certificates, signer identity or signature validity.

Three more things to know when reading results:

• An inconclusive result can still list markers. Read them before you route.
• analysis_incomplete is an inconclusive reason that means the check could not finish in full. Re-run it.
• The best input is a file as close to the issuing system as possible: the BOL from the carrier or TMS portal, the POD from the driver app, not a forwarded packet three emails deep. A POD that arrives printed to PDF or flattened is a step removed from the issuer – ask for the original (more in print-to-PDF flattening and tampering).

Routing, never automatic denial

A modified verdict is evidence that a file changed after it was created. It is not a finding of fraud, and on its own it is not a basis for withholding carrier pay, declining an advance, cutting off a carrier or denying a cargo claim. PDFs in freight get re-saved for ordinary reasons all the time – a dispatcher rotates a page, a back office merges documents for a portal upload.

The API ships that constraint in the payload rather than leaving it to the integrator. Every result carries a usage_caution object with safe_for_automated_adverse_decision: false and a recommended_action: route_to_human_review for modified, request_from_issuer for inconclusive, no_action for intact. Route on that field.

In a factoring or settlement workflow that means:

• modified → a human review queue, with the marker list attached so the reviewer knows what to look at;
• inconclusive → a request to the issuer for the original (the carrier’s TMS portal, the driver app, the shipper) or lower-priority review, especially when the document claims to come from a system;
• never an automatic rejection of a carrier, a driver or a claim.

Integration

The API is one POST with a URL to the document and one GET for the result:

curl -X POST https://api.htpbe.tech/v1/analyze \
  -H "Authorization: Bearer $HTPBE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "url": "https://factor.example.com/intake/load-40417-bol.pdf" }'
# → { "id": "8d2f6a1c-4b7e-4f3a-9c5d-1e2b3a4c5d6e" }

curl https://api.htpbe.tech/v1/result/8d2f6a1c-4b7e-4f3a-9c5d-1e2b3a4c5d6e \
  -H "Authorization: Bearer $HTPBE_API_KEY"

An abridged result for a BOL that was edited after export:

{
  "id": "8d2f6a1c-4b7e-4f3a-9c5d-1e2b3a4c5d6e",
  "status": "modified",
  "modification_confidence": "high",
  "has_digital_signature": false,
  "modification_markers": ["HTPBE_EDITING_TOOL_FINGERPRINT", "HTPBE_MULTIPLE_REVISION_LAYERS"],
  "usage_caution": {
    "safe_for_automated_adverse_decision": false,
    "recommended_action": "route_to_human_review",
    "message": "..."
  }
}

On your side the logic is a switch on status, then on status_reason when the result is inconclusive. Every account gets a test key (htpbe_test_*) that returns deterministic synthetic results for a fixed set of scenarios, so you can build the routing branches before a single real packet goes through. If you want to try it by hand first, the web upload gives you 5 free checks on signup, and then it is pay-per-check. For a quick look at what a file says about itself, there is also a PDF metadata viewer.

What this does not solve

• Who the carrier is. Identity, authority, insurance, MC/DOT numbers, double brokering. That is carrier vetting.
• Whether the load moved. A check on a POD file says nothing about whether delivery happened. Confirm it with the receiver or the shipper.
• Whether the values are true, or whether a genuine document was financed twice. Both are covered in the scope list above: neither involves an edit to the file.
• Documents that were false at issue. A document that carried wrong details from the start can come back intact.
• eBLs that are not PDFs, and the legal standing of a bill of lading. Out of scope.

Where it fits

If you factor freight, settle with carriers or pay freight claims, you already collect these PDFs. A structural check is one API call per file, run at intake next to carrier vetting, and it surfaces a category of evidence – edits to a file after it was issued – that carrier vetting and packet review don’t look at. Many results on freight paper will be inconclusive, because forms and scans are what this industry runs on. What changes is which packets a human opens first, and that a POD gets examined as a file, not only as a picture of a signature.

Start with the API documentation and pricing – test keys work before you commit to anything.