Do Not Let Document-Reading AI Decide When a Value Is Final

Consider a process that uses generative AI to read a supplier quotation and register it in an internal system. The amount and date are entered in the required fields, and the screen looks complete. But what if the amount is in thousands of yen and the date is the validity deadline rather than the quotation date? At what point would anyone catch that?

This article recommends not treating an AI reading result as a confirmed value. Separate “the value taken from the original,” “the value converted for business use,” and “the value that passed validation.” What must be decided first is not how the output looks, but what evidence is required to accept each field.

Separate reading from business conversion

RICOH says it implemented “Adaptive AI-OCR,” which converts reading results according to processing rules for a company or individual operator, in its received-invoice and received-delivery-note services. [1] OCR (optical character recognition) is technology for reading characters in images and similar inputs. [4] The company cites processes such as extracting part of an identifier and converting a Japanese era date to a Western calendar year. [1]

The current service explanation also says that users’ correction histories are fed into generative AI to produce outputs tailored to processing rules. [4] Both statements are from the provider and should not be treated as independent evidence of customer savings.

The distinction to consider is between accurately transcribing text and changing it into a value for business use. For example, removing leading digits might preserve a partner’s identifier accurately while making it inconsistent with your own registration rules. A test that compares only the final value cannot identify whether the reading or conversion was wrong.

At design time, keep the original string, converted value, applied rule, and supporting page or location separately. If the converted value is populated even though the original was not read, route it for review instead of confirmation. If AI is also asked to provide an evidence location, validate whether the cited location actually contains the relevant entry.

A correctly shaped output does not mean the value is semantically correct

Structured output is a way to receive responses in a defined format, such as specified field names and data types. [2] Google’s official Gemini API documentation describes outputs that follow a JSON Schema, while also requiring the application to validate values even when the JSON syntax is valid. [2] It explicitly addresses outputs that are well-formed but semantically incorrect. [2]

Turn this distinction into business acceptance criteria. For an amount field, check not only that it is numeric but also the currency, unit, and whether tax is included. For a date field, define whether it means the issue date, validity deadline, or delivery date, rather than checking only whether it can be read as a date.

For example, if a hypothetical input says “amount 12, unit: thousand yen” and is converted to yen, the candidate value is ¥12,000. The value 12, after losing its unit, is still a valid number. Tests should compare converted results including units, rather than relying only on string matching.

Handling blanks is also part of the specification. Do not collapse “not stated,” “characters unreadable,” “multiple candidates,” and “not applicable” into one blank field. If an unstated amount is filled with zero, it becomes impossible to distinguish “not verified” from an amount of zero. Design both a format that permits an empty value and the reason it is empty.

Which parts to delegate to AI and which to validate with fixed rules

There are three options: let AI handle extraction through correction, use only fixed rules, or combine the two. This article favors using AI to read the wording on documents while executing established conversion rules and matching conditions in ordinary software.

For example, check whether a department code is registered, whether a period’s start date precedes its end date, and whether a line item is duplicated. If reconciling totals, agree on calculation rules—including discounts and rounding—with the business side before implementation. If you call a difference an error before the rules are settled, the design asks reviewers to make corrections without a basis.

If everything is delegated to AI, the challenge is how to evaluate both extraction and validation results. Do not treat explanations generated by AI as proof that a value is correct. Conversely, if a new rule must be added whenever formats or wording change, compare the ongoing work required and decide who will maintain it.

If the required fields can already be received as structured data, consider direct integration before converting them into document images and having AI read them again. Do not make AI adoption an end in itself; prefer a path where both parties can agree on the transferred values and what they mean.

Do not make a confidence threshold the only condition for confirmation

Microsoft’s official Document Intelligence documentation explains that the service returns estimated confidence for extracted fields, but not every field has a confidence score. [3] It also says confidence for a cell and for a row may differ: a table cell may be correct while the row may still have been missed. [3]

Therefore, before setting a single threshold for an entire document, decide which fields will be judged and at what level. Do not treat a field with no confidence score as automatically safe. Handle value format, evidence location, business consistency, and confidence level when available as separate conditions.

Do not set acceptance criteria using only easy-to-read documents. Include test cases where the unit is outside the field, line items span pages, vendor names are similar, before-and-after corrections appear together, or required fields are absent. Keep a separate set of documents for testing after the criteria are finalized, apart from those used for tuning.

For tests, report not only the share of fields read, but also the number of incorrect values that passed to the confirmation candidates and the number sent for review. More reviews increase frontline workload. Conversely, if criteria are relaxed to reduce review, state explicitly which types of errors are being accepted.

Make confirmation criteria an artifact business teams can update

On the review screen, show the extracted value alongside the relevant original text, conversion, and reason it failed a condition. When an operator corrects a value, record whether it was a reading error, a gap in the conversion rule, or a contradiction in the document itself. Distinguish what was corrected before feeding corrections back into learning.

In Forward Deployed Engineering (FDE)—working with the customer from planning and prototyping through implementation and adoption—make a field definition table a shared deliverable for the business and development teams. Record each field’s meaning, evidence, conversion rule, missing-data handling, confirmation criteria, and the owner responsible for changing those criteria. When the model or instructions change, recheck using documents held back for that purpose.

This approach is unsuitable when the original cannot be checked, or when even the business team cannot define what a field means and what the correct value should be. In that state, it is impossible to design conditions for confirming AI output as a business value. Start by reviewing document intake or the definitions of input fields.

Practical implications

Recommendation 1: Decide each field’s meaning and missing-data handling before prototyping. For an amount, define its unit and currency; for a date, identify which date it represents, with examples of expected outputs.

Recommendation 2: Pass the original, converted value, and validation result separately. Do not make a value final in the business system merely because it arrived in the correct format.

Recommendation 3: Assess the number of incorrect values that pass and the number routed for review side by side. Set automation scope based on the conditions reviewers can handle, not on how polished the output looks.

References

1. RICOH, “Develops Adaptive AI-OCR to Optimize OCR Results for Each Company’s and Operator’s Form Processing Rules” (2025-05-08, press release at publication; checked 2026-09-23)
2. Google, Structured outputs (2026-09-17, current HTML, no version number; checked 2026-09-23)
3. Microsoft, Interpret and improve accuracy and confidence scores (2026-04-08, Document Intelligence v4.0, API 2024-11-30 GA; checked 2026-09-23)
4. RICOH, “Further Advancing AI-OCR with Generative AI” (publication/update date unknown, current HTML, no version number; checked 2026-09-23)

This article was created with AI assistance and automatically reviewed before publication. Information checked on: 2026-09-23.