WEMAIDE / INSIGHTS / ENGINEERING
AI document processing: turn extracted fields into a reviewable workflow
Plan an AI document-processing workflow with source evidence, field validation, human review and controlled export. Includes a synthetic invoice example and review checklist.
An AI document-processing workflow needs more than extracted JSON. It must connect each important value to the source document, check the value against the application's rules, route uncertain records for review and record what was exported. A plausible-looking result is not enough evidence to update a business record.
This guide uses a synthetic invoice to explain the design. It is not a client case, an accounting recommendation or a benchmark of an extraction provider. The intended result is a reviewable draft record; payment, tax treatment and other consequential decisions remain outside the example.
OCR, extraction and a completed process are different outputs
| Stage | Output | Still unanswered |
|---|---|---|
| OCR or text reading | Recognised text and available layout information | Which value belongs to which business field? |
| Structured extraction | Candidate fields, types and available source evidence | Are required values present and internally consistent? |
| Application validation | Rule results and review reasons | Should this particular version be accepted? |
| Human review | Corrected values and a recorded decision | Has the intended downstream write actually completed? |
| Controlled export | A confirmed target record or an uncertain outcome | Can an operator trace and recover the operation? |
Google Document AI offers processors for tasks including extraction, classification and splitting. The application still needs an explicit contract for the record it will accept. A document may contain several logical records or pages, so deciding what constitutes one business submission belongs near the start of the design.
Define the record and retain evidence for each critical field
For the example, an operator needs a draft supplier record with an invoice reference, date, currency and stated total. Preserve the original file identity and extraction version. For important fields, retain a source page or location supported by the chosen provider, the original text and the normalised candidate. Do not invent an evidence location when the provider did not supply one.
Illustrative review record — invented values
document_id: invoice-demo-0042
extraction_revision: 1
field: total
source_text: EUR 120.00
source_page: 1
normalised_candidate: { currency: EUR, amount: 120.00 }
validation: needs-review
reason: line-item reconciliation has not been confirmed
review_status: pending
export_status: not-attemptedA filename is not a sufficient record identity: the same file can be uploaded twice, and a revised document can reuse the same name. Keep an intake identity and a deliberate duplicate policy. A content digest can help identify identical bytes, but it cannot decide whether two similar documents represent the same business obligation.
Validate business fields independently of fluent model output
| Check | Example review reason | Do not assume |
|---|---|---|
| Required fields | The invoice reference is absent or unreadable | A model should fill missing values from intuition |
| Type and format | A date can be read in more than one order | Every locale uses the same date convention |
| Currency and amount | The currency is missing or amounts disagree | A visually similar symbol establishes the intended currency |
| Cross-field consistency | Line items and the stated total do not reconcile under the agreed rule | One universal arithmetic rule covers discounts, fees and all documents |
| Reference data | The proposed supplier does not match an authorised record | An extracted name grants permission to create or change an account |
| Document version | The source was replaced after review began | An earlier decision remains valid for a changed document |
Keep a distinction between a value that failed a rule and one that could not be checked. For example, a readable total with no available line items is not the same as a confirmed arithmetic mismatch. Route both according to the product's review policy, with different reasons visible to the operator.
Use confidence as an evaluated signal, not a universal permission score
Some extraction services return confidence at field or other supported levels. Microsoft documents both the available confidence signals and the need to evaluate performance for the customer's own use case. A model-generated sentence saying it is very confident is not a substitute for a provider's evaluated field signal or a business validation rule.
Do not copy a threshold such as 0.8 into every workflow. Build a labelled, representative test set, examine the important field errors and choose the handling policy for that task. For example, a readable description and an incorrect account identifier have different consequences. A high score should not bypass missing permissions or a failed required check.
Give the reviewer a decision they can actually make
Show the source alongside the candidate record, highlight the values needing attention and explain the failing or unavailable checks. Let the reviewer correct a candidate, reject the document or approve the current record for the stated export destination. Record the reviewed revision rather than attaching a timeless approved flag to the document's filename.
A correction should trigger the relevant validations again. Replacing the source, target organisation or important value should invalidate an earlier decision where it changes what was authorised. This is a recommended design for the example, not a feature attributed to every document-processing provider.
A reusable intake, field, review, export and evaluation checklist with a synthetic example. No upload or registration required.
Export one accepted record and handle an unknown result
Assign the accepted business operation its own identity and check that its reviewed revision is still current before exporting. Retain the downstream identifier on success. If the target accepts a write but its response is lost, record uncertainty and reconcile using the target's supported lookup or idempotency mechanism before repeating the write.
Provider-specific idempotency support must be checked rather than assumed. A unique key in your local database can prevent some repeated local work, but it does not make the external system part of the same transaction. Keep an operator path for unresolved records and separate export status from extraction or review status.
Measure the complete workflow on representative documents
Include the formats, languages, scan quality and document variations the workflow will actually receive. Keep labelled test material distinct from development examples, and track the processor or prompt version used. Google Document AI's evaluation compares predictions with labelled test documents and describes the precision/recall tradeoff as confidence thresholds change.
- Field quality: required-field omissions, wrong values and unsupported extracted claims.
- Review burden: how many records need a person, why they need review and time spent correcting them.
- Operational completion: confirmed exports, duplicate attempts and unresolved outcomes.
- Coverage: results by document type, language and scan quality, not only one pooled score.
- Cost: extraction, storage, integration operation and human review under the same workload assumptions.
A pilot is useful when it produces an observable answer about the whole job: which records can progress, which need a person and what the operator does when a step fails. Start with one document type and one controlled destination before expanding the number of formats and automated actions.
