Document Intelligence returns confidence per field, per word and per selection mark

Confidence in Document Intelligence is one number per value. It is the probability that a specific extracted value was detected correctly, expressed from 0 to 1, and it comes back per field, per word and per selection mark ^[8]. Microsoft's accuracy and confidence documentation sets the target: "It's best to target a score of 80% or higher. For more sensitive cases, like financial or medical records, we recommend a score of close to 100%." ^[11] The dev.to post's reading is that invoices are financial records, so a blanket 0.80 across every field is not a defensible design for anything that moves money ^[12].

The scenario the post opens with is document 400: a vendor sends a scanned fax with a handwritten purchase order number, the model returns a total at 0.61 confidence, and the flow posts it straight into the accounting system ^[15]. Read that score as a frequency and 1 - 0.61 leaves roughly a 39% chance the value is wrong ^[17]. The sample response in the post shows InvoiceId at 0.981, about 1.9% ^[16][18]. So the field that sets the payment amount is around twenty times likelier to be wrong than the field that names the document ^[19].

For that comparison to transfer, the 0.61 has to behave like a frequency on your document mix and not merely as an ordering. The post does not report a measured confidence distribution or what share of documents ended up in each lane ^[20]. Absent that, the size of the review queue is a guess.

Accuracy is a different number with a different job. It is returned at training time for custom models and describes how well the model predicts labeled values on visually similar documents, and custom neural and generative models do not return an accuracy score during training at all ^[9]. The post's division of labour: gate on confidence, and use accuracy to decide whether the model is worth deploying ^[10]. For a neural or generative custom model, that deployment decision has to come from somewhere other than the training run.

Model selection sits ahead of all of it. The prebuilt invoice model is generally available on v4.0 (2024-11-30) and supports 27 languages, per Microsoft's invoice model documentation ^[7]. The post says to start there and build a custom model only once you can point at specific fields the prebuilt schema misses, and that choosing wrong costs weeks ^[21]. When you want tables and structure instead of semantic fields, the model ID to pass is prebuilt-layout ^[6].