AI-OCR Comparison: RFP and PoC Guide for Thailand

An AI-OCR comparison should not answer only which product reads the cleanest demo page. For a manufacturer in Thailand or ASEAN, the real question is which approach can transfer required fields from invoices, purchase orders, inspection forms and delivery notes into business systems, return exceptions safely to people, and remain economical in operation. This guide shows how to compare four document-processing patterns with the same documents, scoring logic, RFP, PoC and FAT/SAT evidence.

The answer: compare business output, not a headline OCR accuracy rate

A feature matrix built around file formats, a displayed recognition percentage and API price will hide important differences. One incorrect character in an invoice number can break matching. An incorrect tax amount or currency that is automatically posted can affect accounting. By contrast, agreed normalisation may safely absorb whitespace or character-width differences in a company name. A single character-level average cannot represent these business consequences.

Change the unit of comparison from an OCR engine to the complete flow from intake through extraction, validation, review, export and evidence. Divide the candidates into four patterns:

1. OCR or read-only text extraction.
2. Prebuilt document, form or table extraction.
3. Customer-specific, deterministic custom extraction.
4. Generative or multimodal document understanding with grounded output and human review.

Score critical-field correctness, false auto-accepts, straight-through processing, manual review, unresolved cases, duplicate/export errors, cycle time, language and layout fit, evidence, change resilience and total operating cost. There is no universally winning pattern. The appropriate option is the one that meets the customer’s agreed gates on a frozen, representative test set.

Four solution patterns for an AI-OCR comparison

The label “AI-OCR” can cover a service returning words and coordinates, a prebuilt invoice model, a trained custom extractor, or a generative model interpreting varied documents. They may appear adjacent in a proposal, but their output, implementation work, behaviour under change and evidentiary strength differ.

Pattern 1: include downstream logic in a read-only OCR quote

Read-only OCR returns page text, lines, words and positions. Its unit price may be low, but someone still has to classify the document, decide which text is the invoice number, reconstruct tables, normalise values, validate them and integrate the result. It can be flexible where layouts are stable and the customer owns mature rules. The OCR call alone is not the finished system.

As accessed on 2 September 2026, Google Cloud’s public pricing page lists the first 0–1,000 Enterprise Document OCR pages as free, then the 1,000–5,000,000-page tier at USD 1.50 per 1,000 pages. AWS Textract’s official US West (Oregon) example lists Detect Document Text at USD 0.0015 per page. These are dated public references, not customer quotations. Region, tier, feature, contract, tax and currency can change them, and they exclude some combination of classification, field mapping, review, storage and integration.

Pattern 2: test required fields, not merely available fields

Prebuilt invoice, form or table models return vendor-defined structured fields and can shorten initial implementation. They may not cover a Thai tax-document field, an internal supplier code, PO matching, line-level requirements, stamps or mixed-language tables exactly as required.

Azure’s current model-selection guide positions Document Intelligence for high-volume, deterministic extraction from structured and semi-structured documents, while Content Understanding targets more varied or multimodal content and inferred or generated fields. This is the vendor’s product-positioning guide, not an independent benchmark. The RFP should therefore freeze the quoted model, API version, region, language and output schema rather than relying on a product-family name.

Pattern 3: measure custom extraction maintenance and retesting

Custom extraction based on labelled records, templates or rules can be reproducible for proprietary inspection forms, labels or supplier-specific purchase orders. Its cost moves into labelling, configuration, new supplier onboarding, layout-version changes, retraining and regression testing.

A one-time PoC score is not valid if training and acceptance records are mixed. Separate training, tuning and final acceptance data. Keep final records blind or held out from tuning. Ask how many labels and how much effort a new layout requires, who performs that work, how a model change is tested, and whether the previous version can be restored.

Pattern 4: contract grounding and review for generative document understanding

Generative or multimodal models can help classify unusual documents, combine context across locations, and suggest fields when labels vary. They also introduce the risk of plausible but unsupported values, output variability, model changes, latency and difficult explanations.

Specify whether a missing value must be null or may be proposed as an inference. Link every critical output to the source page, region and original text. Validate supplier, PO, currency, tax and total with master data and deterministic equations. Grounding failure or a rule conflict must route to review. Language ability must not be treated as permission to post directly into an accounting system.

Freeze a representative document test set

Fairness depends more on the test set than the brochure. If vendors choose only favourable records or demonstrate clean native PDFs, rankings can be manipulated. Build a versioned, hashed and frozen set reflecting actual variation.

Stratify it by:

• Document type: invoice, purchase order, delivery note, inspection form, receipt and label.
• Issuer: major, low-volume and new suppliers, customers and internal sites.
• Language: Thai, English, Japanese, Vietnamese and mixed pages.
• Capture: native PDF, scan, phone photograph, e-mail attachment.
• Pages: single, multi-page, continuation, missing and out of order.
• Layout: current, old, shifted and line items continued on another page.
• Notation: handwriting, stamps, corrections, notes, vertical text and unusual symbols.
• Defects: blur, noise, darkness, faint or small text, cutoff, glare and skew.

Google Enterprise Document OCR offers optional image-quality analysis with a score from 0 to 1 and flags including blur, noise, darkness, faint text, small text, cutoff and glare. Google also notes possible false positives and limitations with local glare. This quality signal is not business accuracy. It can be used at an intake gate to separate capture problems from extraction problems.

Include both frequent cases and rare, high-impact cases: non-THB invoices, negative lines, multiple POs, handwritten corrections and mixed tax treatment. One operational set can mirror production distribution while a separate risk set over-samples dangerous boundaries. Report both, so a strong average cannot conceal a critical failure.

Double-check the ground truth

If the labelled truth is wrong, a correct output is scored as an error. Have one person label, another compare it with the source, and a process owner resolve disagreement. The data dictionary should define names, types, required/optional status, repeated fields, nulls and line boundaries.

Define normalisation before scoring. For identifiers, decide whether to preserve leading zeros, remove spaces or hyphens, and match case. For amounts, define decimals, rounding, separators and negative notation. For dates, define day/month order, Buddhist/Gregorian year conversion and ambiguous dates. Changing a rule after results arrive destroys reproducibility.

Measure AI-OCR accuracy by field and process

A claim such as “99% accuracy” does not reveal the denominator, documents, failure exclusions or critical errors. Make character accuracy secondary to business-field and document-flow measures. Our related AI-OCR accuracy guide provides additional detail.

At minimum report field exact match or precision/recall, document straight-through-processing rate, false auto-accept rate, manual-review rate, unresolved rate, duplicate/export error rate and end-to-end cycle time. Do not remove processing failures from the denominator and then advertise accuracy only on returned fields.

Azure’s official accuracy and confidence guide describes confidence as an estimated probability and shows low-confidence fields being routed to human review. It also recommends representative visual and layout variation in training and evaluation. A 0.90 score from vendor A is nevertheless not inherently equivalent to 0.90 from vendor B. Calibrate confidence bands against actual correctness on the same labelled customer set before choosing thresholds.

A high-confidence wrong answer is especially dangerous because it can bypass review. Combine confidence with deterministic checks such as subtotal plus tax equals total, supplier/currency agrees with the PO, and line totals agree with the header. A confident output that conflicts with a rule should not auto-post.

Verify multilingual fit at model and feature level

Google’s Document AI processor list says Enterprise Document OCR is generally available and supports more than 200 languages, including printed Japanese, Thai and Vietnamese. Generic character support does not prove reliable field extraction from a customer’s invoice, handwritten form or mixed-language table. Demand evidence on customer records.

Amazon Textract’s official limits list English, French, German, Italian, Portuguese and Spanish as supported text-detection languages, with handwriting recognition limited to English. This is an early fit gate when Thai, Japanese or Vietnamese documents are in scope. The same documentation says synchronous PDF/TIFF processing supports one page with a 10 MB in-memory limit, while asynchronous PDF/TIFF supports up to 500 MB and 3,000 pages. Test real size, page count, latency and asynchronous integration.

Azure’s Document Intelligence What’s New page lists Thai and Vietnamese locales for the invoice model and Thai and Vietnamese currency codes. Availability must still be verified for the quoted model/API version and region. “Multilingual product” is too broad an answer; obtain feature-level proof.

Convert AI-OCR pricing into monthly TCO

Public API price matters, but it is one part of the operating model. Use a common equation:

Monthly TCO = API/processor fees + capture/classification + storage/network + integration/monitoring + model/template maintenance + human review + error correction/reprocessing + security/compliance operations.

As accessed on 2 September 2026, Google’s public page lists Form Parser and Custom Extractor at USD 30 per 1,000 pages for the first million pages and Layout Parser at USD 10 per 1,000. AWS’s Oregon examples list Forms at USD 0.05 per page and Tables at USD 0.015 per page for the first million pages; an example using both includes both feature charges. These prices do not promise equivalent output scope. Record date, region, feature combination, tiers, tax and quotation assumptions. Do not convert them into THB without stating an exchange-rate assumption.

Hypothetical internal calculation

The following is an illustrative design model, not a market average or provider quote.

• Volume: 50,000 pages/month.
• Manual baseline: 3 minutes/page at THB 180/hour.
• Baseline labour: 50,000 × 3 ÷ 60 × 180 = THB 450,000/month.
• Option A: 60% straight-through; the remaining 40% reviewed at 1.5 minutes/page.
• Option A review labour: 50,000 × 40% × 1.5 ÷ 60 × 180 = THB 90,000/month.
• Option B: 80% straight-through; the remaining 20% reviewed at 1.5 minutes/page.
• Option B review labour: 50,000 × 20% × 1.5 ÷ 60 × 180 = THB 45,000/month.
• Review-labour difference: 90,000 − 45,000 = THB 45,000/month.

If error/rework and risk are equal, a platform premium below THB 45,000/month for Option B may be economically rational. If Option B has more false auto-accepts, greater maintenance or slower peak processing, recalculate. This example does not establish a universal payback period.

Measure review time from opening the case through comparing the source, correcting it and resolving an ERP error. Reducing the number of review cases can leave only complex cases and increase minutes per case. Separate one-time implementation, migration, training and parallel-run costs from steady-state monthly costs.

Attach a reproducible scorecard to the RFP

A weighted score helps structure a decision, but must not average away a severe failure. Apply mandatory gates first, then score passing candidates. The following are proposed acceptance design examples, not external benchmarks.

Illustrative mandatory release gates

• Zero critical wrong auto-posts in the frozen acceptance set.
• Every low-confidence or business-rule conflict is routed to review.
• Every exported record retains a link to source page and field evidence.
• Duplicate submission is idempotent and does not create a second record.
• Human corrections, model/configuration version and retest result are traceable.
• Mandatory language, file, page and region requirements are met.

“Zero” applies only to the customer’s finite frozen acceptance set. It does not statistically guarantee zero production defects. Phased rollout and monitoring remain necessary.

Link each score to test-case IDs, logs, screens, API output and quotation lines rather than sales prose. Normalise vendor-specific outputs into one schema and retain raw measurements so weights can be changed later. Showing open questions and disqualification conditions is more useful than presenting a falsely precise decimal ranking.

What an AI-OCR implementation RFP should contain

The RFP is a specification for comparable tests and operations, not merely “Can you read our invoices?” Include:

1. Document inventory: type, version, issuer, language, volume, peak and pages.
2. Intake channels: e-mail, shared folder, scanner, phone and API.
3. Output schema: fields, types, required status, normalisation, tolerance and lines.
4. Downstream systems: ERP, accounting, purchasing, quality and DMS boundaries.
5. Exception flow: reviewer, displayed evidence, correction and return path.
6. Data constraints: location, encryption, access, retention, deletion and training use.
7. Evidence: source, region, value, confidence, rule, correction and export ID.
8. Non-functional needs: throughput, peak, response, availability, monitoring and support.
9. Change control: model/API version, notice, regression and rollback.
10. Commercial model: units, minimums, add-ons, support, review and environments.
11. PoC terms: frozen data, scorer, blind/held-out split, period, deliverables and gates.
12. Exit terms: return and deletion of data, configuration, labels and logs.

Prohibit hand-picking only clean documents and require customer-selected blind or held-out records. Transform all outputs into a common JSON or CSV schema and rerun the same scorer. This is more reproducible than having different reviewers judge each vendor’s own interface.

For the deployment team, phased rollout and operational responsibilities, see our AI-OCR implementation guide. The comparison scorecard in this article can become its selection and acceptance workstream.

Make the PoC demonstrate failures, not only happy paths

A PoC should prove that the system stops safely, preserves evidence and recovers. Require demonstrations of:

• Capture failure such as blur, cutoff or glare returning to recapture.
• Unsupported language or unknown layout being rejected rather than forced into fields.
• Continuation pages, missing pages and page reordering.
• Duplicate submission without duplicate export.
• Timeout, partial success and rate limit followed by safe retry.
• Supplier, PO, currency or total conflict routed to review.
• Human correction with value, reason, user and time recorded.
• The same frozen set rescored after model/API version change.
• Rollback to a prior version or manual route after regression.

Trace input ID, dataset version, model/configuration version, timing, output, rule result, review and final record ID. Screenshots alone are not reproducible; require machine-readable output and scoring results.

Separate FAT and SAT

FAT validates extraction, rules, APIs, evidence and failure cases in a controlled environment. SAT validates identity, network, real scanner/e-mail/file intake, ERP/API integration, operational review, monitoring and backup in the customer environment.

The same PDF can pass FAT while scanner resolution, file names, latency, service-account permissions, ERP master data or reviewer availability change the SAT result. Include peak load, partial outage, overnight processing and manual fallback in site testing.

Keep the frozen set after acceptance. Rerun relevant cases when the model, template, rule, scanner or ERP schema changes. Place new document layouts in review-only mode until enough evidence supports expanding automation. Record which version and test result authorised each expansion.

The broader lifecycle from paper receipt to retention and disposal is covered in our paper-document digitisation guide. Changing OCR alone does not complete the process when scan quality, source custody, correction authority and retention are undefined.

Turn evaluation results into an approval and contract

A technical scorecard alone does not give management an investment case or procurement an enforceable scope. Connect the selected pattern, business effect, residual risk, operating ownership, cost assumptions and release conditions in one decision record.

First, state the process boundary in one sentence. For example: “Extract header and line fields from invoices e-mailed by designated suppliers to the Thailand plant; validate PO, supplier, currency and amount; place only non-conflicting records in an ERP-ready queue; accounting personnel retain final posting authority.” Define the automation denominator as all received files, classified in-scope documents or complete documents, and report excluded files with reasons.

Second, approve severity before testing. Give examples for minor, correctable, critical and release-stopping errors. Whitespace may be minor, while a wrong entity, currency, duplicate record or unsupported value without source evidence can be critical. Business, accounting, quality, IT and security owners approve their stop conditions, with a named adjudicator for disagreements.

Third, keep an evidence register that distinguishes vendor claim, configuration inspection, PoC measurement, contract commitment and unverified status. A language on a support list is not customer-field accuracy. A deletion button is not a contractual deletion time covering backup and logs.

Treat “unverified” separately from a low score, because inability and missing evidence require different action. Assign owner and due date for items to close before contract and those allowed to close at SAT.

Fourth, run sensitivity analysis. A weight is an expression of priorities, not a physical constant. If changing field accuracy from 25% to 35%, or three-year TCO from 15% to 25%, reverses the ranking, present a conditional recommendation rather than a universal winner. Calculate low, base and high cases for page volume, review minutes, exchange rate, supplier growth and reprocessing.

Fifth, retain rejection reasons as well as the selection. Record the dataset version, failed field or gate and condition for reconsideration. Put limits on the selected option too: for example, printed Thai invoices may enter an auto-post candidate queue, handwriting always goes to review, an old Vietnamese layout remains out of scope, and each new supplier stays review-only for an observation period. Selection authorises a tested scope, not the entire product.

Finally, connect payment milestones to acceptance evidence and deliverables: data dictionary, common schema, labelling policy, test-set version, scorer, complete results, exceptions, operating procedure, monitoring, incident procedure and regression method. Avoid incentives to overfit the disclosed acceptance set; confirm that the same processing rules work on held-out records. Procurement, legal and information-management teams should verify final contractual terms against applicable rules.

The scorecard then becomes a durable decision record: what scope was authorised, by whom, with which evidence and residual actions. New layouts and renewals can be assessed as controlled changes rather than restarting the debate.

Twenty evidence-based vendor questions

1. Which quoted pattern is read-only, prebuilt, custom or generative?
2. What model, API version, region, language and sync/async limits apply?
3. Can each value be traced to its page and source region?
4. Does a missing value return null or an inferred proposal?
5. What does confidence represent and how is it calibrated on our set?
6. Can deterministic business rules block confident but wrong output?
7. How will mixed Thai, Japanese, English and Vietnamese be tested?
8. What are the conditions for handwriting, stamps, corrections and multi-page tables?
9. How are capture failures separated from extraction failures?
10. Will you accept customer-selected blind/held-out PoC records?
11. Who owns training data, labels, configurations and prompts?
12. What time and cost are required for a new supplier or layout version?
13. How do retries remain idempotent after partial success?
14. Does review show source, value, evidence and rule conflict together?
15. Are corrections retained and reusable for regression tests?
16. What are the storage, location, retention, deletion, training-use and subprocessor terms?
17. Which classification, storage, monitoring and support costs are outside the quote?
18. How and when are model or service changes notified?
19. What are manual fallback, recovery objective and rollback arrangements?
20. At exit, in which format are data, logs, settings and labels returned?

Replace “supported” with a model, condition, test result, limitation and price. A feature may exist but not in the quoted region or plan. Decide in advance whether an unanswered item fails, scores zero or remains a PoC action.

FAQ about AI-OCR comparison, pricing and accuracy

What should be prepared before comparing AI-OCR vendors?

Prepare a document inventory, required-field schema, frozen test set, verified ground truth, normalisation rules, error severity and exception flow before the vendor list. Otherwise each provider can demonstrate a different sample and metric.

What AI-OCR accuracy percentage is sufficient for production?

There is no universal threshold. Measure supplier, invoice number, currency, tax and other fields separately and track false auto-accepts. Low-confidence review alone does not catch high-confidence errors, so add business-rule validation.

Can AI-OCR pricing be compared using API price alone?

No. Include capture, classification, storage, integration, monitoring, maintenance, human review, rework and security operations. Record exchange rate and date for conversions and verify that compared calls provide equivalent scope.

Is generative document AI always better than traditional OCR?

No. It can help with varied documents and context, while prebuilt, custom or rule-based extraction can be more predictable for strict stable schemas. Compare grounding, inference errors, review, latency and TCO on the same set.

How many documents are enough for a document OCR PoC?

There is no universal count. Coverage of suppliers, languages, layouts, capture defects and high-risk exceptions matters more than a headline total. Report uncertainty and untested conditions, and collect more records for sparse strata.

Is high confidence enough to auto-post?

Not until confidence is calibrated on the same labelled set and critical errors are examined. Confidence is not business accuracy and cannot be compared directly across vendors. Combine it with master-data, arithmetic and duplicate checks.

Does Thai-language support prove fit for Thai invoices?

It is only a starting point. Printed OCR, handwriting, prebuilt invoice models, tables and mixed language can have different coverage. Freeze the model, version and region and test actual Thai fields.

What is the difference between FAT and SAT?

FAT tests extraction, rules, APIs and evidence in a controlled environment. SAT tests identity, network, real capture channels, ERP integration, reviewers and monitoring in the customer environment. Both are needed to bridge demo accuracy and production operation.

Summary: same documents, same scorer, same gates

An AI-OCR comparison should centre on frozen customer documents and end-to-end outcomes, not a brochure recognition rate or minimum API fee. Compare OCR-only, prebuilt, custom and generative document understanding against critical fields, false auto-accept, review, unresolved cases, evidence, integration, change and monthly TCO.

Put the common schema, blind/held-out set, mandatory gates, pricing assumptions, failure demonstrations, FAT/SAT and exit terms in the RFP. Treat internal thresholds as customer-specific design assumptions, never as universal benchmarks. The result is a procurement decision backed by reproducible evidence rather than PoC impressions.

TOMAS TECH can help manufacturing teams in Thailand create a document inventory, comparison scorecard, RFP and PoC acceptance package before a product is selected. If you are still defining required fields and exception flows, contact us to discuss the evaluation design.

References

• Google Cloud Document AI pricing (accessed 2 September 2026)
• AWS Textract pricing (accessed 2 September 2026)
• Azure Document Intelligence: Choose a model or feature
• Azure Document Intelligence: Accuracy and confidence
• Google Document AI processor and detail list
• Google Enterprise Document OCR
• Amazon Textract quotas and limits
• Azure Document Intelligence: What’s new