Riverway Logistics
Paperwork intake
Turning a glovebox full of bills of lading into a folder anyone can search
Every load produces paper, and every piece of it has to be findable months later when a broker disputes a charge. I built an intake pipeline that takes a photo from a driver's phone, reads the load number off it, and files it in the right Drive folder without anyone typing a filename.
The job
A flatbed load generates paper at both ends. A bill of lading at pickup, a signed delivery receipt at the other end, a rate confirmation from the broker, scale tickets when the freight is heavy. None of it matters until somebody disputes something ninety days later, and then all of it matters at once.
The paper existed. It was in a truck. Getting it from a truck into a place where an office computer could find it was the entire problem.
What I found
The system, before I touched it, was text messages. A driver takes a photo of the BOL and texts it to whoever is on their phone. That photo lands in a message thread with a hundred other photos, gets saved to somebody’s camera roll, and eventually somebody sits down and drags files into Drive with names like IMG_4471.jpg.
Every step of that is a place to lose a document. And when a broker calls asking for proof of delivery on a load from two months ago, the search is a person scrolling through a phone.
The failure mode is not that the process is slow. It is that it is invisible. Nobody knows a document is missing until the moment they need it, which is the worst possible moment to find out.
What broke
Optical character recognition on a photograph of a bill of lading is nothing like OCR on a scanned page.
The documents come in creased down the middle from riding in a pocket. They are photographed at an angle, in a truck cab, sometimes at night with the dome light on, sometimes with a thumb in frame. Half of them are already a fax of a photocopy before the camera ever sees them. The load number I needed to read is often handwritten in a box that was designed for a typewriter.
The first version keyed on the load number and filed by that alone. It worked in testing, because I tested with documents I photographed myself on a desk. In the field, the recognizer would return a six-digit number that was correct except for a 5 where an S should be, or an 8 for a B, and the script would confidently create a brand new folder for a load that did not exist. I ended up with a Drive full of near-miss folders, each containing exactly one document, which is worse than no automation at all. At least the text message thread was honest about being a mess.
The second thing that broke was quieter. Apps Script stops a function at six minutes. Filing one document at a time, that ceiling is invisible. Processing a backlog is a different story, and the script would die partway through a batch with no record of where it stopped, so rerunning it duplicated everything it had already filed.
The fix
Two changes, and the second one mattered more than the first.
Match against loads that exist. The recognizer no longer gets to invent a load number. It reads candidates off the document, and each one is checked against the actual list of open loads. Character confusions that OCR reliably makes get normalized before comparison, so S and 5, B and 8, O and 0 collapse together. If exactly one open load matches, the document files itself. If more than one matches, or none do, it goes to a review folder with the extracted text attached, and a human spends four seconds on it instead of four minutes. Guessing is not allowed.
Make the batch resumable. Every document gets marked as processed the moment it is filed, not at the end of the run. When the six-minute limit hits, the script schedules itself to continue and picks up from the first unmarked document. Running it twice is now harmless, which means a failure in the middle of a batch is boring instead of destructive.
The naming convention is fixed and dull on purpose: date, load number, document type. Dull names sort correctly, and sorting correctly is most of what a filing system is for.
What I’d do differently
I would have built the review folder first. My instinct was to make the automation good enough that it never needed one, and that instinct cost me a Drive full of orphan folders and an afternoon of cleanup. An automation that handles eighty percent of cases and openly hands you the rest is more useful than one that handles ninety-five percent and hides its mistakes in the other five.
I would also log the confidence score alongside every filing decision. Right now I can tell you what the pipeline did. I would rather be able to tell you how sure it was, because that is the number that tells you where to spend the next hour of work.