Misreading a footer and misreading a payment account can each count as one extraction error. They do not have the same consequence. A financial institution evaluating document AI needs to know both how often the system is wrong and what happens when it is wrong.
That begins with the evaluation dataset. A collection of clean, familiar documents may produce an attractive score while saying little about an operating population that includes amendments, poor scans, handwritten changes and several languages. More documents help only if they add relevant variation and trustworthy reference answers.
Define the output before collecting examples
Specify the fields and relationships the workflow needs. An amount without a currency, reporting period or entity may not be a usable result. A covenant ratio without its definition may be misleading. Decide whether the system is extracting a printed value, calculating a value or interpreting an obligation. Those are different tasks and should not share an undefined success criterion.
For every field, define acceptable formatting and permitted normalisation. Removing thousands separators may be harmless when locale is known. Treating a comma as a decimal point when locale is uncertain can change the value substantially. A reference answer should record the source expression alongside the normalised output so that reviewers can distinguish recognition failure from transformation failure.
Google's Document AI evaluation documentation compares predicted entities against labelled test documents and reports precision, recall and F1. Precision asks how many predicted values match the annotations. Recall asks how many annotated values were found. These measures answer useful extraction questions, but the business still has to define what a correct annotation represents.
Represent the actual operating population
Sample by document family, issuer or counterparty, language, quality, format and source channel. Include both common documents and cases that drive exceptions. Track the sample composition so that a team can see whether difficult categories are improving or disappearing from the test set.
Hold out entire counterparties or document templates when assessing generalisation. Randomly dividing pages from the same repeated form between training and testing can exaggerate how well the system handles an unfamiliar source. A chronological holdout can also reveal whether changes in reporting formats create errors that an older sample misses.
Keep routine and stress evaluation sets separate but visible together. A stress set can deliberately contain a high proportion of damaged scans or unusual clauses. Its results should not be presented as the expected production error rate. Conversely, a frequency-weighted average should not erase a rare failure with a large financial consequence.
A hypothetical result with the wrong lesson
Hypothetical example: an administrator tests an extraction service on 1,000 invoices, each with ten scored fields. The system returns 9,900 correct fields out of 10,000. The advertised result is 99%. Ten of the errors concern beneficiary account numbers, while most of the remaining errors affect low-impact descriptions.
The aggregate is arithmetically correct and operationally incomplete. It does not show whether account errors would be caught by a verified beneficiary register, whether they occurred on a particular layout or whether the documents would have passed unattended. The material question is the rate of dangerous errors that survive the entire control path.
The administrator separates account details, currency and total payable into critical fields. It requires an independent match before payment preparation and measures the share of documents that can complete that check automatically. A lower automation rate may be acceptable if it prevents unsupported beneficiary changes. The commercial benefit must be calculated using that lower rate.
Annotators need a way to disagree
Reference data is not automatically correct because a human entered it. Use clear annotation guidance, independent review for consequential fields and an adjudication process for disputed cases. Preserve uncertainty where the source itself is ambiguous. Forcing a single answer onto a genuinely unresolved clause makes the benchmark less truthful.
Version the labelled dataset and record corrections. If a model flags an error in the reference answer, fix the evidence and rerun affected comparisons rather than quietly replacing the label. Otherwise later reviewers cannot explain why a release's reported performance changed without a change to the model.
Protect confidential documents in the evaluation environment. De-identification can be useful, but substitutions should preserve the difficulty being tested. Replacing every irregular account or entity name with an obvious placeholder can remove the very recognition problems the institution needs to measure.
Confidence is an input to review policy
Amazon Textract's best practices advise considering confidence scores alongside the sensitivity of the use case and escalating low-confidence results. A provider score can help route work. It should be tested against the institution's own labelled population before it becomes the basis of an unattended decision.
Measure errors among accepted results, not just across all results. Raising a threshold may reduce incorrect accepted values while increasing the review queue. The relevant operating picture includes accepted-error rate, referral rate, reviewer time and the age of outstanding work. A threshold is useful only if the receiving process has capacity.
Do not assume a single threshold suits every field. A mildly uncertain merchant description and an uncertain currency code carry different consequences. Use deterministic cross-checks where possible, such as reconciling line items to a total or comparing an extracted identifier against an approved record. Passing a consistency check does not prove the underlying document is authentic.
Include absent fields deliberately. A document that omits a maturity date should not receive a fabricated one merely to satisfy the output schema. Score unsupported completion separately from missed extraction, because the two failures call for different remediation.
Report severity without hiding the raw results
A materiality framework can classify errors by likely consequence: presentation, reconciliation, client reporting, exposure measurement or movement of funds. Record the reasoning for the classification. The same numerical error may be tolerable in a research draft and unacceptable when it feeds an instruction.
Severity-weighted scores can help prioritise remediation, but publish the underlying counts and category results as well. A weighted average can become another opaque headline if weights change between releases. Show whether a failure was caught by the model, a deterministic control or a human, because those layers have different costs and dependencies.
Review the full document outcome alongside field scores. A document that needs one critical correction still requires intervention even when its other fields are perfect. For staffing and turnaround commitments, the proportion of documents requiring attention can matter more than the proportion of fields extracted correctly.
This extends the reasoning in AI inference verification and procurement: execution evidence and fitness for purpose answer different questions. The record discipline in digital assets in financial statements is relevant too. Financial outputs need traceable support, and automation does not change the consequence of an unsupported number. The release decision should identify which errors remain, which controls catch them and who owns the residual cases.