A browser-based delivery verification tool built to replace manual sticker-to-box checks
The problem with checking deliveries by hand
Verifying a delivery means comparing a document's line items against physical stickers and box contents — three sources of truth that rarely line up cleanly. Done manually, it's slow, easy to get wrong, and leaves no record beyond a checked-off paper.
What the tool needed to do
Build a browser tool that could take a delivery document in whatever format it arrives — PDF, Excel, or CSV — read sticker photos with OCR, match items against the document automatically, let an operator confirm or flag exceptions, and produce an exportable record of the whole check.
One tool: parse, OCR, match, confirm, export
The result is a self-contained browser app: upload the delivery document and sticker photos, let it score matches by GTIN, code, or description, then step through on-sticker and in-box confirmations with manual override where needed, and export the finished verification as JSON.
Our other projects
The brief was to remove the manual, error-prone step of cross-checking a delivery document against sticker photos and physical box contents, and replace it with a single guided tool.
Delivery checks require matching line items from a document against physical package stickers and box contents at the same time. Doing that by eye is slow, inconsistent between operators, and easy to get wrong on high-volume days.
This is a browser prototype, not a production logistics integration. Public content about it should describe the tool as a proof of capability rather than imply it's connected to a live inventory or shipping system.
A browser-based tool accepts delivery documents in PDF, Excel, or CSV form, runs sticker photos through OCR, scores matches against the document by GTIN, code, or description, lets operators mark each item as found on the sticker and in the box (with manual not-found and undo controls), and exports the completed check as a dated JSON file.
The browser parses the uploaded delivery document into a structured item list, runs sticker images through an OCR step, and cross-references the two using GTIN, code, and description signals. Operator confirmations update a live status view — Total Items, On Sticker, In Box, Complete — and the final state exports to JSON for recordkeeping.
- Delivery document upload for PDF, Excel, or CSV
- Sticker image OCR
- Automated GTIN, code, and description matching
- On-sticker and in-box confirmation states with manual override
- JSON export of the completed verification
The prototype turns a manual, error-prone reconciliation step into a guided browser workflow — a strong proof point for operations tooling, ready to demo once it's populated with placeholder delivery data.
- Working document parser, OCR processor, item matcher, and export pipeline
- Live UI counters for Total Items, On Sticker, In Box, and Complete
- Manual override and undo controls for exception handling
Is this specific to one industry, or could it work for us?
The pattern generalizes well: any operation that receives a document — packing slip, invoice, manifest — and has to verify it against physical items is a fit. What changes per business is the matching logic (GTIN, SKU, or free-text description), and that gets scoped around whatever identifiers the buyer's documents and stickers actually use.
Why put this in Webflow if external code is involved?
Webflow is the public storytelling and CMS layer. The parsing, OCR, and matching logic run in the app itself, where they can be versioned, tested, and improved without touching the site.
What's needed before this becomes a public case study?
Fake delivery documents and sticker images that show the matching and export flow clearly, without any real vendor or product data.
It shows SoFlow can take a manual, error-prone operational check and turn it into a focused browser tool that parses, matches, and tracks state without requiring a bespoke backend system.
Is this specific to one industry, or could it work for us?
The pattern generalizes well: any operation that receives a document — packing slip, invoice, manifest — and has to verify it against physical items is a fit. What changes per business is the matching logic (GTIN, SKU, or free-text description), and that gets scoped around whatever identifiers the buyer's documents and stickers actually use.
Why put this in Webflow if external code is involved?
Heading 1
Heading 2
Heading 3
Heading 4
Heading 5
Heading 6
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
- Item 1
- Item 2
- Item 3
Unordered list
- Item A
- Item B
- Item C
Bold text
Emphasis
Superscript
Subscript
Heading 1
Heading 2
Heading 3
Heading 4
Heading 5
Heading 6
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
- Item 1
- Item 2
- Item 3
Unordered list
- Item A
- Item B
- Item C
Bold text
Emphasis
Superscript
Subscript
Delivery verification relied on someone manually comparing a document, a sticker, and the physical box — with no consistent record once the check was done.
Operators now work through a structured, OCR-assisted checklist that tracks match status in real time and produces an exportable record of every check.
The workflow needs local document parsing, image OCR, fuzzy item matching, stateful confirmation tracking, and file export — none of which a static Webflow page or CMS collection can do on its own.
