A proposal crossed my desk with a line in it I have now seen in some form a dozen times: ninety five percent accurate on invoice data extraction. Everyone in the room read it the same way, which is that one invoice in twenty would come through with something wrong and somebody would catch that one. That is not what the number said. Nobody asked what was being counted, and the vendor had no reason to volunteer it.

Accuracy is a fraction, and a fraction needs a denominator. The claim almost never comes with one. That is rarely dishonesty. The vendor measured what their engineers measure, which is fields, and the buyer hears what they care about, which is documents. Those two numbers sit a long way apart, and the gap is where the work nobody budgeted for lives.

Accurate at what, counted how

Say an invoice has twelve fields you need: vendor, invoice number, date, due date, PO number, subtotal, tax, total, and four line items. A system that gets each field right ninety five percent of the time is not getting ninety five percent of invoices right. If the errors fall independently, the chance that all twelve fields are right on one document is 0.95 multiplied by itself twelve times, which is about 0.54. So roughly half of your invoices arrive with at least one field wrong on them.

Errors do not really fall independently. They cluster, because one bad scan ruins several fields at once, which makes clean documents cleaner than the arithmetic suggests and messy ones worse. Either way, the honest reading of a ninety five percent per field claim is that most documents need a person to look at them, and the question becomes which person, looking for what.

Two failures, two very different prices

A single accuracy number also averages together two mistakes with nothing in common operationally. One is a wrong value the system was sure about, so it passed. The other is a correct value it was unsure about, so it got flagged. Both count as one error. They cost wildly different amounts.

Only the last row is expensive, and it is the row an accuracy number describes worst. Two systems can both land on ninety five percent while one puts nearly all its errors in row two and the other puts them in row four. Where money moves or records get reported on, those are not comparable products, and the proposal will not tell them apart.

When the answer is almost always no

Accuracy gets stranger the rarer the thing you are hunting. Say you want duplicate invoices caught, and three invoices in a hundred are duplicates. A system that flags nothing, ever, is ninety seven percent accurate. You could build it in an afternoon, and it would clear the accuracy bar in most proposals I read.

So for anything that detects an exception, and most operational AI detects exceptions, accuracy is the wrong measure. You want two numbers. Of the duplicates that were there, what share did it catch. Of the ones it flagged, what share really were duplicates. The industry calls these recall and precision. You do not need the vocabulary, you need both numbers, because either one can be raised by sacrificing the other and one accuracy figure hides that trade completely.

A confidence score is not a probability

Most of these systems attach a number to each value they pull: 0.92 on the invoice number, 0.61 on the PO. Everyone reads 0.92 as a ninety two percent chance of being right. It is the model's own internal score, and whether it tracks how often the answer is really correct is something you measure rather than assume. A score can be genuinely useful or completely flat, and the two look identical in a demo.

The test takes an afternoon. Take a few hundred values you already know the right answer for, sort them into buckets by the score the system gave them, and count how often each bucket was actually right. If everything above 0.9 is right ninety nine times in a hundred and the 0.7 to 0.9 band is right eighty times in a hundred, you have learned something real and you can set a routing threshold on it. If both bands come back at about the same rate, the score is not carrying information and a threshold on it is decoration.

That threshold decides who sees what. It is the dial that moves errors between row two and row four of that table, and it usually gets set once, early, by whoever configured the system, off a number nobody has checked.

Measured on whose documents

Every accuracy figure is measured on some set of documents. Vendor benchmark sets are clean by construction, because they were assembled to demonstrate the product. Your set is not, and your exceptions are the reason you are buying anything.

So ask for the sample to be yours. Two hundred to three hundred documents is enough, and you choose them: the handwritten one, the two page fax, the vendor who puts the PO number in the memo line, the credit note against two invoices, last December when volume tripled. Then have the output scored against what you know to be true, field by field. A vendor who will not run that, or who wants to pick the sample, has told you where their number came from.

The number worth putting in writing

When this reaches an agreement, I would rather see one number than an accuracy percentage, and it is not a measure of the model. Call it the escape rate: how many wrong values reach a downstream action with no person in between, per thousand documents. That is what your business actually feels, it stays measurable after go live, and it holds the vendor to an outcome rather than a benchmark.

It also puts the attention where it belongs. The escape rate is set much more by how you route and review work than by which model is underneath, which is the same reason a review queue does more for reliability than a better prompt does. If you want that part, it is covered in Why AI Workflows Need Review Queues.

Questions worth asking before you sign

1. Is that per field or per document, and across how many fields?
2. On which documents was it measured, and can we run the same test on three hundred of ours that we pick?
3. Of the errors, what share are wrong values that passed, and what share are correct values that got flagged?
4. Has the confidence score been calibrated, against what, and how recently?
5. What escape rate would you be willing to write into the agreement?

None of these are gotcha questions. A good vendor has answers, or says plainly that they have not measured it yet. What you are listening for is whether the number came from someone who thought about your operation or from a benchmark page. You can usually tell inside two minutes, and the gap between a per field claim and a per document reality gets paid for by your team, every day, for years.