Accuracy and confidence answer different questions. Accuracy measures performance against checked answers; confidence is a model’s score for a particular prediction. Neither, by itself, decides whether a system should act without review.
What does an accuracy rate describe?
Accuracy describes performance on a defined, labelled sample. It can inform expectations for similar future work, but only if that sample represents the documents, fields and conditions the business will encounter.
Above all it says nothing about distribution. Ninety-nine per cent sounds identical whether the missing one per cent is a misread house number or an invoice sent to the wrong company. The average does not know the difference. The business does.
What does a confidence score describe?
It depends on the tool and prediction. A field score may estimate whether an extracted value is correct; a document-type score may describe resemblance to a learned class. Read the provider’s definition before interpreting a number.
Some tools return scores alongside individual words or fields. Others do not expose confidence for every result. A number generated by asking a chat model how sure it feels is not automatically a calibrated probability.
What does a confidence score not tell you?
Even a high score is not proof of correctness. Check calibration: among results assigned a similar score, how many are actually correct on a separate representative test set? Clean-looking inputs can still produce the wrong answer.
Use confidence as one review signal alongside missing fields, format checks, conflicting identifiers and business rules. High-impact actions may require approval regardless of the score.
What would a useful test look like?
Consider a hypothetical pilot with two hundred documents. A proposed threshold sends forty to review and accepts a hundred and sixty. Checking those accepted results finds four errors. That is 97.5% observed accuracy in the accepted group, not proof that the next document is safe.
Now examine what those four errors were. A punctuation mistake and a wrong bank account should not carry the same business weight. Repeat the test across document types and difficult inputs before deciding whether the threshold is useful.
Who decides where the threshold sits?
The business owns the acceptance criteria, with technical input from the supplier. Set thresholds using representative validation data and the cost of mistakes, not a number that looks reassuring in a demonstration.
Preparing a draft and executing a payment need different controls. Do not interpret a lower-risk use case as permission to guess: define what may be proposed, what can be written and what always requires approval.
What happens when the threshold is too high, or too low?
A high threshold can create more review than the team can handle. Measure that workload and assign an owner, so exceptions do not accumulate in an unattended queue.
A low threshold can pass too many errors. Adjust it only against checked results and continue sampling after launch. New document types or changing conditions may require tighter controls, not looser ones.
What should a buyer ask instead?
Ask what was tested, how errors were scored, which cases need review and who handles them. Request both the accepted-case error rate and the proportion sent to people. Include critical-field failures separately.
The useful purchase is not a single impressive number. It is a process with a measured quality level, clear stopping rules and a workable path for exceptions.
Further reading: Microsoft on accuracy and confidence in document processing
