Case Study
How a Freight Business Stopped Reviewing Every Document by Hand.
A freight settlement business moved from manual paperwork to automated extraction, evidence checks, and structured results. The supplied estimates put manual review at roughly 10% of submissions, with typical single-page processing under a minute.
- Need manual review, down from all submissions
- ~10%
- Per typical single page, down from hours or days
- <1 Min
- More documents processed per day
- 20×
The Challenge
The Paperwork Was Holding Up the Next Decision.
Prepare the routine work automatically, and give reviewers the evidence and reasons they need to handle the exceptions.
The Business Context
The business coordinates freight settlement and financing. Bills of lading, proof-of-delivery receipts, rate confirmations, and carrier invoices arrive as scans, phone photographs, and PDFs. Operations staff need usable information from those documents before the next settlement decision can move forward.
Staff opened each submission, transcribed its contents, and checked the carrier and delivery evidence. As intake grew, routine preparation competed with the cases that needed closer judgement. Partners also needed a way to submit paperwork and receive results directly from their own systems, with a record of the checks behind each result.
- A clear digital document and a poor-quality phone photograph entered the same review queue.
- Routine transcription took time away from investigating missing information and questionable evidence.
- Carrier details, signatures, and line items needed consistent checks, with reasons available for later review.
- Partners needed system-to-system submission and results, without waiting for a person to move each file.
What We Delivered
We built an asynchronous document-processing platform with authenticated partner submission, image preparation, text and signature detection, AI-assisted structuring, carrier-registry checks, and a rule-based integrity score. Results are stored with their supporting evidence and delivered through encrypted, digitally signed callbacks, with API retrieval as a fallback. The platform also records document history, separates partner access, and supports ongoing product development.
The Solution
Four Problems, and What We Built for Each.
01 / 04
One review queue for everything
- Bill of lading (PDF)
- Proof of delivery (photo)
- Carrier invoice (scan)
The Problem
A Clear PDF and a Blurry Phone Photo Waited in the Same Queue
Documents arrived as scans, phone photographs, and PDFs, and all of them went to the same manual review.
- Bill of lading (PDF)Continues
- Proof of delivery (photo)Stopped: unclear
- Carrier invoice (scan)Continues
What We Built
Every File Prepared, and Unreadable Ones Stopped Early
Files are brought into a common format. A page that cannot be read well enough stops there, with the reason recorded.
How We Built It
- 01
Any File AcceptedPDFs, photographs, and multi-page scans are prepared in one common format
Reading with a Quality CheckAmazon TextractBlank pages are set aside, and an unclear page stops with a reason
- 03
Signatures Assessed SeparatelySignature evidence is judged on its own, apart from the text
Python services on serverless AWS infrastructure, working through separate queued stages.
02 / 04
- Carrier
- Ship date
- Line items
- Signature
Read by a person, and typed in field by field The Problem
Typing Out Documents Took Time from the Cases That Needed Judgement
Staff opened each submission and transcribed its contents before any real review could start.
- Carrier
- Ship date
- Line items
- Signature
Kept as written, and tied to the original What We Built
AI Prepares the Record. People Handle the Exceptions.
AI-assisted extraction prepares a consistent freight record, keeping each field as written in the document.
How We Built It
AI-Assisted StructuringOpenAI APIOrganizes the extracted text into a consistent freight record
- 02
Checked Against the OriginalThe line-item count has to agree before the output is accepted
- 03
Exceptions Go to a PersonDocuments that need judgement reach a reviewer, with the reasons
The original document and its history stay available beside every result.
03 / 04
Checked differently each time
- Line items
- Signature
- Carrier identity
- Ship date
- Carrier code
The Problem
The Checks Needed to Be the Same Every Time
Carrier details, signatures, and line items needed consistent checks, with the reasons kept for later review.
The same five checks, each with a reason
- Line itemscomplete
- Signaturepartial
- Carrier identitymatched
- Ship datepresent
- Carrier codemissing
What We Built
A Score That Explains Itself
Every document gets the same five checks, and each result shows what contributed and why. The score supports review. It is not a fraud probability.
How We Built It
- 01
Five Checks on Every DocumentLine items, signature, carrier identity, ship date, and carrier code
- 02
Carrier Registry CheckCarrier details are validated against the registry
- 03
A Reason behind Every PointEach result carries the contribution and reason for each check
The score is rule-based, so a reviewer can always see how it was reached.
04 / 04
Partner’s system
A person moves each file
The platform
Every file waited for someone to pass it on The Problem
Partners Were Waiting for a Person to Move Each File
Partners needed to submit paperwork and receive results directly from their own systems.
Partner’s system
The platform
Submitted by APIResult signed and encryptedAlways retrievable What We Built
Partners Connect System to System
Each partner submits by API and receives its results signed and encrypted. If its endpoint is down, the result is kept and can be retrieved.
How We Built It
- 01
Each Partner Kept SeparateIts own credentials, result destination, and delivery keys
- 02
Results Sent Back SecurelySigned and encrypted before they leave the platform
- 03
Nothing Lost If Delivery FailsProcessing stays complete, and the stored result can be fetched through the API
Infrastructure is defined in TypeScript and deployed with SST.
From an Uploaded Document to a Result a Partner Can Use
The Previous Process
- Scans · Photographs · Freight PDFs
Open Each Submission
Type In Its Contents
Check the Carrier and Delivery Evidence
Every submission depended on a person reading the file, entering the information, and checking the available evidence before work could continue.
The Document-to-Result Workflow
- 01
Partner’s System
Accept and Prepare
Validate the upload, store the original, and prepare page images
02 · The Platform
Read and Structure
Extract text and signature evidence, then organize the freight data
03 · The Platform
Check and Score
Validate carrier information and explain each scoring contribution
04 · Reviewer
Deliver and Review
Return the stored result to the partner; route exceptions with reasons
The score supports a partner’s review workflow. It does not establish that a document is genuine or authorize a funding decision.
Technologies Used
Python
Document Processing & APIs
AWS
Serverless Cloud Infrastructure
Amazon Textract
Text & Signature Detection
OpenAI API
Structured Document Extraction
SST
Cloud Infrastructure & Deployment
TypeScript
Infrastructure Definitions
How the System Was Built
- 01
Accept the Documents the Business Actually Receives
Partners submit a document with their own reference number and receive a platform identifier while processing continues in the background. PDFs, photographs, and multi-page scans are prepared in a common format so the next stage receives consistent input.
Technical Detail: Accept the Documents the Business Actually Receives
The intake API validates format, size, and partner-scoped reference uniqueness before storing the source file. PyMuPDF rasterizes PDFs and Pillow handles images and multi-frame TIFFs. Page images are retained as separate artifacts. The supplied implementation uses 600 DPI rasterization and a 5 MB submission limit.
- 02
Stop Unclear Evidence before It Becomes Structured Data
Text extraction includes a quality check, and blank pages are excluded from the document’s confidence calculation. A document that cannot be read well enough stops with a recorded reason. Signature detection is assessed separately from text quality.
Technical Detail: Stop Unclear Evidence before It Becomes Structured Data
Amazon Textract extracts text and signature regions. The supplied configuration requires a mean OCR confidence of at least 75% across non-blank pages and uses a separate 60% signature-detection threshold. These are processing thresholds, not measured extraction accuracy or proof of a valid signature. Extracted text and detection evidence are retained for review.
- 03
Keep Structured Information Tied to the Original
AI-assisted extraction prepares a consistent freight record while preserving the fields as written in the document. The platform checks that the two representations agree on line-item count before accepting the output, and checks carrier identity against a public registry where the required details are available.
Technical Detail: Keep Structured Information Tied to the Original
The OpenAI API supports the structured-extraction service. The service returns canonical and source-field representations; a line-item-count mismatch fails validation. Carrier checks compare the extracted registration identifier and legal name with registry data. Input validation checks the data contracts, and database transactions keep the final payload and document state together.
- 04
Show Why a Document Needs Review
A score is useful only if the team can understand it. The platform scores line-item completeness, signature evidence, carrier identity, ship-date presence, and carrier-code presence. Each result includes the contribution and reason behind each check.
Technical Detail: Show Why a Document Needs Review
The default 10-point rubric assigns 3 points to complete line items, 4 to detected signature evidence, 2 to carrier identity, and 0.5 each to ship date and carrier code. When a signature is not applicable, its weight moves to carrier identity and routing bands change; the selected mode is recorded. The score is deterministic for the same inputs and rubric version. Its scale is not a calibrated probability of fraud or authenticity.
- 05
Connect Partners without Mixing Their Records
Each partner has its own credentials, result destination, and delivery keys. Results are signed and encrypted before being sent to that partner. If its endpoint is unavailable, processing remains complete and the stored result can be retrieved by either platform ID or partner reference.
Technical Detail: Connect Partners without Mixing Their Records
Tenant-scoped queries and ownership checks separate partner access. The delivery envelope uses RSA-PSS with SHA-256 for signatures and hybrid encryption with Fernet and RSA-OAEP. Callbacks are best-effort; failures are captured for investigation and do not roll back the result. Partner-specific enrichment adds metadata without changing the shared fields used for scoring.
- 06
Make Processing Failures Traceable
Document preparation, extraction, and structuring run through separate queued stages. The platform records progress and failure reasons so the team can find where work stopped. API activity and document history provide two views of the same submission.
Technical Detail: Make Processing Failures Traceable
SST and TypeScript define the serverless infrastructure; Python workers use queues and persisted document states. Workers check the expected state before acting to reduce duplicate processing under message redelivery. External calls have timeouts, and multi-record writes use transactions. API logs omit file content and oversized payloads; lifecycle logs record transitions separately.
The Results
Less Routine Preparation. More Attention on the Exceptions.
What Was Delivered
The platform connects document intake, extraction, carrier checks, scoring, and partner delivery in one recorded workflow. Partners receive structured information with a breakdown of the checks. Reviewers can examine the original document, extracted fields, and processing history when something needs attention.
Reported Operational Change
The supplied project account estimates that manual review moved from every submission to roughly one in ten, with typical single-page documents processed in under a minute. The project owner also reports a 20-fold increase in documents processed per day. The team continued handling exceptions and investigations rather than transcribing every file. Delivery to general availability took nine months, followed by ongoing product engineering.
Review-load and processing-time figures were supplied as indicative estimates. The 20-fold increase in daily document processing was separately reported by the project owner. No measurement period, sample size, or independent validation was provided. Processing time is not settlement time, and the integrity score is not a measured fraud-detection rate.
What Changed for the People Doing the Work
- Operations Analysts
- Receive exceptions with reasons and supporting evidence, with less routine transcription in the reported workflow.
- Risk & Review Teams
- See the checks behind a score and the recorded rubric mode when deciding what needs further investigation.
- Integration Partners
- Submit documents from their systems and receive structured results through callbacks or API retrieval.
- Support Teams
- Trace a submission through its API activity, document history, and recorded failure reason when a partner asks what happened.
- Technical Teams
- Investigate failures by processing stage and maintain partner-specific requirements without changing the shared freight record.
What This Project Reinforced
A Clear Failure Is a Useful Result
If the document cannot be read reliably, return a reason that someone can act on. Uncertain extraction should not become an unexplained decision.
Keep the Evidence beside the Score
A number supports review when its inputs and checks can be examined. It cannot replace the judgement needed to establish what happened.
Make Optional Checks Explicit
Some documents legitimately lack a signature. Record which rules applied so reviewers can interpret the score in context.
Separate Processing from Delivery
A partner’s unavailable endpoint should not erase completed work. Store the result first and retain another way to retrieve it.