FAX注文書の入力を自動化
OCR導入前に試す
7つの注文パターン

FAX注文書の入力は、AI-OCRで品番や数量を読み取り、自社の商品情報と照合してから、販売管理へ渡す流れで自動化できます。 取引先にFAXをやめてもらう前に、受信後の転記を減らす方法があります。

ただし「3箱」を正しく読めても、登録先が個数で管理していれば、そのまま「3」と入力することはできません。本記事では、架空の商品と注文データ7件を使い、単位の換算や再送・訂正の判定を実際に動かしました。OCRの読取精度は試しておらず、読み取った後の処理を検証した記事です。 入力データと処理結果を公開します。

FAX注文書の入力はどう自動化する？

「文字を読む」「商品と数量を確かめる」「販売管理に登録する」の三つをつなぎます。 AI-OCRは、紙や画像の文字を読み取り、品番・数量・希望納期などの項目に分ける部分を担います。

FAXを複合機で受けているなら、受信内容をPDFで保存できるかが最初の確認点です。紙をスキャンして試すこともできますが、毎回印刷とスキャンを挟む運用では、その作業が残ります。受信方法を変える場合は、現在のFAX番号と転送方法への影響も確認します。

すでに取引先からCSVなどのデータを受け取れる場合は、直接取り込む方法を検討できます。Web受発注で商品を選択してもらえる取引と、FAXが残る取引を分けても構いません。既存業務のどこから着手するかは、中小企業のAI導入の進め方でも解説しています。

商品コードと数量を、登録先に合わせる

注文書に書かれた値と、販売管理へ登録する値を両方残します。 担当者が確認する際に、AIが読み間違えたのか、商品や単位の変換が違うのかを切り分けられるためです。

商品名が似ていても、規格まで照合する

商品マスタは、自社の商品コード・名称・規格・入数などを管理する一覧です。注文書に取引先独自の品番が書かれる場合は、取引先と品番を組み合わせて自社コードに対応させます。同じ略称でも、取引先が変われば別の商品を指す可能性があります。

例えば「商品A」に500mLと1Lの規格があれば、名称だけでは一つに決まりません。似た名前の商品を自動選択せず、規格や過去の対応付けを確認できる状態にします。注文頻度だけでは、今回の商品を確定できません。

「3箱」と「3個」は別の数量になる

今回の架空データでは、商品Aの500mLを1箱12個、登録単位を「個」と設定しました。注文書の「3箱」は36個へ換算します。数量の数字だけを転記すると、必要な数量と登録数量がずれます。

入数は商品ごとのマスタで管理し、注文書の数量・単位、使った換算率、換算後の数量を記録します。入数が未登録、単位が空欄、小数が許されない商品で端数が出る場合は、推測で埋めず確認へ回します。包装が変わる商品では、換算ルールの適用日も管理対象です。

7つの注文パターンで処理を試した

再送や訂正を含む注文を流し、受注データを追加してよい条件を確かめました。 弊社が2026年9月10日に、この記事用の架空データを使ってローカルで実行した結果です。

OCRやFAX画像の読み取りは実行せず、人が用意した読み取り後に相当するCSVを照合しました。特定のAI製品の性能を試した結果ではありません。商品は500mLと1Lの2種類に絞り、「取引先・注文番号・明細行」が同じなら同じ注文を指すルールを、試験用に設定しました。

比較のために、あえて照合を省き、全行を追加する説明用の処理も動かしました。その処理では7件とも追加対象となり、「3箱」の数量欄も3のままでした。照合を加えた処理では、新規の下書き候補は2件となり、残り5件を理由付きで保留できました。保留件数は、読み取りの精度を示す数値ではありません。

7件の入力条件と処理結果をCSVでダウンロードできます。 仕組みを確認したい担当者向けに、架空データ・マスタ・再現用プログラムの一式も用意しました。いずれも説明用で、実際の受注システムには接続しません。

CSVは、Excelなどの取込機能で「入力コード」列を文字列に指定して開いてください。直接開くと先頭の0が消える場合があります。

同じ注文番号でも「再送」とは限らない

05と06の違いは、前に受け取った内容から数量が変わっていることです。単に「同じ注文番号は捨てる」と決めると訂正を見落とし、反対に全部追加すると二重の注文候補を作ります。元の注文と変更後の内容を並べ、担当者が訂正か追加注文かを決められるようにします。

注文番号が毎月繰り返される、訂正時に行番号が変わる、番号自体がない取引では、今回の識別ルールをそのまま使えません。取引先との運用に合わせて注文を識別し、確定できないものは照会へ回します。すでに出荷済みなら、データを直す前に出荷先や在庫への影響も確認が必要です。

今回の試験では、本番登録・複数注文の同時処理・複数明細をまたぐ訂正・在庫確認・納期回答は行っていません。また、誤読したコードが別の実在商品と一致する場合は、マスタ照合だけでは誤りを見抜けません。導入時には実際の帳票の読取試験と、承認・登録先との連携試験を別途行います。

販売管理への登録で確認すること

「送信した」ではなく、登録先の受付番号と登録内容を確認して完了にします。 処理が途中で止まったときに、入力済みなのか未処理なのかを追えることが、二重登録を避けるために必要です。

CSV・API・画面入力のどれが使えるか

まず、現在の販売管理にCSV取込やAPIがあるかを確認します。APIは、別のシステムからデータを登録・照会するための接続口です。CSVで足りるなら、登録先の列名・並び順・文字コード・日付形式に合わせて出力する方法から始められます。

取込画面では、コードの先頭の0、必須列、明細と伝票の区切りを確かめます。一部の行だけ失敗したときに、ファイル全体を取り消すのか、成功分は登録されるのかも重要です。再取込で成功済みの行まで追加されないかを、テスト環境で確認してください。

取込機能がなく画面操作を自動化する場合は、RPAなどを使う選択があります。その際は入力位置だけでなく、画面の変更、処理待ち、エラー表示を検出する仕組みまで必要になります。使っている製品の連携仕様を確認してから、方法を決めます。

登録結果が分からないときは、再送前に確認する

通信が途切れても、販売管理側では登録が終わっている場合があります。応答がない処理には「結果不明」と記録し、注文番号や受付番号で照会してから再実行する流れにします。今回のローカル試験で行った再送判定だけでは、こうした本番の二重登録まで防げません。

同じ注文を複数の処理が同時に受け取る場合も、登録先を含めた重複防止が必要です。受信原本、読取結果、担当者の修正、登録先の番号を対応付けて残します。締切前の確認待ちは代理担当へ回せるようにし、障害時に手入力へ戻した分も、自動処理と重複しない形で記録します。

既製品と追加開発をどう選ぶ？

既製品で読み取り・照合・取込まで満たせるかを先に試し、残った業務だけ追加開発を検討します。 帳票の種類、取引先別の呼び方、販売管理への接続条件を一式で確かめると、必要な範囲を絞れます。

例えば、WisOCR for 注文書は、注文書のデータ化に加え、マスタ検索による補完やCSV整形・連携を案内しています。CO-NECT AIデータ変換の公式ページには、商品マスタとの照合、単位換算、CSV出力やAPI連携の説明があります。機能があることと、貴社の注文ルールに合うことは、導入前の試験で確かめます。

ベンダーの読取精度だけで、確認作業がなくなるとは判断できません。Microsoftの文書抽出の信頼度の説明でも、抽出結果の推定値と、人による確認を含む運用が扱われています。文字を正しく読めるかと、その商品・単位で受注してよいかは別に確かめます。

費用を見積もる際は、月の注文件数に加えて、ページ数、明細行数、帳票の種類、確認が必要な割合を整理します。読み取り料金だけでなく、初期設定、マスタ整備、連携、保守に何が含まれるかを比較してください。利用料金の単位は製品によって異なるため、候補先の見積条件で揃えます。

導入前後は、転記に使う時間に加え、読み取りの修正、確認待ちの処理、マスタ更新、エラー対応の時間も計測します。単に「自動処理した枚数」が増えても、担当者の負担が減ったとは限りません。開発を依頼する場合の費用の考え方は、AI開発の費用と依頼範囲も参考になります。

まず一つの注文書式で試す

よく届く注文書式を一つ選び、通常の注文と、単位不明・再送・訂正の注文をセットで試します。 商品情報と登録先の取込仕様を揃え、担当者が完成形を確認できる下書きまで作るのが最初の到達点です。

初回の相談では、注文の受け取り方、入力しているシステム、転記後に担当者が判断することを整理すれば進められます。実際の帳票や取引先情報を共有する際は、利用目的と保存・削除の条件を確認し、必要な範囲に絞ります。項目名だけの見本や、今回のような架空データから説明する方法もあります。

「読み取れるか」に加えて、「迷った注文を誰が確認し、どこへ登録すれば完了か」まで決めておくと、試作から運用へ進めやすくなります。確認待ちや手入力への切替も含めて試し、任せられる注文から対象を広げてください。