How to handle the exception queue for document extraction
The exception queue for document extraction takes a row with a low confidence score, a blank required field, or a conflict with master data, and the same line records who may edit it, what changed, and which row may leave. The field list names each field and where it sits on the sample. This page is how a row enters human review after extraction, and how it leaves.
On this page
- Keep the exception queue apart from the field list
- A low score enters the queue on the company's own line
- When the tool returns no score, write that no score was returned
- An empty required field enters the queue even when the score is high
- Name who may change the extracted value
- When the row conflicts with master data, name the record that was compared
- Keep the value before, the value after, and the reason
- The row leaves when the releaser has signed
Keep the exception queue apart from the field list
The field list says, for each field, its name, where it sits on the sample, what counts as an acceptable value, who confirms it, and which queue it enters when it is blank or unreadable. The exception queue answers a different question: after a row has been extracted, how it enters human review when the confidence is low, a required field is empty, or it conflicts with master data; who may change the extracted value; what the change leaves behind; and when the row may leave. The review queue named on the field list is the exception queue on this page. The name is the one written on the list. How the fields are defined is in Which fields to define before document data capture.
A step that must wait for a person is still a human gate. How to write that gate is in Which human gates to write before workflow automation. How extraction, review, and export meet the daily work is under Document processing and data capture. This page does not rewrite the five items on a field, and it does not invent a queue name that the field list does not use.
A low score enters the queue on the company's own line
Read on 27 October 2026, Microsoft Learn: accuracy and confidence scores describes a confidence score as a probability: how sure the extraction is that the result is correct. The page shows no publication date. It says field confidence is an estimated probability between 0 and 1, and it uses 0.95 as an example of a prediction that is likely correct about 19 times out of 20. It says that where accuracy matters, confidence can decide whether to accept the prediction automatically or flag it for a person. It also says to consider human review in the workflow, and to add a human review stage for more critical automation. The page is written for Azure Document Intelligence. A capture flow can use the same distinction: automatic acceptance is only discussed when a score exists. The page does not require that product to be purchased.
For custom-model accuracy, the page says it is best to aim at 80 percent or higher, and close to 100 percent for more sensitive cases such as financial or medical records. That is the page's recommendation about training accuracy. The line the exception queue uses is written separately on the queue rule: which document type, which field, and below which score a row enters human review, with who agreed the line and on which day. Until that line is dated, a field that has a score does not leave the queue on its own, and it does not go downstream on its own. The figures 0.95, 80 percent, and close to 100 percent stay on the page. They are not copied onto the line. Amount fields still wait for the named colleague. See Which fields to define before document data capture.
When the tool returns no score, write that no score was returned
The page says that not every document field currently returns a confidence score. It also notes that, for custom models, field confidence includes word confidence from the 2024-11-30 general-availability API. A field with no score is logged as "no score". A 0 or a 1 is not filled in. A required field with no score enters the exception queue under the field list. An optional field with no score follows the list's rule for blanks: if the list says the field may be empty, the missing score does not by itself put it in the queue; if the list says a blank needs a person, it enters the queue.
The page also says to read the confidence of the text read and the confidence of the field extraction separately, because the read confidence does not become the field confidence. If the tool returns both, the log keeps both and names each one. If it returns only one, that one is kept and the other is "no score". A read score is not treated as permission for the field to leave the queue.
An empty required field enters the queue even when the score is high
The page says a cell or field with no value can be null and still carry a confidence. If the training set is mostly empty in that place, a high confidence on null means the model thinks the value is absent and that this judgement is more likely correct. A low confidence means the model is less sure, and the value may have been missed. The exception queue puts "required" ahead of the score: if the field list marks the field required and the extracted value is empty, the row enters the queue whether the confidence on that empty result is high or low. A high score only says the model thinks the document may not contain the value. A person still looks at the sample.
If the confirmer has looked at the sample and the document really has no such field, they write "not on the document" on that field and sign. That is a value. It does not turn a required field into an optional one. If the document has the value and the tool did not extract it, the confirmer writes the value read from the sample, and the original extraction stays in the log. What "required" means stays on the field list. It is not changed on this row.
Name who may change the extracted value
The person who may change a value is the confirmer already named on the field list. That person can open the sample for this document. If they cannot open it, someone who can open it makes the change, and the line says why the person changed. A change replaces the extracted text with the text on the sample, or records that the document does not contain the field. The confirmer does not edit master data unless they are also the owner of that master data, and the two roles are separate on the log.
A second person releases the row. The releaser decides whether this row may leave. The releaser and the confirmer may be the same person. The two lines stay separate, so a later check can see who changed the value and who let it leave. A person who is not on the list does not change a value and does not release a row. A sentence in the group chat that says "I fixed it" is copied into the log first. Without the log, the value has not been changed.
When the row conflicts with master data, name the record that was compared
A row that does not match master data enters the queue with the document id, the field name, the extracted value, which master record was compared, the value on that record, and the time. If the master record has no id, the id is added before the row is handed to the confirmer. The confirmer compares the sample with the extracted value. If the sample supports the extracted value and the master record differs, the outcome is "keep the extracted value; the master record is a separate check", with the name of the master-data owner. If the sample supports the master record, the extracted value is changed to the text on the sample.
Whether the master record itself should change is written by its owner on the master-data side. It is not edited inside the exception queue. Until one of those outcomes is written, the row stays. If the field list has not yet named the master data, the conflicting row waits until that name is added. See Which fields to define before document data capture.
Keep the value before, the value after, and the reason
Each log line holds the document id, the field name, the reason the row entered, the time it entered, the original extracted value, the confidence or "no score", who changed it, the value after the change, and the time of the change. The reason uses a name the queue rule already has: below the company's line, required field empty, or conflict with master data. A reason outside those three is added to the rule, with a date, before it is used on a row.
A new value with no previous value, or with no person, is not a finished change. If the same field is changed twice, both changes stay. The earlier one is not overwritten. The path of the log is written on the queue rule. If that path cannot be opened, the releaser does not release the row.
The row leaves when the releaser has signed
A corrected row leaves only when all of these are true: every required field has a value, or "not on the document" signed by the confirmer; the master-data conflict has an outcome; the log has the value before, the value after, the reason, and the time; and the releaser has signed and written the time. If one of those is blank, the row stays, with the status awaiting release. There are two ways out: write downstream, or return the document to its owner. A return is also signed, with the reason. A returned row is not written downstream.
What is written downstream is still only a confirmed field, and the target field name matches the list. How that write meets the system already in use is in Which fields to define before document data capture. A row whose score is above the company's line, whose required fields have values, and which has no master-data conflict may skip human review, and the log still keeps the score and "did not enter the queue". While the line has no date, that automatic path is not used. A row is marked as having left when three things are true: the reason has an outcome, the change is in the log, and the releaser or the person who returned it has signed.