FAX-OCRを基幹システムへ取り込む方法｜連携方式の選び方と誤読帳票の直し方

◆監修・編集責任者　小園 将隆　2026年10月5日

B2B EC-COLUMN

FAX-OCRの結果は、基幹システムにどこまで自動で取り込めるのか

取引先から届くFAXの注文書を一枚ずつ基幹システムへ打ち込んでいると、OCRで文字が読めても、品番の置き換えや取込の手前で結局は人が手を動かすのではないかと気になります。
公開されている製品情報を見ると、CSV出力やAPI連携、取引先独自の品番を自社コードへ変換する機能、読み取り結果を確認・修正する画面を備えるFAX-OCRがあります。
ただし、項目の対応づけ、品番の対応表、取込形式、誤読や例外の帳票を直す担当は自社で決めることです。
まず定型の取引先を少数選び、自社の実際のFAXで試してから広げるのが進めやすい順序です。

OCRが担う範囲と基幹側で決める範囲

ハンモックが公表した、食品の小売・卸売業の受注業務担当者を対象とする2023年のインターネット調査では、FAX・メール・電話で受注する担当者のうち60%が、注文書の「手入力」に手間がかかると答えています⁶。
業種を絞った調査なので他業種へそのまま当てはめることはできませんが、FAX-OCRが置き換えようとしているのは、まさにこの打ち込みの工程です。
一方で、打ち込みが減っても、読み取った文字を基幹システムが受け付ける受注データに変えるまでには、いくつかの段階が残ります。

公開されている製品情報では、この段階の一部をOCR側で引き受ける機能が説明されています。
LINE WORKSのPaperOnは、取引先独自の品番を自社の商品コードや規格名称へ変換する機能と、CSVダウンロードによる基幹・ERPへの取込、API連携を挙げています⁴。
CO-NECTのAIデータ変換は、整形済みCSVの出力とAPI連携、過去実績や辞書学習による商品マスタへの紐づけ、ブラウザ上での読み取り結果の修正を挙げています³。
PFUのコラムも、認識結果を後続の業務システムの仕様に合わせた形式へ変換する、データ連携を考慮した機能に触れています¹。
いずれも提供元が自社のサービスについて述べた内容で、すべてのFAX-OCRに同じ機能があるわけではありません。

では、どこに手作業が残るのでしょうか。
たとえば取引先Aから「A-102 10ケース 納期来週火曜」と書かれた注文書が届いたとします。
OCRが文字を正しく読めても、基幹システムが受注として受け付けるには、得意先コード、自社の商品コード、基幹で使う単位、納品先、決まった形式の日付などがそろっている必要があります。
「A-102」が自社のどの商品か、「ケース」を基幹の単位にどう直すか、どの列にどの値を入れて取り込むかは、OCR製品が最初から知っているものではありません。
変換機能があっても、その対応表や設定をつくり、取引先や商品が変わったときに直すのは導入する側です。

整理すると、OCR側が担えるのは読み取り、製品によってはコード変換と確認画面、そして決められた形での出力までです。
基幹側の受け口の形式、注文書の項目と基幹の項目の対応、取込のタイミング、例外の帳票を誰が直すかは自社で決めることになります。
「読めても基幹に入らないのでは」という不安は、後者が決まっていない状態で起きると考えると、手を打つ場所が見えてきます。

公開されている認識率の読み方

製品を比べるとき、認識率の数字が目に入ります。
PFUのコラムでは、同社の基準帳票を用いた検証で、従来OCRの認識率が80%だったのに対し、AI-OCRでは98%だったと紹介されています¹。
AI-OCRは、学習済みのモデルを使って文字を読み分ける方式のOCRを指します。

この98%は、PFUが用意した帳票での検証値です。
どの単位で数えた率か、どのような画質の帳票を使ったかといった検証条件の詳細までは記事から読み取れず、自社に届くFAXで同じ数字が出ることを示すものではありません。
FAXでは傾きや拡大縮小が起きることがあり、同じコラムもその補正を精度向上のポイントに挙げています¹。
取引先ごとに送ってくる原稿や機器が違えば、読み取りやすさも取引先ごとに違うと考えておくほうが安全です。

もう一つ見落としやすいのは、認識率が測っているのは文字を正しく読めたかであって、取り込んだ受注が正しいかではない点です。
取引先Aの「A-102」を一文字も間違えずに読めても、対応する自社コードが登録されていなければ基幹には入りません。
欄外に「前回分と合わせて納品」と書き添えられていれば、文字が読めても、その指示をどの項目に反映するかは人が判断します。
認識率は読み取りの工程を比べる参考値として使い、取込まで含めた手作業の量は、次に述べる取り決めと自社の試行で見積もるのが現実的です。

取り込みの前に決めておくべきこと（項目対応・コード照合・取込形式）は何か

項目対応と必須項目

最初に手を付けたいのは、注文書に書かれている項目と、基幹システムが受注データとして求める項目を並べて対応させる作業です。
注文書にあるのは取引先の言葉です。
店舗名、取引先が付けた品番、「ケース」「箱」などの単位、「来週火曜」のような納期の書き方が、そのまま並んでいます。
基幹側にあるのは自社の言葉で、得意先コード、納品先コード、自社の商品コード、基幹に登録された単位、決まった形式の日付です。

対応表をつくると、基幹の項目ごとに値の出どころが分かれることに気づきます。
数量のように注文書から読み取った値をそのまま使える項目、品番のように変換を通す項目、得意先コードのように帳票ごとに決まっていて読み取る必要のない項目、そして注文書に書かれていないため人が補う項目です。
出どころを項目ごとに決めておくと、OCRの設定で何を読ませ、何を固定値や変換に任せ、何を確認画面で人が入れるのかがはっきりします。

あわせて確かめておきたいのが、基幹側の必須項目です。
注文書には納品先が書かれていないことがあるのに、基幹では納品先が必須になっている、といった食い違いがあると、OCRが正しく読めても取込で止まります。
必須項目が空のときに基幹がどう扱うかは基幹の取込仕様によって違うため、空になりうる項目を洗い出し、その場合の補い方を先に決めておくと、取込エラーの原因を一つ減らせます。

取引先独自の品番を自社コードにそろえる

手入力のときに担当者が頭の中でしていた置き換えを、仕組みに移す必要があるのが品番です。
取引先Aの「A-102」が自社の「100345」だと分かっているのが、長く入力してきた担当者の記憶や手元の一覧だけ、という職場では、この置き換えをどこに持たせるかが取込の成否を左右します。

OCR製品の側では、この置き換えを手伝う機能が説明されています。
LINE WORKSのPaperOnは、マスターデータ変換機能で取引先独自の品番を自社の商品コードや規格名称へ変換できるとしています⁴。
CO-NECTのAIデータ変換は、過去の実績に基づく紐づけと、事前に登録した内容の辞書学習による紐づけを挙げています³。
変換の仕組みや当たりやすさは製品によって異なるので、同じ「コード変換」と書かれていても、どの情報をもとに紐づけるのかを確かめて比べる必要があります。

どの方式でも、対応のもとになる情報を整えるのは自社です。
取引先ごとの品番と自社コードの対応を誰がまとめて登録するか、新商品の追加や取引先の品番変更があったときに誰が更新するかを決めておかないと、運用を始めてから未登録の品番が少しずつ増えていきます。
たとえば取引先Aが新しく「A-103」を発注してきたとき、受注担当者が確認画面で気づき、商品マスタを管理する担当へ登録を頼む、という流れを決めておけば、その一件を手で直したうえで、次回からは変換に任せられます。
対応表の更新を受注担当者が一人で抱えるのか、マスタ管理の担当と分けるのかは、品番の増え方と社内の分担で選んでよい部分です。

取込形式と基幹側の受け口の確認

OCRから出すデータの形は、基幹システムの受け口に合わせることになります。
CSVで受ける基幹なら列の並びや見出し、日付や数値の書き方、文字コードが決まっていますし、APIで受けるなら受け付ける項目と値の形式が決まっています。
OCR側で出力の形を整えられても、目標となる形は基幹側の取込仕様書や提供元への問い合わせで確かめるしかありません。

仕様を確かめるときは、形式に加えて、うまくいかなかったときの動きを見ておくと運用を決めやすくなります。
一つは、登録されていないコードが含まれていたときに、その行だけをはじくのか、ファイル全体を止めるのか。
もう一つは、取込でエラーが出たときに、どの行がなぜ止まったかを担当者が確認できる形で返ってくるか。
そして、同じ注文を二度取り込んでしまったときに、基幹側で重複を検知する仕組みがあるかどうかです。

これらは基幹ごとに違い、どれが正解ということはありません。
ただ、答えによって確認の置き方が変わります。
一件の誤りでファイル全体が止まる基幹なら、取込前の確認を厚くして、まとめて取り込む前に疑わしい帳票を外しておく運用が向きます。
行単位ではじく基幹なら、取込後にエラーの行だけを直して入れ直す運用も選べます。
重複の検知がない場合は、その日に受け取ったFAXの枚数と取り込んだ受注の件数を突き合わせるなど、二重取込を人が防ぐ手順を足すことになります。

基幹への連携方式はどう選べばよいか（ファイル取込・API・RPA・標準機能）

CSV・データベース出力・APIの違い

取り決めが見えてきたら、OCRの結果を基幹へ渡す方法を選びます。
公開情報で確認できる出力方法は、大きく分けてファイル、データベースへの直接出力、APIの三つです。

CSVファイルは、OCR側が受注データを表形式のファイルに書き出し、それを基幹のファイル取込機能で読み込む方法です。
LINE WORKSのPaperOn、CO-NECTのAIデータ変換、ハンモックのTeleFormのいずれも、CSV出力を挙げています⁴³²。
基幹にファイル取込の機能があれば、連携のための仕組みを新たに作り込まなくても始めやすい形です。
出力と取込の間に人の操作が入るので、取り込む前にファイルを見直す余地が自然に残る一方、取り込む作業そのものは毎回発生します。

データベースへの直接出力は、OCRの結果を基幹が使うデータベースへ書き込む方法です。
TeleFormは、CSV出力に加えて、MS SQL ServerやOracleなどのデータベースへODBC経由で直接出力できるとしています²。
ODBCは、異なるソフトからデータベースへ接続するための共通の手順です。
取込操作が要らなくなる反面、基幹の画面や取込機能を通らずに値が入る構成では、基幹側の入力チェックが働くか、どのテーブルへの書き込みが許されるかを基幹の提供元と確かめておく必要があります。
これはTeleFormの仕様として記載されている方式で、他の製品にも同じ出力先があるとは限りません。

APIは、システム同士が決められた形でデータをやり取りする窓口です。
LINE WORKSのPaperOnとCO-NECTのAIデータ変換がAPI連携を挙げており⁴³、基幹側が外部からの受注登録を受け付けるAPIを持っていれば、確認を終えたデータを送るところまでつなげられます。
基幹の受け口に合わせた連携処理を用意する必要があり、送った時点で基幹へ入るので、確認は送る前にOCR側で済ませておく前提になります。

このほか、OCRサービスの側で特定の基幹との連携を用意している場合もあります。
CO-NECTは、CSV出力やAPI連携によって主要な基幹・会計システムと連携できるとしていますが³、どの基幹が対象かは紹介ページからは分からないため、自社の基幹と版が対象に入るかを提供元に確かめることになります。

RPAを選ぶときの条件

基幹にファイル取込もAPIもない場合、候補に挙がるのがRPAです。
RPAは、人がパソコンで行う画面操作をソフトに覚えさせ、代わりに実行させる仕組みで、基幹の入力画面へ受注データを打ち込ませる使い方ができます。
基幹側に手を入れずに済む点は魅力ですが、条件があります。

アスピック編集部の記事は、RPAで多数のフォーマットに対応させるのは、初期構築とその後のメンテナンスの両面で負担が大きく、現実的ではないとしています⁵。
取引先ごとに注文書の書式が違うまま、その違いをロボットの手順で吸収しようとすると、書式の数だけ手順が増え、取引先が書式を変えるたびに直すことになります。
RPAを使うなら、帳票の違いはOCR側で吸収し、項目のそろったデータを基幹へ打ち込む部分だけをロボットに任せる、という役割分担が考えやすい形です。

その形でも、ロボットは画面の並びや操作手順に沿って動くため、基幹の画面が変わったときには手順の修正が要ります。
入力の途中でエラーが出たときに、ロボットがどこで止まり、どの注文まで入ったかを誰が確かめるかも決めておく必要があります。
対象の帳票を定型のものに絞り、件数の多い取引先から始めると、この保守の範囲を見通しやすくなります。

条件別の検討順

方式に優劣を付けるより、自社の基幹が何を受け付けるかから順に確かめるほうが迷いません。
出発点は、いまの基幹に受注データのファイル取込機能があるかどうかです。
あればCSVでの連携が土台になり、取込前に人がファイルを見直す工程を置きやすいので、運用を固めていく段階に向いています。

CSVでの取込操作そのものが負担になるほど件数が多い、あるいは受注を早く基幹へ反映したいという事情があれば、APIやデータベースへの出力を検討します。
この場合は確認をOCR側で終えてから流す運用が前提になり、基幹の提供元にどの受け口を使ってよいかを確かめる工程が加わります。

どちらの受け口もなければ、RPAで入力の部分を任せるか、基幹の提供元に取込の手段を相談するかの選択になります。
費用や工数は基幹の構成と提供元の条件で変わるので、候補ごとに見積もりを取り、確認の置き場所と保守の担い手まで含めて比べると判断しやすくなります。

誤読や照合エラーの帳票は、誰がどこで確認・修正するのか

確認画面の種類

取込前の確認で何をどう見るかは、確認画面のつくりで変わります。
公開情報からは、少なくとも二つの方向の画面が読み取れます。

一つは、疑わしい文字だけを集めて見せる画面です。
TeleFormには、要再検査となった文字だけを切り出し、一文字ずつ並べて確認できる「キャラクターモード」があると説明されています²。
数量や品番の数字のように、一文字の読み違いが受注の中身を変える箇所を手早く見比べたいときに向いた考え方です。

もう一つは、帳票ごとに読み取り結果の全体を見て直す画面です。
CO-NECTのAIデータ変換は、読み取り結果をブラウザ上で編集・修正し、内容を確認したうえで受注データにするとしています³。
品番と数量の組み合わせが普段の注文と比べて不自然ではないか、といった帳票全体の文脈は、こちらの見方のほうが確かめやすくなります。

ここで分けて考えたいのが、読み違いと照合エラーの違いです。
TeleFormは、特性の異なる二つのOCRエンジンの結果が一致した場合だけを正しい結果として採用する方式を説明しています²。
これは読み取りの確からしさを高める工夫で、読んだ品番が自社の商品マスタにあるかどうかを確かめるものではありません。
文字は正しく読めているのに、対応するコードが未登録で取り込めない、という帳票は読み取りの精度とは別に起きるので、確認の工程も別に用意しておく必要があります。

手書き・欄外メモなど自動化しにくい帳票

FAXの注文書には、印字された欄のほかに手書きの追記が入ることがあります。
アスピック編集部の記事は、手書き文字や欄外メモの自動転記には対応できない場合がほとんどで、イレギュラーな対応には目視での補正や内容確認などの人手が要るとしています⁵。
一方、CO-NECTのAIデータ変換は手書きの注文書にも対応するとしており³、手書きの読み取りを扱う製品もあります。

この二つを並べると、手書きの扱いは二つに分けて考えるのが実務的です。
決まった欄に手書きで数量や品番を書く場合は、読み取りの対象になりえます。
欄外に「A-102は先週分と合わせて納品」「午前着希望」と書き添えるような場合は、文字が読めても、それは受注の項目ではなく担当者への依頼です。
どの項目にどう反映するかは文脈の判断になるため、自動で取り込む対象から外し、人が読む区分へ回すほうが扱いやすくなります。

そこで、欄外の書き込みや訂正のある帳票は、読み取りの結果にかかわらず受注担当者が目を通す、と決めておく方法があります。
取引先との普段のやり取りを知っている人が見るほうが、追記の意味を取り違えにくいためです。
書き込みの多い取引先が分かってきたら、決まった欄へ書いてもらえないか相談するのも一つの手です。

取込前後のチェックの置き方

ここまでの確認を、取込の前後に並べ直してみます。
取込前に置くのは三つです。
まず、OCRが疑わしいとした文字や、数量・納期の数字を確かめる読み取りの確認。
次に、品番が自社コードに変換できたか、必須項目が空になっていないかを見る照合の確認。
そして、欄外メモや手書きの追記がある帳票を、人が読む区分へ分ける確認です。

取込後には、基幹が返す取込結果を見て、はじかれた行と理由を確かめます。
あわせて、その日に受け取ったFAXの枚数と基幹に入った受注の件数を突き合わせれば、取り込み漏れや二重取込に気づく手がかりになります。
二重取込を基幹側で防げるかどうかは基幹の仕様によるので、その仕組みがない場合はこの突き合わせを日々の手順に含めておきます。

担当の分け方は一つの提案ですが、読み取りの確認と欄外メモの判断は取引先を知る受注担当者、未登録コードの登録は商品マスタを管理する担当、取込結果の確認は取込操作をする人、と分けると、どこで何を見落としたのかを後から追いやすくなります。
この運用で変わるのは、注文書のすべての項目を打ち込む作業が、印の付いた箇所と例外の帳票を確かめる作業に置き換わる点です。
確認そのものがなくなるわけではないので、どの程度軽くなるかは、自社の帳票を使った試行で確かめることになります。

最初にどの取引先・帳票から試し、何を見て本格導入を判断するか

試す取引先と帳票の選び方

試行では、すべての取引先を一度に対象にしないことが大切です。
取引先と書式が多いまま始めると、読み取りの精度、コードの未登録、欄外メモのどれが原因で手作業が残ったのかを切り分けにくくなるからです。
最初は、毎回同じ書式で届き、印字が中心で、件数がある程度まとまっている取引先を少数選びます。
結果が良ければ似た書式の取引先へ広げ、うまくいかなければ原因を絞り込む、という順序を取れます。

試行の入口は、本番と同じ受け取り方にそろえます。
PFUのコラムは精度を上げるポイントとして、FAXに対応したAI-OCRを使うこと、FAXの紙をスキャンせず複合機の受信データをそのまま使うこと、傾きや拡大縮小を補正することを挙げています¹。
同社製品を前提にした説明ですが、試行のときだけ紙をスキャンしてOCRにかけ、本番では受信データを使う、といったずれがあると、試行の結果を本番の見込みとして使いにくくなります。

製品によっては、自社の実際のFAX帳票で精度を検証できる無償トライアルが用意されています⁴。
期間や枚数などの条件はサービスごとに異なるので、使える枚数の中で、選んだ取引先の数週間分の注文を流せるかを見て計画を立てると、結果のぶれを抑えやすくなります。

試行で記録する項目

試行で記録したいのは、手作業がどこに、どれだけ残ったかです。
帳票ごとに、読み違いがあった項目と件数、自社コードへ変換できなかった品番の件数、欄外メモや手書きで人が読む区分へ回した件数、確認と修正にかかった時間、取込でエラーになった件数とその理由を残しておきます。

件数を原因ごとに分けて残すのは、直し方がそれぞれ違うからです。
読み違いが多ければ、受信経路や補正の設定、取引先の原稿の状態を見直す話になります。
未登録の品番が多ければ、OCRの精度ではなく対応表の整備が追いついていないことを示します。
欄外メモが多ければ、確認の区分を厚くするか、取引先に書き方を相談するかを考えます。
原因を分けずに「手直しが多かった」とだけ残すと、どこを直せば次の試行で減るのかが見えません。

確認にかかった時間は、いまの手入力と比べるための記録です。
試行を始める前に、同じ取引先の注文書を手で入力するのに一件あたりどれくらいかかっているかを測っておくと、比べる相手ができます。
誤読の修正や未登録コードの対応に時間がかかった帳票は、時間とあわせて理由も書き添えておくと、本格導入を判断するときの材料になります。

本格導入に進む前の確認事項

試行の結果から本格導入に進むかを決める基準は、自社で先に決めておきます。
誤読の件数や確認時間がどこまで下がれば進めるか、という一律の目安は示しにくく、取引先の数や書式の違い、受注の締め時刻によって許容できる範囲が変わるためです。
試行の前に「確認時間が手入力より短いこと」「未登録コードの対応が担当者の手に負える件数であること」のように自社の言葉で条件を書いておくと、結果を見たときに判断がぶれません。

試行の結果によっては、OCRと基幹連携まで進めないという判断もありえます。
アスピック編集部の記事は、入力件数が多くない場合や、注文内容が毎回異なり都度確認が要る場合には、FAXをインターネットで受信できれば足りる場合があるとしています⁵。
確認の手間が手入力とほとんど変わらない取引先が多いなら、まずは受信の電子化で紙の扱いを減らし、定型の取引先だけをOCRの対象にする、という分け方もできます。

進める場合は、試行で見えた取り決めを本番の運用に書き起こします。
基幹の取込仕様のうち、未登録コードの扱い、エラー時の止まり方、重複の検知を提供元に確かめた結果、品番の対応表を更新する担当と頻度、例外の帳票を見る担当と時間帯です。
これらがそろっていれば、取引先を増やすときも、新しい取引先の品番を対応表に足し、その書式を試すところから同じ手順で広げられます。

項目の対応や品番の対応表、基幹の取込仕様は、注文書と基幹の両方を見比べないと、手作業が残る場所が見えにくい部分です。

手元のFAX注文書と基幹の取込項目を並べ、どの項目がOCR側で埋まり、どこに確認が残りそうかを整理できます。無料相談で要件を整理する

要点の整理

軸	基準
自動化の範囲	読み取り・コード変換・出力は製品機能。項目対応・品番の対応表・取込形式・確認担当は自社で決める
認識率	公開値は提供元の基準帳票での参考値。取り込んだ受注の正しさや未登録コードは測っていない
連携方式	基幹にファイル取込があればCSVが土台。APIやデータベース出力は提供元に確認、RPAは入力部分に絞る
確認の置き方	読み違い・照合エラー・欄外メモを取込前に分け、取込後はFAX枚数と受注件数を突き合わせる
試行	定型の取引先を少数、本番と同じ受信経路で、原因別の件数と確認時間を手入力と比べる

試行で何を記録し、どの条件で本格導入に進むかは、始める前に決めておかないと結果の読み方がぶれます。 対象にする取引先の選び方、試行で残す記録、判断の条件を、自社の受注の流れに合わせて整理できます。

よくある質問

FAXの紙を複合機でスキャンしてOCRにかけても精度は変わらないのか

変わる可能性があります。
PFUのコラムは精度向上のポイントとして、FAXの紙をスキャンせず複合機の受信データをそのまま使うことと、傾きや拡大縮小を補正することを挙げています¹。
どの程度変わるかは帳票と機器によるため、試行では本番と同じ受け取り方で確かめるのが確実です。

取引先ごとにFAXの書式が違う場合でもOCRと基幹連携は成り立つのか

成り立ちますが、書式の違いをどこで吸収するかで手間が変わります。
CO-NECTのAIデータ変換は取引先ごとの独自フォーマットに対応するとしています³。
一方、RPAで多数の書式に合わせ込むのは構築と保守の負担が大きいとされます⁵。
書式の違いはOCR側で吸収し、基幹へ渡す形は一つにそろえると考えやすく、導入初期は定型の取引先から始めると原因の切り分けがしやすくなります。

OCRで読み取ったデータを確認せずに基幹へ自動取込してよいのか

文字が正しく読めても、未登録コードや欄外メモのように認識率では測れない例外が起きるため、少なくとも運用の初期は取込前の確認を置くことをおすすめします。
CSVで取り込む形なら取込前にファイルを見直す工程を置きやすく、APIやデータベースへの直接出力では出力前にOCR側で確認を終える前提になります。
確認を減らすかどうかは、試行で例外の件数と種類を見てから判断するのが安全です。

基幹側に取込機能がない場合は、どの連携方式から検討すればよいのか

まず基幹の提供元に、ファイル取込やAPIなど外部から受注を登録する手段があるかを確かめます。
手段がない場合は、RPAで基幹の入力画面に打ち込ませる方法が候補になりますが、画面の変更に合わせた保守が要り、多数の書式に合わせ込むのは負担が大きいとされます⁵。
データベースへ直接出力できる製品もありますが²、基幹側の入力チェックを通らない構成になりうるため、提供元と書き込みの可否を確かめてから検討します。

手書きの注文書や欄外メモはどう扱えばよいのか

決まった欄への手書きは、手書きに対応する製品であれば読み取りの対象になります³。
欄外のメモや追記は自動転記に対応できない場合がほとんどとされ⁵、内容も受注項目というより担当者への依頼の性格を持ちます。
書き込みのある帳票は受注担当者が目を通す区分へ回す、と決めておくと扱いが安定します。

FAX-OCRの導入前に、自社の帳票で何を試せばよいのか

定型の取引先を少数に絞り、本番と同じ受信経路で、数週間分の実際の注文書を流してみます。
帳票ごとに読み違い、未登録コード、欄外メモで人が読んだ件数、確認にかかった時間、取込エラーを原因別に記録し、事前に測った手入力の時間と比べます。
基幹の取込仕様のうち、未登録コードの扱いやエラー時の止まり方もこの時点で確かめておくと、本格導入の判断がしやすくなります。

1. 1　出典：株式会社PFU(リコーグループ)「FAX注文書はOCRできる？精度を向上させる3つのポイント(デジタラクル コラム)」（2025年）
2. 2　出典：株式会社ハンモック「TeleForm FAX OCR受注ソリューション」
3. 3　出典：CO-NECT「AIデータ変換（FAX・メール・PDFの注文書をデータ化）」
4. 4　出典：LINE WORKS株式会社「FAX注文書の入力負担をAI-OCRで軽減！受注業務をデジタル化する方法」（2026年）
5. 5　出典：アスピック編集部「FAXによる受注業務を効率化！クラウドやRPAで自動化する方法」（2025年）
6. 6　出典：株式会社ハンモック(IDEATECH「リサピー」企画のインターネット調査)「食品業の受注業務に関する実態調査」（2023年）