AI-OCR Implementation in 4 Steps, From Inventory to PoC

In the back office of a Japanese-owned company in Thailand, invoices, delivery notes, goods receipts, customs paperwork, timesheets and internal request forms are still typed into systems by hand. Everyone involved already knows that AI-OCR exists. The staff have read the product comparisons and looked at the price ranges. And yet the project does not move forward, or it goes live and quietly falls out of use within a few months. Those two failures share a single cause. The conversation starts with products, ahead of the work of counting and testing the company’s own documents. This article treats AI-OCR adoption not as a purchasing decision but as a project made of four steps, from taking inventory of the target documents, through checking the destination systems and evaluating products, to validating accuracy in a PoC, and sets it out for the reality of Japanese-owned plants and subsidiaries in Thailand.

Why “we know about AI-OCR” so rarely becomes “we have deployed it”

Start with where you are. Nobody disputes that manual paper handling in the back office is inefficient. The problem is that between recognising this and being able to decide, the material needed for the decision is missing.

The stall usually takes one of three shapes.

• The scope is vague. Everyone agrees on the goal of getting rid of paper, but nobody has counted how many of each document type are processed per month.
• The only evidence available is a catalogue figure. Published recognition accuracy sits high and tightly bunched across products, so it gives you nothing to choose on.
• No estimate of the benefit can be produced. Without a number for the hours saved, the internal approval request never gets filed, or gets sent back.

The second is the most awkward. According to a media roundup comparing AI-OCR products, as of 2026 several products claim recognition accuracy above 99%, and comparison is generally made on around five axes, functionality, accuracy, price, integration and support. In other words, catalogue accuracy no longer separates one product from another. The separation appears when you point the product at your own documents. A catalogue figure says nothing about a smudged company seal on your invoices or the line-item layouts that differ from supplier to supplier.

Meanwhile the surrounding environment is clearly moving. In the Business Outlook Study 2026 published by UOB on 30 June 2026, more than 70% of SMEs in Thailand have already adopted AI, a level above the regional average. The same study reports that among the SMEs that adopted AI, 58% saw cost reduction and 44% saw productivity gains. It is reasonable to read this as a stage where the technology is in general use and the remaining task is to eliminate the reasons your own company has not started.

For the wider picture of automating the whole back office, of which AI-OCR is one part, see our article on back office automation with AI-OCR. This piece isolates the adoption process itself from that broader ground and goes deeper on it.

What generative AI-based AI-OCR changes compared with the older generation

Before evaluating anything, there is one technical premise to settle. Products currently sold as AI-OCR include two generations of quite different character.

Conventional OCR is fundamentally built on defining in advance where to read. A person configures the definition, the date sits at this coordinate on this form, the amount sits in this box. For internal forms with a fixed layout, that produces high accuracy. But the moment a supplier changes its format, the definition becomes invalid and has to be rebuilt. When you have several dozen suppliers each using their own invoice format, creating and maintaining those definitions becomes a new manual task in itself.

AI-OCR built on generative AI reads differently, by understanding context. Because it interprets document structure as meaning, it can infer the correspondence between a field label and its value even for unstructured documents whose positions were never defined. A published explanation of documents and data usage identifies exactly this, the ability to handle unstructured documents through contextual understanding, as the essential difference from the conventional generation.

The contrast can be summarised as follows.

That last row drives the whole implementation design. An error in the conventional generation is visible as something that could not be read, whereas a system that infers from context can return a value that looks formally correct. That is precisely why the PoC described later must measure the share of records that needed correction, not the share that could be read. Whichever generation you choose, that validation design cannot be skipped.

AI-OCR adoption breaks into four steps

With the preamble out of the way, here is the substance. Adoption becomes far less confusing when split into the following four steps. This sequence matches the commonly described approach, which starts with surveying document types and volumes, then checks the destination systems, evaluates and compares products, and finally validates.

None of the four can be reordered. In particular, if step 2 is pushed behind step 4, the project stalls for the reason that accuracy was fine but the data cannot be loaded into the accounting system. Each step follows below.

Step 1, take inventory of the target documents and their volume

The first task is not to collect product literature. It is to count what your company processes and how much of it. Projects that skip this almost always see their scope swell mid-way until nothing can be concluded.

The inventory fills in the following items for each document type.

Filling in that table produces the same realisation at most sites. Volume is heavily skewed by document type, and the top one or two types account for most of the total. That skew is probably why beginning with invoice OCR is such a common choice. Choose a request form that occurs a handful of times a month as your first target and the validation period ends without any measurable effect.

One note on measuring current handling time. Rather than asking staff how long a sheet takes, have them process a few sheets while you time it. Numbers gathered by interview tend to be understated, particularly by experienced staff, which inflates the later benefit estimate. Measure not only the keying itself but the time spent locating the original, querying the issuer about unclear entries, and having a second person cross-check afterwards. That produces a figure close to reality.

The inventory has one conclusion to reach. Narrow the first AI-OCR target to one or two document types. “Invoices only, to start” is entirely acceptable. Narrowing is not a compromise. It is the condition that makes the validation in the later steps possible at all.

Step 2, check the destination system and the integration spec

After the inventory, establish where the extracted data goes. AI-OCR only takes responsibility as far as turning characters into data. The work is only shortened once that data lands in the accounting system or the ERP.

Underestimate this and a familiar failure follows. Recognition accuracy was fine, but the field names in the exported CSV did not match what the accounting system accepts, so a person ends up rearranging the file before import. The transcription work has simply been renamed from “keying” to “reformatting” and almost none of the saved hours survive.

What to check differs by destination.

Code matching deserves particular attention. What is printed on an invoice is the supplier’s company name, not the supplier code in your ERP. Without a mechanism to match the extracted name against your master data, looking up the code remains a human task. The same applies between item name and item code, and between department name and department code. Deciding at the inventory stage, field by field, whether the extracted string is usable as it stands or requires a master lookup will keep the later integration estimate stable.

One more thing to settle up front is the relationship with the approval flow. Whether the data extracted by AI-OCR is injected before approval or after it changes the shape of the integration you need. Injecting before approval makes operation straightforward, because correction can be built into the approver’s task, but it may require changes on the workflow side.

Step 3, evaluating products, where to put the decision axes

Only now does product comparison begin. This is the correct position in the sequence and it should not be brought forward. Look at products without the inventory results in hand and you end up choosing on the number of features.

As noted above, as of 2026 several products claim recognition accuracy above 99%, so accuracy itself no longer functions well as a comparison axis. In practice the separation comes from the following six points.

Of these, the one that most often becomes an issue at the approval stage is data location. Invoices and timesheets contain supplier information and information relating to individuals, so where the extracted data and source images are held, who can access them and how long they are retained should all be confirmed in writing before contracting. If headquarters has an information management policy, obtaining its requirements before shortlisting products avoids rework.

Detailed feature and price-band comparison of individual products is covered separately in our article on comparing AI-OCR products and how to choose. This article focuses on preparing your own side of the conditions before that comparison starts.

The exit condition for this step is a shortlist of 2 to 3 products. Narrow to a single product before the PoC and, if the result disappoints, you have no fallback prepared and have to restart the validation from the beginning. Validate five or more in parallel and the validation work itself becomes the burden, and no conclusion arrives within the period.

Step 4, validate on your own documents in a PoC

Of the four steps this is the one most often skipped, and the one whose omission costs the most. A published explanation of what to watch for when adopting AI-OCR makes the same point, that test validation using samples of your own principal forms is essential when selecting a product. Catalogue accuracy is accuracy against the documents that product was trained on, not accuracy against yours.

How to choose validation samples

The quality of the PoC conclusion is decided by the samples you feed it. What to avoid is submitting clean specimens. The forms that actually flow through the business have seals overlapping the printed characters, scans that came in crooked, faxed copies that have faded, and handwritten additions. A PoC that excludes those grubby real documents will fail in production.

Compose the sample set as follows and it will reflect reality.

• Collect forms from your main suppliers, working down from those with the highest number of documents. A few sheets per supplier will not capture format variation, so include several months of the same supplier.
• Deliberately mix in forms that previously caused keying errors or follow-up queries. That brings the proportion of difficult documents closer to the real one.
• Use originals containing handwritten additions, overlapping seals, skew and fading exactly as they are. Do not clean them up or filter them out.
• If your scope covers both Thai and Japanese, include both in the sample set in the same ratio as in reality.

What to measure

Keep the measurements to four. Adding more only makes the judgement harder.

For recognition accuracy, we recommend measuring per field rather than per character. Per-character accuracy tends to look high as a number while carrying little operational meaning. If one character in the amount field is wrong, that field needs correcting. Count not how many characters matched but whether the field could be used as it came out.

Set the pass line before the PoC starts. Decide the criterion after seeing the results and you are simply endorsing whatever number appeared. The practical way to set it is on elapsed time rather than absolute accuracy. Is the handling time per sheet, including correction, shorter than the current manual keying? Making that single question the primary criterion keeps the discussion from spreading.

Duration and staffing of the PoC

Allow one to two months. Less than a month and you will not capture the forms that pile up at month end or the documents that only arrive at certain times of year. More than three months and attention fades, with extensions continuing while the original hypothesis is never tested.

On staffing, involve from the outset the people who will actually do the checking and correcting. Run the PoC inside the IT department alone and you will get accuracy figures but no judgement about whether it can survive daily operation. How heavy the correction workload really is can only be known by the people who did it.

Cost and how to think about pricing models

Because the money depends heavily on the number of document types and the volume, it makes sense to describe ranges. A published explanation of AI-OCR costs sets the monthly base fee broadly in the range of 30,000 to 200,000 yen, with pricing models split between per-volume charging and flat rate. On top of that base fee, initial configuration and integration with existing systems generally incur separate costs.

The choice of pricing model follows from the volume skew you counted in the inventory. Pick per-volume charging for work that concentrates at month end and cost spikes in busy months. Pick a flat rate with a high allowance for work whose volume is stable and you pay indefinitely for capacity you do not use. Here too, the basis for the decision is the actual count from step 1.

Price bands and pricing models for procurement in Thailand specifically are covered in our separate article on AI-OCR pricing and how to compare total cost, while this article concentrates on when, and on what basis, to produce that estimate at all.

Three issues specific to Japanese-owned companies in Thailand

Everything so far applies at a site in any country. The following three issues are specific to Japanese-owned plants and subsidiaries in Thailand.

Japanese and Thai forms side by side

In a Thai back office, forms in Japanese exchanged with the parent company and Japanese suppliers sit on the same desk as forms in Thai for local counterparties and authorities. That mixture constrains product selection tightly.

Thai uses a writing system in which vowel and tone marks attach above and below the base characters, and that complexity places it among the harder scripts to recognise in print. What accuracy you actually get varies greatly with the product and the condition of the documents, so rather than taking published figures at face value, always include your own Thai-language forms in the PoC sample set. Doing so avoids the failure of passing the PoC on Japanese forms alone and then watching correction work balloon in production.

Making it stick in a small back office

At Japanese subsidiaries in Thailand, it is common for a handful of people to cover accounting, general affairs, purchasing and HR between them. That structure is both a tailwind and a headwind for AI-OCR adoption.

The tailwind is that decisions come quickly and there is little inter-departmental coordination to do. The headwind is that the time available for standing up a new system is structurally scarce. So in the implementation design, minimising the number of new operations staff have to learn matters as much as accuracy itself. Consolidating the review of extracted results into a single screen, and documenting the criteria for correction, are unglamorous preparations that decide whether the system sticks.

Designing for handover from the outset

Expatriate rotations and local staff turnover mean the people in these roles change every few years. If the field definitions and correction criteria set at implementation exist only in one person’s head, operation degrades at every handover.

The remedy is simple. At implementation, leave the list of target documents, the field mapping table, the correction criteria and the destination system specification together in one folder. These artefacts are produced naturally during the PoC, so almost no extra work is involved. The only difference is whether you keep them or let them evaporate.

How to estimate the benefit

What the approval request needs is a number for the hours saved. But applying published case-study figures directly to your own situation inflates expectations. It is worth being explicit about how to read them.

Among published examples, Kayaba is cited as having cut the time required for stocktaking work from one month to one week, and Sumika Nogyo Shizai as having eliminated 70% of the work in scope. In the UOB Business Outlook Study 2026 mentioned earlier, 58% of the Thai SMEs that adopted AI reported cost reduction and 44% reported productivity gains.

What to extract from these numbers is not the percentages. The point is that each is a reduction rate within a limited scope of work. Paper handling across the whole company did not fall by 70%. Seventy per cent of the work selected as the target fell away. When applying this to your own case, put the one or two document types identified in the inventory in the denominator.

Your own estimate can be assembled from the following four items.

A note on that last row. What tends to be valued most after an AI-OCR deployment is often not the hours saved as such but the fact that the monthly close moved several days earlier. An earlier close means management figures are available sooner and there is more slack in reporting to headquarters. That effect is hard to convert into money and therefore hard to place in the estimate table, but it is a strong argument in the approval discussion.

Frequently asked questions

How long does an AI-OCR implementation take

With scope narrowed to one or two document types, a realistic guide is 3 to 4 weeks for the inventory and destination check, 2 to 3 weeks for product evaluation, and 1 to 2 months for the PoC, totalling roughly 2 to 4 months. If that has to be compressed, the part to cut is product evaluation, not the PoC. Shortening the comparison by going straight to two candidates is far safer than skipping validation.

Can form OCR read handwriting

Some products can, but it is a harder problem than printed text and the gap between products is wide. So if your target forms contain handwriting, always include genuine handwritten documents in the PoC samples. It is equally important to decide operationally how handwriting will be handled. Designing the flow so that only handwritten boxes are checked by a person often still delivers a substantial overall benefit. Insisting on automating everything is what usually stops the project.

What accuracy target should an invoice OCR project aim for

Rather than fixing an absolute figure, we recommend judging on elapsed time. The operational pass line is whether the handling time per sheet, including correction, is shorter than the current manual keying. It is entirely reasonable to have a person check every record in fields where an error has direct consequences, such as the amount, while taking the saving from the remaining fields. Fix an accuracy target up front and you risk rejecting a combination that would in fact have delivered a benefit, purely because it fell short of the number.

Can one product handle both Thai and Japanese forms

Support differs by product, so this is a condition to confirm early in selection. Even where both languages are listed as supported, the level of support varies with the condition of the documents. Make the judgement in the PoC, not from published material. And if a single product cannot cover both, splitting processing by language is a workable configuration. In that case, however, integration into the destination system doubles, so weigh the additional operating load against the integration spec you established in step 2.

What should we do if the PoC does not reach the accuracy we expected

Before switching products, separate the cause into three. Is it the documents themselves, the field definition settings, or the fit of the product. If it is an input-side problem such as low scan resolution or creased originals, revising the scanning procedure will improve it. If the field definitions are simply too coarse, adjusting the configuration will improve it. Only once both of those have been eliminated is it reasonable to suspect product fit. Change products without that separation and you will reproduce the same result.

Summary

Most AI-OCR failures are failures of sequence, not of product performance. Going to look at products before counting what your company processes and how much of it, choosing candidates on catalogue accuracy, and signing without ever testing on your own forms. As long as the project runs in that order, the product you pick will not change the outcome much.

The approach decomposes into four steps. In the document inventory, measure the monthly volume and current handling time per document type and narrow the target to one or two. In the destination system check, decide field by field whether the extracted data lands directly in accounting or ERP or needs a master lookup. In product evaluation, shortlist to two or three on supported languages, data location, integration method and pricing model rather than on catalogue recognition accuracy. And in the PoC, use the documents that actually flow through the business rather than clean specimens, and decide pass or fail on the handling time per sheet including correction.

At a site in Thailand, the coexistence of Japanese and Thai forms is added to all of this. Pass the PoC on Japanese forms alone and correction work will balloon in production. Whether the system sticks in a small back office is decided less by accuracy than by how few new operations the staff have to learn. And because those staff will change within a few years, leave the field definitions and correction criteria behind as documents.

The first move is not requesting product literature. It is counting how many invoices arrived last month. Without that number, the basis for comparison, the benefit estimate and the PoC pass criterion all lack any foundation. With it in hand, everything that follows moves surprisingly quickly.

If you are at the stage of wanting to establish whether your forms are in a state that AI-OCR can handle, or how far they can be integrated with your existing accounting system or ERP, please get in touch through our contact page. Exploratory enquiries are welcome. We will go through your current document types, volumes and system configuration and work out with you which document type is the realistic place to start.

References

• The difference between OCR and generative AI, and how to approach adoption, Wanbishi Archives — in Japanese. The difference from conventional OCR, namely that generative AI-based OCR handles unstructured documents through contextual understanding, and the four adoption steps of surveying document types and volumes, checking the destination system, evaluating and comparing products, and validating
• AI-OCR cost ranges and pricing models, AIJIMY — in Japanese. Monthly base fees broadly in the range of 30,000 to 200,000 yen, the difference between per-volume charging and flat-rate pricing, the case of Kayaba cutting stocktaking work from one month to one week, and the case of Sumika Nogyo Shizai eliminating 70% of the work in scope
• AI-OCR product comparison trends, Digi-Mado — in Japanese. That as of 2026 several products claim recognition accuracy above 99%, and that comparison on around five axes covering functionality, accuracy, price, integration and support has become standard
• UOB Business Outlook Study 2026, ThaiPR — dated 30 June 2026. More than 70% of SMEs in Thailand have already adopted AI, above the regional average, and among the SMEs that adopted AI, 58% saw cost reduction and 44% saw productivity gains
• Points to watch when adopting AI-OCR, NEC Solution Innovators — in Japanese. The importance of running test validation with samples of your own principal forms when selecting a product