On-Device Field Extraction by Veryfi
Secure on-device extraction even if you're offline
Start new thread

On-Device Field Extraction by Veryfi - Secure on-device extraction even if you're offline

by•
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.

Add a comment

Replies

Best
Hunter
📌
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.

 will it work if I capture a billboard

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.

Hunter

 Really good callout, that's exactly the tension we had to design around. The on-device model is deliberately lighter-weight for speed and offline use. Thanks!

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.

Hunter

 exactly, that's the moment we designed the product for. "Still holding the thing" is a perfect way to put it. Thanks !

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?

Hunter

 Appreciate the thoughtful questions, those are exactly the kinds of implementation details we're happy to walk through directly. Feel free to and we can go deeper there. Thanks!

 Totally fair, will reach out for the deep dive. One quick one that decides fit for us though: does the on-device field detection run fully offline at capture, or does the validation step still make a network round-trip to your API before it clears the receipt?

This seems amazing . I was looking for a ready app to use like this. Thanks a lot!

Hunter

 Thanks so much for the kind words!

Just a quick note on what this is — the On-Device Field Extraction is part of the Veryfi Lens SDK, which is a developer tool that companies embed into their own mobile apps to capture and validate receipts and documents in real time.

If you're looking for a ready-to-use expense management app, we actually have one for that: Veryfi Expense Management App at . It's available on iOS and Android, free to start, and handles receipt scanning, reporting, and accounting integrations like QuickBooks and Xero.

Hope that points you in the right direction!

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?

Hunter

 Thanks for the thoughtful question, calibration between on-device and server models is definitely something we account for internally. Appreciate you raising it.

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

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?