When an accounts payable team at a Thai factory receives supplier invoices as PDFs, email attachments, paper and electronic documents, the first problem is rarely whether software can read the characters. The hard questions are whether the same invoice arrived twice, which ERP supplier record it belongs to, whether its totals make sense, who resolves a discrepancy, and who may approve an AP posting. OCR without those decisions can fill fields while leaving the approval queue just as crowded.
This guide covers supplier invoice intake, extraction, validation, exception queues and the ERP posting gate as one operating design. Our earlier guide to invoice processing automation examines the overall business case and three-way matching. Our purchase order OCR guide focuses on capturing the PO itself. Here the focus is the quality and control of the invoice record between receipt and ERP posting.
Define the output as a postable invoice record
OCR text is not an AP voucher. A usable record needs a link to the original document, supplier master code, invoice number, dates, currency, tax treatment, header and line amounts, related PO and goods receipt where applicable, an approval trail and validation results. A correctly read amount is still unsafe if the currency or legal supplier is unclear. Define “capture complete” as passing the required checks and resolving the exceptions that block posting, rather than merely populating fields.
The ERP voucher number is the proof of a successful posting. Sending an API request is not the same as posting: a timeout can hide a successful operation, and an unguarded retry can create a second voucher. Store the original file without overwriting it. Keep receipt channel and time, a document fingerprint, the extraction version, human corrections, reviewer and decision history. This allows an auditor to distinguish what the invoice showed from what the business decided to post. Agree retention and tax treatment with the responsible local professionals.
Bring every intake channel into one controlled queue
Suppliers may use a shared mailbox, an employee’s inbox, paper, a portal or EDI. Assign an official receiving point and owner to each channel. A personal mailbox creates gaps during leave or staff changes. Paper scanning should record who scanned the document and when; the original paper’s storage rules remain a separate question. A message might contain an invoice, a delivery note and a payment instruction, so classify attachments before creating an invoice candidate. Do not create an AP voucher at this stage.
Reject password-protected or damaged files, missing pages and scans too poor to read into an intake exception path. Detect exact resends with a file hash. Detect altered-format resends with a candidate match on supplier, invoice number, date and amount. A hash alone misses an invoice printed and rescanned; an aggressive number-only rule can wrongly block a legitimate invoice when a supplier reuses numbers. Separate confirmed duplicates from similar documents requiring human review. Repeat the duplicate check immediately before posting and use an idempotent external reference on the ERP request.
Work backward from the ERP’s required fields
List mandatory, optional and calculated AP fields in the actual ERP configuration. Typical candidates include supplier, invoice number, invoice date, due date, currency, net amount, tax, gross amount, item, quantity, unit price, PO number and cost center. The factory’s own ERP configuration decides which are required. Evaluate extraction by field and line-item completeness, not by a single character accuracy percentage. Include wrapped descriptions, multi-page tables, discounts shown as negative values, freight lines and units that differ from the PO.
Amazon Textract’s AnalyzeExpense documentation describes standardized invoice and receipt fields, line items, locations on the page and confidence values. Google Cloud Document AI lists an Invoice Parser for header and line-item fields. Neither product description proves suitability for a particular supplier’s Thai, Japanese or mixed-language forms. In particular, the currently published Google processor list specifies supported languages and versions; verify the relevant version and run a trial with real documents before claiming Thai or Japanese support. A normalization layer is still needed to turn an extracted name, date, amount or currency into the ERP’s codes and formats.
“ABC Co., Ltd.” and “ABC COMPANY LIMITED” may be the same vendor, but name similarity alone is not a safe way to choose a legal supplier. Compare available tax identifiers, addresses and approved master data. Send ambiguous matches to an exception queue. Store confirmed aliases only with an approval trail, and separate master-data change rights from invoice approval rights. Keep the original text, proposed normalized value, confidence and page coordinates so a reviewer can see the source of a disputed field. After a model update, preserve which model version produced an earlier result.
Line items cannot disappear behind a correct grand total
A factory invoice may combine parts, quantities, unit prices, discounts, freight and tax on several pages. If purchasing must allocate each line to a PO, extracting only the grand total does not complete the job. Measure “line captured” separately from “line mapped to PO.” Keep ambiguous columns visible. A clearly read “1,250.00” still needs context to determine whether it is quantity, price or amount. Let reviewers inspect the highlighted location on the original page instead of asking them to trust a bare value.
Apply four layers of validation after OCR
A confidence threshold is a useful routing signal, but it does not prove business correctness. The document can be legible and still name the wrong buyer. Build rules in four layers:
| Layer | Question | Typical next action |
|---|---|---|
| Document | Is the file complete, readable and the right document type? | Request a new file or scan |
| Field | Are mandatory values present and formats valid? | Inspect the original and correct the field |
| Arithmetic | Can line amounts, tax and total be reconciled? | Review rounding, discounts and freight |
| Business | Are supplier, PO, receipt, approval and duplicate checks satisfied? | Route to the accountable team |
Do not apply one tax rate mechanically to every invoice. Tax treatment, rounding and allocation may differ by transaction. A difference should first be explained and classified; set auto-accept tolerances only after accounting approves the rule. For business validation, check supplier status, PO existence, received quantity, account assignment and approval limit. A no-PO service invoice or advance payment needs its own route rather than being forced through a parts-invoice three-way match. A bank-account change printed on an invoice must never silently rewrite the supplier master.
Make the exception queue a place to resolve work
“OCR failed” is too broad a reason code. Distinguish missing pages, missing mandatory fields, unrecognized supplier, suspected duplicate, arithmetic difference, PO mismatch, receipt not completed, approval pending and ERP rejection. Each exception needs its invoice ID, failed rule, highlighted source region, proposed value, accountable role, due date, conversation and correction history. After a correction, rerun the related arithmetic and business rules. Do not offer a button that bypasses all checks simply because someone edited a field.
Route supplier identity to purchasing, receipt quantity to the warehouse, tax classification to accounting and ERP API rejection to IT, while retaining one overall AP owner. Make the next action explicit. “Waiting for supplier” should include when the resend was requested and how long it has been outstanding. Prioritize by payment deadline, close calendar, production impact and duplicate risk rather than amount alone. A notification should explain what failed and what evidence resolves it.
Exception rate is a process signal, not just a score for the extraction model. High volume may come from supplier formats, missing PO numbers, delayed receiving entries, incomplete aliases or unapproved tolerances. Review exceptions by reason, supplier and purchasing department. Avoid lowering thresholds merely to improve a dashboard: also monitor post-posting corrections, payment reversals and the age of unresolved items.
Use three ERP gates: before, during and after posting
The pre-posting gate confirms original-document linkage, mandatory fields, duplicate status, approval, accounts, tax and the relevant PO or receipt. Transform values to valid ERP master codes and formats, then lock the version being submitted. During posting, send a stable external invoice ID if the ERP supports one. If the API times out, query the ERP by that ID before retrying. Where the ERP has no native idempotency key, persist the integration state and provide a reconciliation step instead of blind resends.
After submission, record the voucher number and final status returned by ERP. If ERP processing is asynchronous, follow it to the final result. Return a rejection to the exception queue with an actionable reason. Keep the relationship between an original voucher, cancellation and repost. This is how a team measures “registered correctly in ERP” rather than “transmitted to ERP.”
Keep Thai e-Tax authenticity separate from OCR extraction
Receiving a supplier’s PDF and extracting its fields does not create or validate an official e-Tax Invoice. ETDA’s e-Tax Invoice and e-Receipt FAQ describes digitally signed electronic documents delivered to buyers and says data submitted to Thailand’s Revenue Department must use the required XML format. The Revenue Department maintains its e-Tax information portal. Those are tax-document rules; OCR is a data-capture method.
Where the received document is an e-Tax Invoice, accounting and tax owners should decide its validation path. ETDA describes TEDA Web Validation for electronic documents, including checks related to signatures, timestamps and structure in supported PDF/PDF-A-3 or XML files. Signature authenticity and OCR field accuracy answer different questions. Decide where document verification, evidence retention and any Revenue Department requirements sit in the workflow. This article is an operational design guide, not an individual tax determination.
For cross-border access by headquarters, document where originals and extracted data are stored, who may view them and how corrections are exported. For cloud tools, confirm available regions, permissions, logs, deletion and model-training terms in the actual contract and product documentation. Generic marketing statements are not proof of suitability for a specific factory or document.
Test the posting path in the PoC, not only extraction accuracy
A useful trial set represents the actual suppliers, channels, languages, page counts, values and transaction types. Include parts invoices with PO, no-PO expenses, credits, freight, discounts, resends and poor scans. Have accounting and purchasing jointly agree the ground truth. If the source is genuinely ambiguous, record that ambiguity rather than inventing a correct answer. Report document classification, mandatory-field accuracy, line completeness, supplier identification, exception rate, resolution time, ERP posting success and post-posting correction as separate measures.
Consider a hypothetical factory receiving 1,000 invoices a month. Suppose 850 pass initial validation and 150 enter the exception queue. Staff resolve 100 exceptions that month, leaving 50 open. The initial pass rate is 85%; 850 + 100 = 950, so 95% reach the posting gate during the month; 5% remain open. The number posted without human intervention is a separate measure and cannot automatically be called 850, because approval or ERP rejection can still stop a record. These are illustrative assumptions, not observed performance.
If a better extraction model raises the initial pass count to 900 while 200 records fail at the ERP gate because the vendor master is incomplete, the end-to-end result may not improve. Set PoC acceptance around traceability to a final ERP voucher number under agreed quality and approval conditions. State the denominator for every reported automation percentage.
Keep the trial results at the invoice level so the cause of each stop is visible. If twenty invoices from one supplier have a misread invoice number, the problem may be the layout rule or source quality. If the number is read correctly but the ERP vendor code cannot be found, the master data is the issue. Combining both under one failure rate hides the investment decision. For each invoice ID, record document type, extracted value, agreed correct value, failed rule, human correction and ERP response. This distinguishes product configuration work from a change in purchasing or accounting practice.
Measure the time humans spend resolving an exception. OCR may finish in seconds while a request for a replacement document waits three days and delays month-end close. Conversely, highlighting the source line can shorten review time even when the exception count is unchanged. Separate time to initial validation, time to assign an owner, active correction time, waiting for an external response, and time to final ERP registration. These are different delays with different remedies.
State which documents were excluded from the PoC. A trial that leaves out handwritten or mixed-language invoices cannot prove suitability for every supplier. If strong results come from one stable layout, plan an initial deployment limited to that scope. If the test deliberately overrepresents difficult forms, explain how that differs from normal monthly intake. Retain the original evidence and evaluation sheet so a later model or service can be compared under the same conditions.
Roll out by supplier group and transaction route
Start with a group that has meaningful volume, relatively stable forms and usable ERP master data. First control intake, duplicates and original-document storage. Then introduce header extraction with human validation. Add lines, PO and receipt checks, approvals and ERP posting as the exception reasons become clear. Agree who approves supplier aliases, amount tolerances, no-PO invoices, tax classification, cancellations and month-end exceptions before development hardens those decisions into screens.
Define states such as received, extracted, under validation, waiting for supplier, waiting for purchasing, pending approval, ready to post, posted and cancelled. Give each state an entry condition, exit condition, owner, deadline and permitted action. Prepare source invoices, vendor master extracts, sample POs and receipts, previous duplicate cases and the ERP field map for the PoC. Test confidentiality and storage arrangements before putting real documents into a vendor trial. Compare systems on line-item output, confidence and source coordinates, audit export, mixed-language documents, exception routing and safe ERP retries, not just per-page OCR price.
Once live, review the leading exceptions weekly and post-posting corrections monthly. Change receiving rules, master data, extraction settings or matching rules according to the cause. Regression-test representative invoices whenever a model or rule changes. Human corrections should be reviewed before they become training examples. A better extraction score is useful only when the full record becomes safer and faster to post.
Assign an owner to every state
If the employee who receives an invoice must also resolve every error, the workload will concentrate in one AP inbox. Assign unclear supplier identity to purchasing, missing goods receipts to the warehouse, tax classification to accounting, and ERP rejection to IT. Keep a separate owner accountable for the final AP posting, and specify who takes the next action when two departments are involved. Define states such as received, extracted, under validation, awaiting supplier, awaiting purchasing, awaiting approval, ready to post, posted and cancelled. For each state, document its entry and exit conditions, permitted roles, deadline and return path. An indefinite “processing” state makes aging and root-cause analysis impossible. If urgent month-end handling is allowed, record its exceptional approval separately from the ordinary approval.
Prepare the minimum PoC data set
Collect original examples from the target suppliers, a vendor-master extract, matching PO and goods-receipt examples, previous duplicate and rejection cases, and the ERP AP field map. Include invoices that employees previously resolved through a phone call or an email, not only clean successes. Without a common ID linking the original to the ERP voucher, posting success cannot be measured. Before putting real documents into a third-party trial, check the permitted purpose, storage region, access rights and deletion procedure. Redacting a bank account or tax identifier can make a validation test unrealistic; use synthetic examples for user-interface demonstrations and a tightly controlled real-document environment when fidelity is necessary.
Ask vendors questions beyond “Can it read invoices?”
Ask how the product returns multi-page lines, per-field confidence and source coordinates; whether supplier-specific correction rules can be governed; whether correction histories can be exported; and how it deals with the actual mixture of Thai, English and Japanese forms. Demonstrate with difficult company documents and require a reviewer to trace a proposed field back to its source. Ask how an ERP resend avoids duplicates, how the exception owner and deadline are assigned, and how an API error becomes an action a business user can understand. In the quotation, separate per-page extraction from channel integration, storage, vendor-master cleanup, exception workflow, ERP interface, testing and support. A high early exception rate creates human work that a low OCR unit price does not show.
Connect the boundary with purchasing and receiving
Invoice capture organizes the document received from a supplier. PO creation, PO approval, PO OCR and goods-receipt entry are separate processes, but they share matching keys. Reading a PO number from an invoice is not enough if the ERP PO is closed, uses a different currency or has an unposted receipt. In that case the posting gate should stop the record and show the exact conflicting key and the department that owns the source correction. A vague search screen leaves the user to infer what went wrong. For the upstream capture of the order itself, see our purchase order OCR guide. For payback and the overall three-way match design, see invoice processing automation. This article covers the controlled conversion of a received supplier invoice into reliable ERP input between those two boundaries.
Common implementation questions
If suppliers send PDFs, can we stop at eliminating paper scans?
PDF intake can reduce lost paper and repeated scanning, but a PDF is still a document meant for a person to read. It does not necessarily contain the ERP supplier code or account assignment, and the same PDF may be sent twice. Controlled intake, duplicate detection, extraction, validation and approval remain necessary. If a supplier can provide structured data, consider taking that data directly instead of OCR while still verifying its authenticity and fit to the transaction.
Can we auto-post only fields with high confidence?
Fields can be accepted automatically under an approved rule, but the model’s confidence is not a posting permission. One misread digit in an invoice number can defeat duplicate detection even when the field scores highly. Conversely, a minor address-reading error may be tolerable when legal supplier identity and ERP code are verified elsewhere. Define review conditions by the business consequence of each error. Use field confidence to guide reviewer attention rather than as a universal release threshold.
What if our ERP has no API?
An ERP import function or supported CSV format may still provide a route. Do not mark file generation as success: check the import result and return the ERP voucher number or rejection to the source record. For manual import, record the file version, operator and time. Screen automation is possible in some environments but can be fragile when screens change or an operation stops halfway through. Design duplicate prevention and result reconciliation first. The pre- and post-posting gates apply regardless of the transport method.
Should we force every supplier to use the same template?
One layout for every supplier may be unrealistic. Smaller rules can be more valuable: always print the PO number, mark a resend in the subject line, and send invoice and delivery note as separate files. Analyze the leading exception reasons for major suppliers and negotiate low-burden changes. If a format changes, specify a transition period and test both old and new versions so invoices arriving during the change are not lost.
Should accounting or IT own the operation?
Accounting normally owns business rules and the final AP entry, while IT maintains connections, monitoring, permissions and incident response. The exact role of purchasing or a shared service center depends on the organization. Write down who diagnoses an OCR error, an outdated vendor master and an ERP rejection; who corrects it; and who authorizes resending. Bring accounting, purchasing, warehouse and IT into the exception review so upstream failures do not get mislabeled as OCR problems.
What should we monitor every day?
Track received documents, unclassified items, validation passes, unresolved items by reason, the oldest pending approval, posting backlog and ERP errors. Reconcile the mailbox or portal intake log with the invoice-candidate queue: a document received but absent from every queue is especially dangerous. At month-end, account for received items as posted, cancelled or unresolved. If OCR or ERP is unavailable, keep accepting originals safely, hold records with their IDs and verify each manual or retried posting against the ledger before the system resumes.
How should extraction-model changes be controlled?
A layout change can make a previously correct field read the wrong column. Test changes on representative clean and difficult invoices, including discounts, multi-page lines and similar invoice numbers. Compare field accuracy, exception reasons and posting-gate passage before and after. If one supplier improves while another worsens, restrict deployment by supplier. Record effective time, affected forms, owner, approver and rollback method. Never silently rewrite an already approved and posted voucher because a model was upgraded; use the ERP’s audited correction process.
What should we prepare for the first consultation?
You do not need every supplier’s archive. Bring three to five major anonymized layouts, each with a routine and difficult example, monthly volume, receipt channels, the ERP AP screen, PO/receipt matching practice and common rejection reasons. If monthly data is unavailable, count intake and handling time for one recent week. Keep the layout intact while masking sensitive names, bank accounts, people and prices. Use a controlled real-document test where redaction would distort the accuracy question. The first shared decision should be which conditions make accounting comfortable posting a record, not merely which characters OCR can read.
Summary
Automated invoice data capture succeeds when a supplier document becomes a controlled, validated and uniquely posted ERP record. Consolidate intake, preserve the original, validate document, fields, arithmetic and business rules, resolve exceptions with clear ownership and verify the ERP voucher number. Treat Thai e-Tax document authenticity as a separate control from OCR.
TOMAS TECH can help a Thai factory map sample supplier invoices to ERP requirements, select a suitable first supplier group and design the exception and posting gates. Contact us with anonymized samples, monthly volume and the main reasons invoices currently stop, and we can make the first assessment concrete.
