Reading purchase orders with AI-OCR is no longer a novelty. Case studies have been published across virtually every industry, and converting purchase orders that arrive by fax into order data automatically is now routine in manufacturing and wholesale alike. In other words, whether a product “can read a purchase order” is no longer the deciding factor in a product selection.
So why do purchasing teams still say that the keying never goes away, or that they end up pulling the paper back out at goods receipt? The reason is simple. Automating the capture of the purchase order alone leaves the steps that follow it — verifying the delivery note at goods receipt, matching the invoice at month end — exactly as manual as before. There are three documents in the chain, and only one of them has been automated. Returns plateau quickly under those conditions.
This article reframes purchase order OCR not as a standalone feature but as a redesign of the whole process, one that reaches through to three-way matching across the purchase order, the delivery note, and the invoice. Market movement, the difficulties specific to purchase orders as a document type, the real effect visible in published cases, the conditions particular to a Thai site, and how to think about cost — we will work through the perspectives a purchasing manager needs in order to make an investment decision.
What Purchase Order OCR Is — Market Growth and Why Paper Persists
Purchase order OCR refers to a mechanism that optically reads the purchase orders arriving from your trading partners, extracts fields such as item, quantity, unit price, and delivery date as structured data, and feeds them into an order management or purchasing system. Where conventional OCR lifts characters from fixed positions in a fixed layout, AI-OCR absorbs layout differences through trained models and can identify fields even in unstructured documents.
The market itself is growing steadily. According to the “OCR Solution Market Trends, FY2025 Edition” published by the Deloitte Tohmatsu MIC Research Institute on August 26, 2025, the domestic OCR solution market in Japan expanded from just over ¥54 billion in FY2022 to just over ¥57 billion in FY2023, or 105.5% year on year. While the market as a whole grew in the 5% range, the AI-OCR segment continued to grow at around 20%. Growth in the overall market is clearly being pulled along by AI-OCR.
Why does the OCR market keep expanding in an era when everyone talks about going digital? Because business-to-business documents are created at the sender’s convenience. No matter how thoroughly you build out an electronic procurement platform on your own side, as long as your trading partners send purchase orders by fax, as PDF attachments, or on paper through the post, the receiving side has to keep processing information that starts life on paper. In most cases, only a subset of high-volume partners can realistically be migrated to EDI or web-based ordering. Fully digitizing the long tail of smaller partners is not practical, and the paper and faxes left in that tail are what sustain demand for OCR.
Among business documents, the purchase order is particularly prone to remaining paper-based, for three reasons. First, it is issued by the buyer at the trading partner, so you as the recipient have no authority to dictate its format. Second, urgent add-on orders and quantity changes are routinely written in by hand. Third, the purchase order is the trigger for order entry, production planning, and inventory allocation, so any delay in converting it to data stops every downstream step. High volume, inconsistent formats, and time pressure all at once. This is the textbook bottleneck — high need for automation, high difficulty in automating.
Three Barriers Unique to Purchase Order Processing
Compared with digitizing invoices or delivery notes, purchase orders carry difficulties of their own. Recognizing these three points early in the evaluation keeps your comparison criteria from drifting.
The first barrier is that formats differ from one trading partner to the next. For documents you issue yourself, you set the layout. A purchase order, however, only ever arrives from outside, so there are as many layouts as there are trading partners. And because the purchase order is the starting point of the transaction, the balance of power makes it awkward to ask a customer to change their form. Field labels vary too. “Part number”, “item code”, and “item no.” are all used to mean the same thing, and “delivery date”, “requested delivery date”, and “required arrival date” may all appear in the same column. Even when raw recognition accuracy is high, the point where projects stall is the semantic conversion — how an extracted string maps to a field in your own master data. Kami Shoji Co., Ltd. reports more than 500 format patterns in its own environment and cites having digitized 100% of them as its result. Read the other way around, that is the reality of the purchase order as a document type — layouts numbering in the hundreds genuinely exist.
The second barrier is handwriting mixed into printed forms. A buyer corrects a quantity in red pen on a printed purchase order, or writes an additional delivery location into the remarks box. That handwritten portion is the most recent instruction, and ignoring it leads to a wrong shipment. OCR that reads only machine print will drop precisely the most important information. Handwriting recognition is harder than print, and accuracy varies with individual writing habits and the pen used, which makes it essential to design where the machine’s judgment ends and human review begins.
The third barrier is integration with existing systems. Being able to read a purchase order and output a CSV means little if loading that file into the order management system, the purchasing system, or the ERP is still done by hand. The work has simply moved location, not shrunk in total. Unglamorous design decisions — error handling on import, treatment of items not registered in the master, detection of duplicate orders — are what determine the reduction you actually realize. Before you compare OCR accuracy, confirm which interfaces your core system can accept data through.
None of these three barriers can be cleared by engine performance alone. Inconsistent formats require field-mapping design, mixed handwriting requires exception-handling flow design, and system integration requires alignment on interface specifications. One reason AI-driven paper document digitization so often gets reduced to “choosing a recognition engine” is that these three points rarely surface as line items in a product comparison sheet. When a vendor demo shows you impressive recognition accuracy, that is exactly the moment to hand over your own purchase order samples and ask how these three are handled.
What Purchase Order OCR Delivers — Time Savings in Published Cases
So how much effect does purchase order OCR actually produce? The following examples come from the collection of purchase order AI-OCR case studies published by Infomart, drawn from companies in different industries. Note that the collection is a continuously updated page and individual cases carry no publication date. The figures are quoted as each company published them.
Hokubee Co., Ltd. is a manufacturing example. The company now processes 80% of the purchase orders arriving by fax into orders automatically, compressing the time spent on data entry and delivery-date replies to 1/4 of the previous level. What deserves attention is that the reduction covers not just entry but the delivery-date reply as well. Once order data lands in the database quickly, the step of checking inventory and production plans and responding to the customer can also be pulled forward. It is a textbook case of automation rippling into downstream work.
Moriyama Nyugyo Co., Ltd. cut entry time per document from 3 minutes to 30 seconds — a saving of 2 minutes 30 seconds per sheet. For a site handling 100 documents a day, that is 250 minutes, or a little over 4 hours, saved daily on a simple calculation.
Oisis Co., Ltd. reduced work that had taken more than 10 hours a day to under 3 hours. A 10-hour daily workload implies a volume that one person could not absorb alone and that had to be shared across several staff. Bringing it inside 3 hours creates room to revisit the staffing plan itself.
Kao Professional Services Co., Ltd. processes 6000 documents a month and cut per-document processing time from 5 minutes to 1 minute. Six thousand documents a month works out to roughly 300 documents per business day. Once you picture a 4-minute saving per document multiplied across 6000 documents, it becomes clear how strongly returns in this area depend on volume.
Kami Shoji Co., Ltd., as mentioned in the previous section, digitized 100% of more than 500 format patterns. What is distinctive here is that the headline result is coverage of the formats the system can handle, not a percentage reduction in time. In a high-mix, many-supplier environment, the share of documents that fall out as exceptions drives operational load more than average handling time does.
What these cases show is that purchase order OCR on its own produces ample effect as long as you confine the scope to the entry step. Processing time falling to a fraction of its former level has been reproduced at multiple companies. The stage of wondering whether to adopt it has therefore passed. The live question has moved to how far the scope of automation should extend.
Do Not Stop at the Purchase Order — Three-Way Matching with Goods Receipt and Invoice
The next wall companies hit, once they have automated the entry step, is matching. Even with purchase orders converted to data, verification at goods receipt and reconciliation against the invoice that arrives at month end are still done by eye in a great many organizations. Does the quantity ordered agree with the quantity delivered? Does the amount billed agree with the unit price on the order? That check means putting three document types — purchase order, delivery note, invoice — side by side, and it is commonly called three-way matching.
As long as three-way matching stays manual, the benefit of purchase order OCR remains capped. Entry time drops, but the burden of the matching and discrepancy investigation that concentrates at month end stays exactly where it was. If anything, once order data reliably reaches the system, the situation becomes more visible and more frustrating for the staff involved — the data is there to be matched automatically, and yet people are still matching it by hand.
Designs that hand the matching itself to an AI agent have recently appeared. According to a press release issued by homula Inc. on PR TIMES on February 12, 2026, its automated invoice processing solution has an AI agent take on matching, allocation verification, and exception detection. The published results include a reduction in first-level approval workload of up to 100%, and verification of allocation and distribution line items — which previously took more than 30 minutes — completing in seconds. Processing is priced from 50 yen per document, implementation takes as little as 2 weeks, and one published deployment handles roughly 9,000 documents per month.
The important part here is allocation verification going from more than 30 minutes to seconds. This is not a substitute for simple keying. The target is a judgment about consistency across multiple documents, work that until now happened inside a person’s head. A task that takes 30 minutes per case is the one that weighs most heavily on the person doing it, and because it clusters at month end it is also a direct cause of overtime. Whether you can remove that is what separates a one-off OCR deployment from a genuine process redesign.
The phrasing “up to 100% reduction in first-level approval workload” should also be read as presupposing an operating model in which no human touches a case unless an exception is detected. Put the other way round, people engage only with the cases the system flags. That way of thinking connects directly to the point about not over-trusting accuracy discussed later in this article.
If three-way matching is in scope, you cannot design the solution by looking at the purchase order alone. How to structure the invoice side — matching logic and consumption tax invoice compliance included — is covered in detail in our article on invoice processing automation, which is worth reading alongside this one. The delivery note, the third leg of the match, also matters. How you capture it at goods receipt determines how reliable the match can be, and the practical questions around capturing delivery notes on the receiving dock are covered in our article on delivery note data capture.
Once you design for three-way matching, the object of the investment is no longer an OCR product but the whole procure-to-pay process. The internal approval case changes with it. For OCR alone you can justify the spend on reduced entry hours. Extend it to matching, and the benefits you line up include matching hours, discrepancy investigation hours, month-end overtime, and reduced risk of late payment and overpayment. Making that shift in perspective is exactly the judgment a purchasing manager is being asked for.
What Makes Thailand and ASEAN Sites Different
Everything above concerns documents and process. At sites in Thailand and elsewhere in ASEAN, one more motive for this investment comes into play — people.
According to “The Current State of Talent Shortages and Responses to Them”, published by JETRO on May 16, 2024, 40.4% of Japanese-affiliated companies in Thailand face talent shortage issues. The report draws on the FY2023 Survey of Japanese-Affiliated Companies in Asia and Oceania, with fieldwork carried out from August to September 2023. In the same survey, rising labor costs were the most frequently cited investment-environment risk, named by 72.8% of respondents. Around 40% of companies cannot secure the people they need, and over 70% see wage inflation as a risk. Those two conditions occurring simultaneously is the baseline situation for Japanese-affiliated companies in Thailand.
Under that baseline, the cost of keeping staff tied to simple back-office keying carries a different meaning than it does in Japan. If local staff you struggled to hire are spending their day typing purchase order figures into a system, that is not a rational allocation of a scarce resource. Retention points the same way — monotonous entry work is a common trigger for resignation, and every departure brings fresh training cost. Redefining the goal of automation as redirecting the people you have managed to hire toward higher-value work, rather than as cutting labor cost, also makes the investment easier to explain internally. Data entry automation at a Thai site is less a cost-reduction measure than a hedge against the difficulty of hiring.
The documents themselves bring their own difficulty at a Thai site. Purchase orders arrive in Japanese from the parent company and Japanese-affiliated suppliers, and in Thai from local suppliers. The same purchasing team handles documents in different languages in parallel. Some carry English alongside, and some are mixed in a single document, with item names in Thai while quantities and unit prices are numerals.
Multilingual support is, technically speaking, already a solved problem. According to a press release issued by AI inside on December 23, 2020, its DX Suite handles both printed and handwritten recognition for Thai and Vietnamese, as well as English and traditional Chinese, at practical accuracy levels. It is worth registering that handwriting recognition across several languages was already available as a product at that point.
Supporting a language and delivering the accuracy you need on your own documents are, however, two different things. Where handwriting is mixed in especially, verification should assume that accuracy will vary by language. How to evaluate recognition accuracy on handwritten forms and where to insert human review is covered in our article on handwritten OCR accuracy. If your purchase orders mix Thai and Vietnamese, we recommend starting with your own real samples and checking the results language by language.
One further point often missed at ASEAN sites is standardization across locations. Companies with sites in Thailand, Vietnam, and Indonesia frequently find that each location runs purchasing its own way, each maintaining its own spreadsheets. Introducing purchase order OCR is a natural opportunity to align field definitions across sites. Conversely, if each site adopts a different tool, the data cannot be consolidated afterwards, and group-wide procurement analysis stays out of reach.
How to Approach Implementation and Choose a Product
From here, we set out the questions that come up in an actual evaluation. We will not go into detailed product comparison criteria, but three questions mark the decision points.
The first question is whether to deploy OCR on its own or choose an AI agent type that includes matching. OCR alone is light to deploy, targets a clearly bounded task, and produces effects you can measure with an intuitive metric — entry time. A design that includes matching is heavier to implement but reaches the matching and discrepancy investigation load that concentrates at month end. The deciding criterion is simple. Work out whether your bottleneck is entry or matching. Are the entry staff working late, or are accounting and purchasing chasing discrepancies at month end? Look at where the overtime actually occurs and the answer emerges.
The second question is how to integrate with your existing purchasing system or ERP. It is enough at this stage to know that integration methods fall into three broad types — file-based integration such as CSV, direct integration by API, and RPA that drives the screens on your behalf. File-based integration is easy to set up but requires managing import timing and designing recovery when an import fails. API integration is stable in operation, but presupposes that the core system exposes an interface. RPA avoids modifying existing systems, at the price of fragility when screen layouts change. Which one you choose comes down to whether the core system can be modified and what capacity your IT department has.
The third question is how accuracy is evaluated. The accuracy figures a vendor presents change meaning with the documents measured, the time of measurement, and the population sampled. Is it a character-level recognition rate, a field-level correctness rate, or the share of documents that required no correction at all? The last of these is what matters in daily operation, but published figures are usually character-level, and comparing them directly produces numbers that do not match lived experience. The most reliable approach is to hand over your own purchase order samples and ask for results reported field by field.
Comparison criteria such as feature differences between products, the range of document types supported, and pricing structures are organized in our AI-OCR product comparison article, which is the one to read when you are narrowing down specific candidates. Our position in this article is that you should have your own answers to the three questions above before you start filling in a comparison table. If you build the table before those answers are settled, features you do not need work their way into the requirements and the decision drags on.
As for sequencing, starting with a narrowly scoped trial is the realistic path. Rather than putting every trading partner’s purchase orders in scope at once, begin with your highest-volume partners, or with partners whose formats are stable, firm up the operating flow and exception handling there, and then widen the scope. Starting where volume is highest also makes the effect easier to measure and gives you something concrete to build internal consensus around.
Cost Thinking and ROI Benchmarks
To support the investment decision, here is how to think about cost against benefit.
You first need a grip on what the current state costs. Research from Ardent Partners is a useful reference here. Figures published as coming from the firm’s “State of ePayables 2024” put invoice processing at companies without automation at an average of USD 12.88 per invoice, taking an average of 17.4 days to process. Alongside those, electronic invoice adoption stands at 67% and electronic payment adoption at 37%. These are invoice figures, but the structure of the work — receive a document, convert it to data, match it, approve it — is shared with purchase order processing, which makes cost per document and days per document a sound pair of axes for measuring your own operation.
That USD 12.88 per document should be understood as a total cost that includes not only labor but system fees, physical storage, and the opportunity cost of waiting for approval. What deserves the closer look, though, may be the 17.4 days rather than the money. Taking more than two weeks from receipt to completion means the item sits in someone’s queue that entire time, and that the operation has settled into clearing everything in a rush at month end. Shortening the elapsed days lowers both psychological load and error rates at once.
On the benefit side, the estimate is fundamentally volume multiplied by time saved per document. From the cases above, published levels include 3 minutes falling to 30 seconds and 5 minutes falling to 1 minute. Multiply your monthly document volume by the saving per document, then by your own fully loaded hourly labor cost, and you have a rough monthly saving. Whether you add the matching step changes the scale of the estimate considerably. If the level of allocation verification moving from more than 30 minutes to seconds can be applied to your own operation, the effect may exceed what the entry step delivers.
On the cost side, usage-based pricing tied to monthly volume has become common. The homula solution mentioned above publishes processing from 50 yen per document with implementation in as little as 2 weeks. Ricoh’s information page for its received invoice service presents an example of up to 83% time reduction on 300 invoices a month, specifically 40 hours becoming 7 hours. That figure is based on Ricoh’s own research as of July 2026. The fact that this level is demonstrated at a scale of 300 documents a month means mid-sized sites are well within the range worth evaluating.
The conclusion that follows is straightforward. The higher your monthly volume, the faster the payback. Conversely, deploying a feature-rich solution at a site that receives only a few dozen purchase orders a month means a long wait to recover the fixed cost. For a company with several sites, the rational sequence is to roll out from the highest-volume site downward and let smaller sites join the same platform later.
One caution applies when you calculate ROI. It is wise to avoid using headcount reduction as the denominator. As noted above, hiring is difficult in Thailand, and in most cases the hours you free up lead to reassignment rather than reduction. Framing the metric as how much transaction volume your existing team can absorb, rather than how many people you can remove, produces an explanation that matches reality.
Pitfalls to Avoid
Three points are where implementation projects most often stumble.
The first is deferring the design for inconsistent field naming. Teams are diligent about verifying recognition accuracy, yet the mapping design — how an extracted string corresponds to a field in your own master data — routinely gets pushed to a later phase. In live operation, however, most of the corrections that arise stem not from misread characters but from gaps in the mapping. Unglamorous groundwork such as item code cross-reference tables per trading partner, unit conversions, and differences in date format is what determines your operating load. Before implementation, list the field labels that appear on your major partners’ purchase orders and build a correspondence table against your master data.
The second is treating alignment with existing flows as a minor matter. Introducing OCR can quietly strip out judgments that staff had been making implicitly while looking at the paper. A local rule such as “if the delivery date field is blank on this partner’s purchase orders, it conventionally means the following Friday” is a typical example. Because such tacit knowledge is undocumented, it does not surface in a requirements definition workshop. Build a step into the schedule for interviewing the people doing the work and drawing out what exactly they are judging when they look at the paper.
The third is over-trusting accuracy and neglecting exception handling. However accurate the AI-OCR, running the operation on the assumption that recognition results are 100% correct lets errors flow downstream. What needs designing is not only how to raise accuracy but where to stop errors. Concretely, you need a mechanism that routes low-confidence fields to human review automatically, an alert when the quantity or amount on the purchase order differs from the order data beyond a set threshold, and a review screen that lets the checker decide quickly. Exception detection was named explicitly as a function of the AI agent in the three-way matching case above, and that is exactly this line of thinking. Rather than automating everything, hand people only the cases people should see. Where you draw that line decides whether the operation succeeds.
You should also fix a review cycle for the period after go-live. Trading partners change and formats get revised continuously. Each month, check the automated processing rate and the correction rate, and feed additional training for the formats of partners where corrections cluster. Without that cycle running, an automation rate that looked strong right after go-live will be visibly lower a year on. Decide at implementation time who watches these numbers and who owns the improvements.
A Checklist for Diagnosing Your Own Situation
Before making the investment decision, work out whether your problem sits within the boundary of the purchase order alone or extends to three-way matching. That single distinction sets the direction of the evaluation. Check how many of the following apply to you.
- A dedicated or semi-dedicated staff member is assigned to purchase order data entry
- Purchase order formats across your trading partners number several dozen or more
- Handwritten corrections and additions on purchase orders are an everyday occurrence
- A delay in entering purchase orders affects production planning or inventory allocation
- Purchase orders in several languages, such as Japanese and Thai, are handled by the same department
If many of these apply, purchase order OCR on its own should deliver ample effect to begin with. Next, check the following.
- Delivery notes and purchase orders are matched on paper at goods receipt
- Month-end time is consumed investigating discrepancies where the invoiced amount does not match the ordered unit price
- Invoice approvals stall in individual inboxes, concentrating payment processing at month end
- Order, receipt, and invoice data are held in separate systems or spreadsheets
- Checks for overpayment and duplicate payment rely on visual inspection
If many items in the second list apply, deploying purchase order OCR alone will produce limited effect. Bringing three-way matching into scope from the outset will give you better returns on the investment overall.
Frequently Asked Questions
What is purchase order OCR?
It is a mechanism that reads the purchase orders arriving from your trading partners, extracts fields such as item, quantity, unit price, and delivery date as data, and loads them into an order management or purchasing system. Because AI-OCR absorbs layout differences through trained models, it can identify fields even on unstructured purchase orders whose format differs by partner. Japan’s OCR solution market reached just over ¥57 billion in FY2023, growing 105.5% year on year, with the AI-OCR segment leading that growth.
How much does purchase order OCR cost?
Pricing structures vary by product, but usage-based charging tied to monthly volume is the norm. As a reference point, one AI-agent-type invoice automation solution that includes matching publishes processing from 50 yen per document. Before weighing unit prices, though, get a grip on what your current state costs. Research finds that invoice processing at companies without automation averages USD 12.88 per document and 17.4 days, which gives you a starting point for measuring your own level.
Can goods receipt work be automated as well?
Designs that automate not only purchase order capture but matching against delivery notes and invoices are genuinely available. In a case where an AI agent handles matching, allocation verification, and exception detection, the published results include a reduction in first-level approval workload of up to 100% and verification of allocation and distribution line items that previously took more than 30 minutes completing in seconds. The premise, however, is an operating design in which people review the cases flagged as exceptions rather than one in which everything runs unattended.
Can handwritten purchase orders be handled?
Products that support handwriting recognition do exist. Accuracy is more sensitive to individual writing habits and writing implements than it is for machine print, so you need to design an accompanying mechanism that routes low-confidence fields to human review. We recommend verifying with real samples before fixing the scope.
Can purchase orders in Thai be read?
Products supporting multilingual printed and handwritten recognition including Thai and Vietnamese had already published practical accuracy levels as of 2020. Being listed as a supported language and delivering the accuracy you need on your own documents are separate matters, however. If you handle purchase orders that mix Japanese and Thai, check the results language by language with your own samples.
How long does implementation take?
It varies widely with scope and integration method. One solution that includes matching publishes implementation in as little as 2 weeks, but that is a guide for cases where the target task is clearly bounded and integration requirements with existing systems are simple. Where API integration with a core system or master data cleanup is involved, allow separate time for requirements definition and verification.
Will a small site see any benefit?
Payback speed depends heavily on volume. A published case shows up to 83% time reduction on invoice processing at a scale of 300 documents a month, specifically 40 hours becoming 7 hours, which shows that mid-sized operations can see meaningful effect. At a few dozen documents a month, on the other hand, a narrowly scoped lightweight mechanism may suit better than a feature-rich solution. For companies with several sites, rolling out from the highest-volume site is the realistic path.
Summary
Converting purchase orders with AI-OCR is an area where many companies have already acted and published their results. Levels such as 3 minutes of entry per document falling to 30 seconds, or 10 hours of daily work fitting inside 3 hours, have been reproduced across multiple cases. The question worth considering now is therefore not whether the documents can be read, but how far the scope of automation should extend.
The central idea this article puts forward is to design the process with three-way matching across purchase order, delivery note, and invoice in view. If you automate only the entry step, the matching and the discrepancy investigation that pile up at month end stay exactly as they were. Design through to matching and you remove the work that weighs most heavily on your staff. Determining whether your bottleneck is entry or matching is the first step.
At a Thai site, one more axis enters that judgment. When 40.4% of Japanese-affiliated companies in Thailand face talent shortages and 72.8% cite rising labor costs as an investment-environment risk, deciding which work your people are assigned to is a management decision in its own right. Releasing local staff from simple keying and redirecting them to higher-value work is the real purpose of automation.
On that basis, at the implementation stage, work carefully through three things — mapping design for inconsistent field naming, surfacing the tacit knowledge in your current flow, and drawing the line for exception handling. Where you stop errors matters more to the success of live operation than headline accuracy does.
Whether you are just starting to evaluate purchase order OCR or have already deployed OCR and now want to revisit the process design through goods receipt and invoicing, TOMAS TECH is happy to talk things through starting from a review of your current workflow. We also welcome questions about running these operations in environments where Japanese and local languages are mixed, at sites in Thailand and across ASEAN. Consultation is available at any stage through our contact form.
References
Source: Infomart, “Purchase Order AI-OCR Case Studies”
Source: homula Inc. press release, PR TIMES, February 12, 2026
Source: Ricoh, “Received Invoice Service”
Source: AI inside, press release on multilingual support in DX Suite, PR TIMES, December 23, 2020
