The review queue is the product

A model at 92% accuracy is useful or useless depending entirely on what happens to the other 8%.

Accuracy figures get quoted in sales meetings as if they settle the question. They do not. A system that handles 92% of invoices correctly is either a large saving or a new source of work, and which one it becomes is decided entirely by the interface you build for the remaining 8%.

Get it wrong and the failure mode is predictable. Uncertain items pile into a queue nobody owns, someone checks it late on Friday, and after a month the team quietly starts double-checking everything the system does. You now have the old process plus a machine.

What works is narrower than it sounds. Show the extracted value next to the source, highlighted, in the same view. Make correcting a field a single keystroke, not a modal. Sort the queue by cost of being wrong rather than by arrival time. And feed every correction back, so a supplier whose format needed review in week one is handled automatically by week four.

The measure we care about is not accuracy but queue depth over time. If it trends down, the system is learning and the team is trusting it. If it trends flat, something in the loop is broken, and it is usually the interface rather than the model.

This is why we spend as much design time on the exception path as on the happy path. The happy path is invisible when it works. The exception path is the entire experience of the people who have to live with your system.