The Accuracy-vs-Speed Tradeoff in an OCR Pipeline, Measured

A client processing invoices at volume wanted faster OCR throughput — the existing pipeline was a bottleneck during month-end close. The obvious move was swapping to a lighter, faster OCR model. It processed documents about 3x faster. Character-level accuracy dropped from 99.2% to 97.8%, which sounded like a rounding error nobody would notice.

Why 1.4 points of accuracy actually mattered

At the volume this client processed — tens of thousands of invoices monthly — that 1.4-point drop translated into roughly 400 additional documents per month with at least one character error, mostly in line-item totals and vendor IDs. Every one of those required manual review and correction, averaging about four minutes each once someone actually traced the error back to its source. We measured it: the speed gain saved the pipeline about six hours of processing time a month. The accuracy loss cost the accounts payable team roughly 27 hours of manual correction.

A faster model that creates more errors downstream isn't actually faster, it just moves the time cost onto someone else's desk.

We ended up on a hybrid: the fast model for a first pass, with a confidence-threshold trigger that routed anything below a set score to the slower, more accurate model for a second pass. That captured most of the speed gain on the easy majority of documents while keeping accuracy on the harder tail that actually drove manual correction cost.

• Never evaluate an OCR speed/accuracy tradeoff on the model metrics alone — measure the downstream correction cost at your actual volume.
• A small accuracy percentage drop can represent a large absolute number of errors at scale.
• Confidence-threshold routing between a fast and slow model often beats picking either one outright.
• Talk to whoever does the manual correction work before assuming a tradeoff is free — they're the ones who'll feel it first.

The instinct to chase throughput numbers is understandable, but throughput isn't the metric that costs the business money. Total time-to-correct-invoice is, and that number only went down once we stopped optimizing OCR speed in isolation from what happened to the output after it left the pipeline.