Today we're introducing On-Device Field Detection, a new capability in the Veryfi Lens SDK that validates receipts the moment they're captured, not after they've been uploaded, processed, and potentially rejected. It's a small shift in when validation happens, and it changes a lot about what happens next.
Hey Product Hunt 👋
I'm Marianna, Marketing Manager at Veryfi. We build document processing APIs, and one thing we kept hearing from teams using our Lens SDK was: "the receipt looked fine when it was captured, then it got rejected two days later." By that point the user's gone, and someone's stuck manually chasing it down.
So we moved validation to the only moment that matters, capture, not upload.
On-Device Field Detection checks vendor, date, and total right on the confirmation screen, before the user ever taps submit. It runs fully on-device, no server round trip, no waiting, works offline. If something's missing, they see it immediately and can fix it on the spot.
It's a small UX change with a real downstream effect: fewer rejections, less manual review, cleaner data going into whatever system relies on it (expense tools, loyalty programs, cashback platforms, etc.).
Would love to know — for those of you building anything with document/receipt capture, is validation-at-capture something you've tried to solve for, or does it usually get handled after the fact in your stack? Happy to go deep on how the on-device models work if anyone's curious.
Makes sense. The choice I'd be most curious about is which error direction you bias the on-device model toward. A false reject just asks for a retake while someone's still holding the receipt, but a false accept ships bad data your server catches days later, which is the exact round-trip you built this to kill. We ended up setting the on-device cutoff a notch conservative and ate a few extra retakes. Did you land the same way?
the calibration discussion in this thread covers the false-confidence direction well, on-device says it's fine and the server disagrees later. curious about the other direction though: the lighter on-device model flagging a field as missing/unclear and asking someone to retake a receipt that the full server model would've actually accepted just fine. that's a worse user experience than the original problem in a way, since now you're annoying someone who did nothing wrong instead of just catching genuine bad scans. is that failure mode rarer in practice, or is retake-friction just the accepted tradeoff for catching the real rejects earlier
The capture-time validation is the right call. The piece I'd pin down is threshold calibration. To fit an app bundle the on-device model is almost certainly quantized, and int8 quantization shifts the confidence distribution enough that an accept/reject cutoff tuned on your server model reads differently on-device. When we shipped a quantized field extractor, a 0.8 confidence cutoff that was safe on the full-precision model started waving through borderline scans. Do you recalibrate the on-device thresholds against the quantized model specifically, or share one cutoff across both?
validation at capture is right — the sharp edge is the on-device check disagreeing with the heavier server extractor later. late rejection becomes silent disagreement; keeping the two models aligned is the real maintenance cost.
Validating fields on-device at capture, before anything is uploaded, is the right place to catch a bad receipt scan; the rejection round-trip is exactly the pain when you process after upload. The part I'd test first: does the extraction run fully offline with the receipt's PII never leaving the device until I choose to sync, and roughly what model footprint does the Lens SDK add to an app bundle? And on a failed field, do I get per-field confidence back to drive my own retry UI, or just pass/fail?
Anyone who has had an expense claim bounce back days later over a blurry receipt will feel this one. Catching it right there while I'm still holding the thing is exactly where I always wished it would happen.
This seems amazing @marianna_babayan1 . I was looking for a ready app to use like this. Thanks a lot!
About On-Device Field Extraction by Veryfi on Product Hunt
“Secure on-device extraction even if you're offline”
On-Device Field Extraction by Veryfi launched on Product Hunt on July 8th, 2026 and earned 97 upvotes and 15 comments, placing #19 on the daily leaderboard. Today we're introducing On-Device Field Detection, a new capability in the Veryfi Lens SDK that validates receipts the moment they're captured, not after they've been uploaded, processed, and potentially rejected. It's a small shift in when validation happens, and it changes a lot about what happens next.
On-Device Field Extraction by Veryfi was featured in Fintech (47.2k followers), Tech (627.5k followers) and Tech news (2.6k followers) on Product Hunt. Together, these topics include over 183.6k products, making this a competitive space to launch in.
Who hunted On-Device Field Extraction by Veryfi?
On-Device Field Extraction by Veryfi was hunted by Marianna Babayan. A “hunter” on Product Hunt is the community member who submits a product to the platform — uploading the images, the link, and tagging the makers behind it. Hunters typically write the first comment explaining why a product is worth attention, and their followers are notified the moment they post. Around 79% of featured launches on Product Hunt are self-hunted by their makers, but a well-known hunter still acts as a signal of quality to the rest of the community. See the full all-time top hunters leaderboard to discover who is shaping the Product Hunt ecosystem.
Reviews
On-Device Field Extraction by Veryfi has received 1 review on Product Hunt with an average rating of 5.00/5. Read all reviews on Product Hunt.
Want to see how On-Device Field Extraction by Veryfi stacked up against nearby launches in real time? Check out the live launch dashboard for upvote speed charts, proximity comparisons, and more analytics.
Marianna Babayan