Looking at expense automation. Dext Prepare is on the shortlist for our revops team.
Heard claims of 99%+ accuracy on receipts. In practice, I'm skeptical. Need specifics from real use.
* What's the actual failure rate on standard items? (e.g., vendor name, date, total amount)
* Does it consistently handle:
* Poor quality photos (blurry, glare)?
* Foreign currencies on receipts?
* Handwritten line items or totals?
* What's the manual correction workflow like? How many clicks to fix a misread field?
We sync to NetSuite. A high error rate creates more work downstream, not less.
null
That 99% figure is a lovely bit of marketing math, isn't it? It likely means 99% of *something* on *some* subset of perfectly formatted receipts. In the wild, your failure rate on standard fields like vendor name will be much higher than 1%. Think about all the boutique coffee shops or client dinners at "The Grill on 5th" where the logo is just a squiggle.
Where it really falls apart is the handwritten totals or line items. It will guess, often comically wrong, and then you're in the correction workflow. Which, to answer your question, isn't a matter of clicks but of re-typing the data yourself. So you've paid a premium to do data entry on a slightly nicer form.
If you're syncing to NetSuite, the cost isn't just the correction. It's the risk of polluted data flowing downstream before you catch it.
Beware of free tiers
The 99% claim is usually for total amounts on printed receipts in major currencies. For vendor names, I'd say we see a 10-15% manual correction rate in our pipeline. It's not just boutique shops, even common chain logos get mangled if the receipt is crumpled.
On your specific points:
* Poor quality photos: It'll try, but glare on thermal paper is a killer. You'll get a "review" flag.
* Foreign currencies: Solid on EUR, GBP, CAD. Anything else, and the total might be placed in the wrong field.
* Handwritten items: Assume it will fail. The correction workflow isn't terrible - you click the field and type - but it defeats the automation purpose.
Syncing to NetSuite is the real kicker. You need a validation stage before export, which adds another layer. The cost is the manual review, not just the subscription.
pipeline all the things
The vendor name correction rate you mentioned, 10-15%, lines up with what I'm seeing in my trial. It's the crumpled receipts from big chains that really surprise me, like when it reads "Starbucks" as "Starbmks" and I don't catch it. That's a sneaky error.
You're right about needing a validation stage before NetSuite. I'm wondering, does Dext's own "review" queue count as that, or do you have to add an extra approval step in your process? Trying to figure out if the built-in tools are enough or if we're just moving the manual work upstream.
Totally share your skepticism about that 99% figure. In my own tinkering, I've found it's more like a tiered accuracy model.
The total amount on a clean, printed receipt in a major currency? Yeah, that's probably hitting 99%. But vendor name and date are a different story. It's not a simple "failure rate" because the system often makes a plausible *wrong* guess, like reading "Hilton" as "Hillon" or catching a slogan instead of the business name. That's where the real manual review burden kicks in.
For your specific questions:
- Poor quality photos usually trigger a "review" flag, but sometimes it confidently reads the glare as a number.
- Foreign currencies are decent on majors, but I've seen it put a JPY total in the VAT field.
- Handwritten anything is a hard no. It'll try and you'll have to retype.
The correction workflow itself is quick, maybe two clicks to edit a field. But the cost is in the mental overhead of spotting the errors before they hit NetSuite. You don't just fix a field, you become a vigilant proofreader.
Oh, that 99% figure. It's always 99% of something you don't quite need, isn't it? The real issue is that a 'failure' isn't always a blank field. Sometimes it confidently populates your vendor field with the restaurant's slogan from the footer. "The Best Coffee in Town" isn't a great general ledger entry.
For your NetSuite sync, the built-in review queue is just a holding pen. You still need a human to validate every single field before it gets pushed, which means you're building an entire pre-approval step into your process. So much for removing manual work.
Handwritten items? Don't even bother. It'll give you a number, but it'll be as useful as a guess from a magic eight ball.
Trust but verify – especially the audit log.
> The real issue is that a 'failure' isn't always a blank field.
Exactly this. The worst errors are the plausible ones that pass a quick glance. We saw "5" vs "S" substitutions on handwritten totals, like "95.00" read as "9S.00". Syncs to NetSuite before anyone blinks.
Their review queue isn't a validation layer. It's a detection queue. You still need the human to be the validation stage, which just moves the manual work instead of removing it. Your pre-approval step becomes mandatory.