FAX-OCRの注文書を基幹に取り込む方法｜連携方式・取込形式の選び方と残る作業

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

B2B EC-COLUMN

FAX注文書の手入力から抜け出す前に、まずOCRの出力と基幹の入口をつなぐ

取引先から届いたFAX注文書を見ながら、品番・数量・納期を基幹システムの受注画面へ打ち込む。
この転記で入力ミスや入力待ちが出ているなら、FAX-OCRは導入候補になります。
ただし、OCRが担うのは紙の文字をデータに変えるところまでです。
そのデータが基幹の取込形式に合わなければ、画面への打ち込みは残ります。
確認できた製品資料では、OCRの結果はCSVなどのファイルかAPIで渡す形が基本です。
読取精度を比べる前に、基幹が何を受け付けるかと項目の対応を決めてください。
そのうえで、読取誤りの確認作業を自社の注文書で試して見積もるのが近道です。

OCRが代わるのは「読む」まで

手入力の流れを分けると、作業は三つです。
FAXを受け取る、紙を見て注文の中身を読む、基幹システムの受注画面に品番・数量・納期・取引先を打ち込む、の三つです。
FAX-OCRが代わりに担うのは、このうち二つ目の「読む」部分です。
紙の上の文字はテキストデータになりますが、その時点ではまだ基幹システムの外にあり、受注として登録されたわけではありません。

読んだデータを基幹へ入れる部分について、提供元のPFUは次のように説明しています。
認識したテキストデータを後続の業務システムに連携したり、出力結果をシステムに合わせた形式へ変換したりできると、連携がスムーズになるという説明です¹。
同社は2025年の発表で、AI-OCR製品DynaEye 11に出力データ変換の機能を加え、OCR結果を後続システムに合う形式へ変換できるようにしたとしています⁵。
これは一製品の説明であり、どのOCR製品にも同じ変換機能があるわけではありません。
ただ、提供元自身が「読んだ後の形を基幹に合わせる工程」を別に用意している点からも、読取と連携は別の課題だと分かります。

精度より先に入口を決める理由

導入を検討し始めると、まず読取精度の比較に目が向きがちです。
しかし、どれだけ正しく読めても、出てきたデータの列の並び、項目名、コードの形が基幹の取込条件と合わなければ、担当者は結局そのデータを見ながら受注画面へ打ち直すことになります。
反対に、読取誤りが一定数あっても、確認画面で直したデータがそのまま基幹へ入るなら、打ち込み作業はなくなります。
その場合、仕事は確認と修正に置き換わります。

つまり、手作業がどれだけ減るかをまず左右するのは、基幹の入口に合う形で渡せるかどうかです。
精度はその次に、確認作業の量を左右します。
この順番で考えると、最初に集めるべき情報が見えてきます。
OCR製品のカタログより先に、自社の基幹システムが外部からどんなデータを受け付けるかを把握する必要があります。

▼ 図の内容を文字で読む

1. FAX受信（複合機の受信データ）
2. OCRで読み取り、テキスト化
3. 確認・修正（人の作業が残る）
4. 基幹の取込形式へ変換
5. 基幹へ取込（エラーは人が処理）

基幹に渡す方法は何があるか：ファイル出力・API・RPA

CSV・TEXTなどのファイル出力

読み取ったデータを基幹へ渡す方法は、主に三つが候補になります。
ファイルとして出力して基幹に取り込ませる方法、プログラム同士をつなぐAPIで渡す方法、人が画面に打ち込む操作をRPAに代行させる方法です。
どれを選べるかは、OCR製品が何を出せるかと、基幹が何を受け付けるかの両方で決まります。

最も始めやすいのは、読取結果をファイルに書き出す方法です。
DynaEye 11は認識結果をCSV、TEXT、ACCESS形式で出力できます。
既存システムと連携させるために、CSVやテキストの出力形式を変換することもできると案内されています²。
AI insideのDX Suiteも、出力はCSV形式だと説明しています⁴。
CSVは項目をカンマで区切って一行に並べたテキストファイルで、業務システムの取込によく使われる形式です。

基幹側に受注データの一括取込やCSV取込の機能があれば、OCRが出したファイルをその機能で読み込ませることで、受注画面への打ち込みをなくせます。
基幹を改修せずに始めやすいのが、この方法の利点です。
一方で、出力したファイルを決まった場所へ置き、取込を実行するといった操作が人に残る場合があります。
一日に何回取り込むかによっては、受注の反映も遅れます。
取込を自動で定時実行できるかどうかは、基幹側の機能によります。

API連携

API（アプリケーション・プログラミング・インターフェース）は、システム同士が決められた手順でデータを受け渡すための窓口です。
DX SuiteはAPIを無償で提供しています。
スキャンからOCR、データ出力、基幹システムへの取込までの流れを自動化できるという説明です⁴。
PFUは、DynaEye 11のSDK版を、システムへ組み込むための開発キットとして案内しています³。

APIやSDKを使うと、人がファイルを取り込む操作を挟まずに、読取から登録までをつなげられます。
ただし、OCR側にAPIがあるだけでは基幹にはつながりません。
基幹側にもデータを受け取る口が必要です。
それがなければ、間に立つプログラムを作る必要があり、開発や基幹の改修を引き受ける体制が前提になります。
自社に開発担当がいない場合は、基幹の保守を担うベンダーに頼めるかどうかが、この方法を選べるかの分かれ目です。

RPAで基幹に入力する方法

RPA（ロボティック・プロセス・オートメーション）は、パソコン上で人が行う画面操作を、ソフトウェアのロボットに記録・再現させる仕組みです。
基幹にCSV取込もAPIもなく、改修も難しい場合に使えます。
OCRで読んだデータを受注画面へ打ち込む操作そのものを、ロボットに任せるという考え方です。
基幹の中身に手を入れずに済むのが利点です。

その代わり、ロボットは画面の項目配置や操作手順に合わせて作ります。
そのため、基幹のバージョンアップなどで画面が変わると、手順の作り直しが要ります。
OCR製品とRPAをどうつなぐかは、製品の組み合わせごとに異なります。
ここで参照した製品資料には具体的な仕様の記載がないため、OCRとRPAの両方の提供元に確かめる必要があります。
ファイル取込やAPIが使えない場合の手段と位置づけるのが現実的です。

▼ 図の内容を文字で読む

• ファイル出力
  • 基幹にCSVなどの取込機能がある
  • ファイルを置いて取込を実行する操作が残る場合がある
• API連携
  • 基幹にデータを受け取る口がある、または改修できる
  • 開発・改修の体制が前提になる
• RPA
  • 取込口がなく改修も難しい場合に使う
  • 画面が変わると手順の作り直しが要る

自社の基幹が受け付ける取込形式を、導入前にどう確認するか

取込形式・文字コード・必須項目の確認項目

OCR側が何を出せるかは製品資料で分かります。
しかし受け取る基幹側の条件は、使っている基幹システムや設定によって違います。
同じ販売管理システムでも、取込機能をオプションで追加しているか、項目をどう設定しているかで、受け付けるデータは変わります。
そのため基幹側の条件は一般論では決まりません。
自社の基幹の取込仕様書を見るか、保守ベンダーに問い合わせて確かめることになります。

問い合わせる際は、次の点を具体的に聞くと、OCRの出力と合うかどうかを判断しやすくなります。
いずれも、合わないとファイルが読み込めないか、読み込めても誤った受注になる点です。

<ul><li>受注を外部から取り込む機能の有無と、取り込める形式（CSV、固定長テキストなど）</li><li>文字コード（Shift_JIS、UTF-8など）と、区切り文字・見出し行の扱い</li><li>必須項目と、空欄のときの扱い</li><li>取引先・品番を基幹のコードで渡す必要があるか、名称でも受け付けるか</li><li>日付や数量の書式（年の表し方、単位、小数の扱い）</li><li>1件の注文を、見出し部分と明細行でどう表すか</li><li>エラーがあったとき、全件が止まるのか、誤りのある行だけが残るのか</li><li>取込を自動で定時実行できるか、人が操作するか</li></ul>

最後の二つは見落とされやすい点です。
エラーの扱いは、導入後に誰がどこでエラーを直すかを左右します。
取込の実行方法は、FAXが届いてから受注が基幹に反映されるまでの時間を左右します。
文字コードが合わずに品名が文字化けする、日付の書式が違って納期が読み込めないといった不一致は、出力側の設定で直せる場合もあります。
ただ、どの書式に合わせるべきかは、基幹側の仕様を見ないと決められません。

OCRの読取項目と基幹項目の対応表

基幹側の条件が分かったら、注文書から読む項目と基幹が受け取る項目を、一行ずつ対応させた表を作ります。
この表は、OCR製品の設定と基幹の取込設定をつなぐ設計図の役割を持ちます。
この段階で、注文書には書かれているが基幹に入れない項目や、基幹では必須なのに注文書にはない項目が見えてきます。

製造業の受注で特に差が出やすいのは、品番と取引先の表し方です。
たとえば、取引先の注文書には取引先側の部品番号が書かれ、自社の基幹は自社品番で管理しているとします。
この場合、OCRが部品番号を正しく読んでも、そのまま基幹へ渡せば品番の不一致になります。
取引先側の番号を自社品番に置き換える変換表を、OCR側・基幹側・間に挟む仕組みのどこで持つかを、対応表の段階で決めておく必要があります。
注文書の社名から基幹の取引先コードを引く処理や、「10/15」のような納期の書き方を基幹の日付形式へ直す処理も、同じようにどこで行うかを決めます。

OCR側で形式を調整できる範囲も確かめます。
DynaEye 11の出力データ変換は、OCR結果を後続システムに適した形式に変換する機能として発表されています⁵。
必要な調整が項目の並べ替えや書式の変換で足りるのか、コードの置き換えまで要るのかで、製品側の設定で済むか、別の仕組みを用意するかが分かれます。
対応表を持って製品の提供元に相談すれば、その場で可否を確かめやすくなります。

▼ 図の内容を文字で読む

• 取込の方法
  • 受注を外部から取り込む機能の有無と取り込める形式
  • 自動で定時実行できるか、人が操作するか
• データの書式
  • 文字コードと、区切り文字・見出し行の扱い
  • 日付や数量の書式
• 項目の持ち方
  • 必須項目と、空欄のときの扱い
  • 取引先・品番をコードで渡すか、名称でも受け付けるか
  • 1件の注文を見出し部分と明細行でどう表すか
• エラーの扱い
  • 全件が止まるのか、誤りのある行だけが残るのか

取引先ごとに帳票が違う場合の読取設定

帳票定義を作る方式

対応表で基幹側の項目が決まっても、取引先が違えば、品番欄が注文書のどこにあるかは変わります。
インプローブは、製造業の受注データは業界や取引先によって形式が混在していると説明しています⁶。
読取設定の持ち方には二つの方式があります。
取引先の書式ごとに読む位置を決めておく方式と、書式を問わず項目を自動で見つけさせる方式です。

一つ目は、帳票ごとに「この位置の欄は品番、ここは数量」という定義を作る方式です。
DynaEye 11では、定型帳票向けのStandardがこれに当たり、きめ細かな読取設定ができると案内されています³。
1つのキャビネット（帳票定義をまとめる単位）の中に複数の帳票定義を作れます。
そのうえで、レイアウトや帳票上のIDの判別によって、届いた注文書に合う定義を自動で選ぶこともできるとされています²。
取引先ごとに定義を用意しておけば、届いたFAXを毎回仕分けて設定を選ぶ手間は避けられます。

この方式では、一度定義を作れば、その書式の注文書では読む位置が決まっています。
そのため、項目の取り違えは起きにくいと考えられます。
その代わり、定義を作る作業は取引先の書式の数だけ発生します。
取引先が注文書の書式を変えれば、定義の修正も要ります。
取引先が少なく、書式が長く変わらない受注に向いた考え方です。

項目を自動抽出する方式

二つ目は、書式ごとの定義に頼らず、注文書の中から品番や数量にあたる項目を自動で見つけさせる方式です。
DX Suiteは、生成AIで対象項目を自動抽出し、フォーマットが統一されていない非定型の書類にも対応すると説明しています⁴。
DynaEye 11でも、請求書や注文書などの非定型帳票向けにEntryという別の版が用意されています³。

この方式なら、取引先が増えるたびに定義を作る手間を減らせる見込みがあります。
一方で、どの欄を何の項目として読んだかは機械が判断します。
そのため、値が正しく読めているかに加えて、正しい欄を拾っているかも確認の対象になります。
たとえば注文書に「納期」と「出荷予定日」が並んでいれば、どちらを納期として拾ったかを見る必要があります。
設定の手間を減らす代わりに、確認の手間が増える可能性があるという関係です。

ここで示した特長は、どちらも提供元の説明です。
自社の取引先の注文書をどこまで読めるかが保証されているわけではありません。
取引先の数と書式の安定度で方式の向き不向きを考え、実際の注文書で試して確かめるのが確実です。
書式の安定した取引先は定義型で読み、書式が頻繁に変わる取引先だけ別に扱うといった組み合わせも考えられます。
ただし、その運用が製品や版の組み合わせで実現できるかは、提供元に確かめる必要があります。

▼ 図の内容を文字で読む

• 帳票定義型
  • 取引先の書式の数だけ定義を作る
  • 確認では読んだ値が正しいかを見る
  • 取引先が少なく書式が安定した受注に向く
• 自動抽出型
  • 書式ごとの定義を減らせる見込みがある
  • 確認では値に加えて正しい欄を拾ったかも見る
  • 取引先が多く書式がばらばらな受注に向く

読取誤りは必ず残る：確認・修正の段階と、FAXの画質条件

認識率98%をどう受け止めるか

どちらの方式を選んでも、読取誤りがなくなるわけではありません。
PFUのコラムによると、同社の基準帳票を使ったFAX注文書で、従来OCRの認識率は80%、AI-OCRでは98%でした¹。
この数値は、2025年のコラムに掲載された、PFUが用意した基準帳票での検証結果です。
手書きの有無、取引先ごとの書式、受信したFAXの汚れ方が違う自社の注文書で、同じ率になることを示すものではありません。

数値が高くても確認が必要なのは、受注データでは一文字の誤りが重い結果につながるからです。
数量の「1」と「7」、品番の「0」と「O」を取り違えれば、誤った受注のまま生産や出荷の手配に進みかねません。
DynaEye 11のFAQでも、OCRは100%ではないため確認・修正作業が必要だとしています。
そのうえで、VerifyOCRという機能で確認の負荷を抑えるとしています²。
DynaEye 11のStandardとEntryには、どちらもレイアウトを調整できる確認・修正画面があると案内されています³。
導入の目的は確認をなくすことではありません。
打ち込む作業を、画面上で見比べて直す作業へ変えることだと捉えておくと、期待と実際のずれが小さくなります。

FAXの画質で精度が変わる

FAX注文書の読取精度は、OCR製品の性能だけでなく、画像をどう渡すかにも左右されます。
PFUのコラムは、受信して印刷したFAX用紙をスキャンし直すのではなく、複合機が受信したデータをそのまま使うことを基本としています。
そのうえで、FAXに対応したAI-OCRを使うこと、傾きや拡大縮小を補正することを、精度向上のポイントに挙げています¹。
受信データを直接OCRへ回せれば、印刷とスキャンの手間も省けます。
そうした経路を作れるかが、最初の確認事項になります。

受信から読取までを、一つの製品で賄えるとは限りません。
DynaEye 11 Entryは、FAX入力に近い低品質の画像でも高精度に読めるとしています。
一方でFAXの受信機能は持たないため、専用のFAX-OCRシステムが推奨される場合があると説明しています²。
同製品は2025年の機能強化で、ドットプリンターの印字やFAXの活字への対応を加えたと発表されています⁵。
複合機の受信データをどこへ保存し、OCRがそれをどう拾うかという受け渡しの部分は、複合機とOCR製品の組み合わせで確かめる必要があります。

確認と修正はどの段階で行うか

読取誤りや不一致を見つける機会は、一か所ではありません。
まず、OCRの確認・修正画面で、読み取った値と注文書の画像を見比べて直します。
次に、基幹へ取り込むときに取込エラーになることがあります。
取引先コードや品番が基幹のマスタ（取引先や品目の基本情報を登録した台帳）にない、必須項目が空欄といった理由です。
さらに、取り込まれた受注を通常の受注確認の流れで見直す段階もあります。

品番や取引先コードがマスタと合わないケースは、読取誤りとは別に起こります。
正しく読めていても、取引先が新しい部品番号を使い始めた、変換表に登録がないといった理由で一致しないからです。
OCR製品側でマスタと自動照合できるかは、製品ごとに確かめる必要があります。
照合できない場合は、確認画面で人が突き合わせるか、基幹の取込エラーで拾うことになります。
どの段階で誰が見つけて直すかを決めておかないと、エラーになった注文が取り込まれないまま残り、受注漏れにつながります。

▼ 図の内容を文字で読む

1. OCRの確認・修正画面で値と注文書の画像を見比べる
2. 基幹への取込でマスタにない品番や空欄の必須項目がエラーになる
3. 取り込まれた受注を通常の受注確認で見直す

条件別に連携方法を選ぶ：基幹改修の可否、帳票の種類数、確認作業の許容量

基幹の受け口が渡し方を決める

ここまでの内容を、自社の条件に当てはめて整理します。
渡し方は、基幹がどんな受け口を持つかで、検討する順番がほぼ決まります。
基幹にCSVなどのファイル取込があれば、まずファイル出力を軸に考えます。
DynaEye 11はCSVやテキストでの出力を既存システム連携の手段として案内しています²。
DX Suiteも、CSV出力とAPIで基幹システムと連携できると説明しています⁴。
基幹がAPIを持つか、改修して受け口を作れる体制があれば、API連携で取込の操作まで自動化する選択肢が加わります。
どちらも難しい場合に、RPAで画面入力を代行させる方法が候補になります。

この順番は、基幹に手を入れる量が少なく、保守の負担が小さいものから考えるという編集上の整理です。
ファイル取込が使えるのにRPAを選ぶと、画面変更のたびに手順を直す保守を抱えることになります。
APIで自動化できる環境なのに人がファイルを取り込む運用にすると、取込の実行が人の作業として残ります。

帳票の種類数と確認作業の許容量

読取方式は、取引先の書式の数と安定度、確認作業にどれだけ人手を割けるかで考えます。
書式が少なく安定していれば、帳票定義型で設定を作り込み、確認の負担を抑える考え方が合います。
書式が多く、取引先ごとに変わりやすいなら、自動抽出型で設定の手間を減らします。
その代わり、拾った欄の確認に時間がかかる可能性を見込んでおきます。
確認を担当できる人数が限られる職場では、設定に手間をかけてでも確認を軽くするほうが、受注の処理が滞りにくいと考えられます。

FAXのまま受け取らない取引先を分ける

選択肢は、OCRの側だけにあるわけではありません。
インプローブは、FAXで受注している取引先に、FAXと同時にExcelやPDFを送ってもらうよう依頼すると転記ミスが減ると述べています。
文字情報を持ったテキストPDFであれば、内容をコピーすることもできます⁶。
これは受注管理システムの提供元としての見解です。
ただ、取引先が注文書をパソコン上で作っているなら、FAXで送る前のデータを添付してもらうことは、送り手にとって大きな変更にならない可能性があります。

送り手である取引先に一律の変更を求めるのは現実的でなくても、注文量の多い取引先に絞って相談すれば、OCRで読む対象そのものを減らせます。
FAXでしか送れない取引先はOCRで受け、データを送れる取引先はファイルから取り込むというように受け取り方を分けると、OCRの設定と確認の対象が絞られます。

導入前に自社の注文書で試すこと、導入後に残る手作業

試行で見る3点

ここまでの判断は、実際に試すと確かめられます。
無償の試用やサンプルでの読取検証を受け付けているかは、製品ごとに違います。
提供元に問い合わせて確認してください。
試すときは、次の三つの条件をそろえると、導入後の姿に近い結果が得られます。

<ol><li>実際に受け取るFAXの画質のまま読ませる。
複合機の受信データをそのまま使う経路で試す</li><li>取引先ごとの書式をそろえる。
注文量の多い取引先だけでなく、手書きが混じる、書式が崩れやすいといった読みにくい取引先も含める</li><li>基幹への取込まで通す。
読取結果を画面で眺めるだけでなく、対応表どおりに変換したデータを基幹のテスト環境へ取り込み、エラーが出るかを見る</li></ol>

試行中は、注文1件ごとに、読取誤りの件数、確認・修正にかかった時間、基幹の取込エラーの件数と理由を記録します。
これを、今の手入力にかかっている時間や転記ミスの件数と並べてみます。
そうすれば、提供元が示す効果の数値ではなく、自社の注文書でどれだけ作業が変わるかを見積もれます。
次に手を打つ場所も見えてきます。
取込エラーの理由が品番の不一致に偏っていれば、変換表の整備が先です。
読取誤りが特定の取引先に集中していれば、画質か書式の問題が考えられます。

導入後に残る作業

導入しても、人の作業として次のものは残ります。
受注入力の担当者にとっては、打ち込む仕事が、これらの確認と保守の仕事に置き換わると考えると実態に近くなります。

<ul><li>読取結果の確認と修正</li><li>基幹の取込エラーの処理（マスタにない品番や取引先、必須項目の欠け）</li><li>新しい取引先の帳票定義の追加や、書式が変わったときの修正</li><li>品番の変換表など、取引先の表記と自社のコードを結ぶ情報の更新</li><li>基幹の更新に合わせた取込形式や出力設定の見直し</li></ul>

後ろの三つは毎日発生する作業ではありません。
しかし担当が決まっていないと放置されやすく、その間は取込エラーや読取誤りが増え続けます。
日々の確認は受注入力の担当者が受け持ち、定義や変換表、取込形式の保守は情報システム担当や提供元が受け持つ、といった分担を試行の段階で決めておくと、移行が滑らかになります。

▼ 図の内容を文字で読む

• 実際のFAXで読む
  • 複合機の受信データをそのまま使う
  • 読取誤りの件数を記録
• 取引先ごとの書式で試す
  • 手書きが混じるなど読みにくい取引先も含める
  • 確認・修正にかかった時間を記録
• 基幹まで取り込む
  • 対応表どおりに変換して基幹のテスト環境へ取り込む
  • 取込エラーの件数と理由を記録

基幹の取込条件とOCRの出力をどう対応させるかは、基幹とOCRの両方の事情を知らないと判断しにくいため

自社の基幹が受け付ける形式と取引先の注文書の状況から、どの渡し方と読取方式が現実的かを整理できます無料相談で要件を整理する

要点の整理

軸	基準
最初に決めること	基幹が受け付ける取込形式と、読取項目との対応
渡し方	CSV取込があればファイル出力、受け口や改修体制があればAPI、どちらもなければRPA
読取設定	書式が少なく安定なら帳票定義型、多くてばらばらなら自動抽出型
精度の数値	提供元の基準帳票での値。自社の注文書で試して測る
残る作業	確認・修正、取込エラーの処理、帳票定義と変換表の保守

試行の結果を、変換表の整備・画質・書式のどこから手を付けるかに結び付けるのは、社内だけでは迷いやすいため 試行で記録した読取誤りや取込エラーをもとに、導入後に残る作業の分担と優先順位を確かめられます

よくある質問

FAXをスキャンし直したほうがOCRの精度は上がりますか

提供元のPFUは、受信したFAXを印刷してスキャンし直すのではなく、複合機が受信したデータをそのまま使うことを基本としています¹。
精度を上げる手段としては、FAXに対応したAI-OCRを使うことや、傾き・拡大縮小の補正が挙げられています¹。
まずは、受信データを直接OCRへ回せるかを確かめるのが先です。

取引先ごとに注文書の書式が違うと、読取設定は取引先の数だけ必要ですか

帳票定義型では読む位置を書式ごとに決めるため、基本的には書式の数だけ定義が要ります。
DynaEye 11では、複数の帳票定義を1つのキャビネットにまとめ、届いた注文書に合う定義をレイアウトやIDで自動選択できるとされています²。
自動抽出型は書式ごとの定義を減らせると説明されています⁴が、どの欄を拾ったかの確認が加わります。
取引先が多い場合は、自社の注文書で両方を試し、設定と確認のどちらの手間が重いかを比べると判断できます。

OCRの結果が基幹のマスタ（品番・取引先コード）と合わないときはどうなりますか

正しく読めていても、取引先側の品番表記と自社品番が違えば一致しません。
OCR製品にマスタとの自動照合の機能があるかは、製品ごとに確かめる必要があります。
ない場合は、確認画面で人が突き合わせるか、基幹へ取り込むときのエラーとして見つけることになります。
取引先の品番を自社品番へ置き換える変換表をどこで持つか、エラーになった注文を誰が直すかを先に決めておくと、受注の取り込み漏れを防ぎやすくなります。

基幹システムを改修できない場合でも連携は可能ですか

基幹にCSVなどの取込機能があれば、改修せずにファイル出力で連携できます。
取込機能もない場合は、OCRで読んだデータを受注画面へ入力する操作をRPAに代行させる方法が候補になります。
ただし、画面が変わるたびに手順の修正が要るため、保守を誰が担うかも含めて検討します。

取引先にFAX以外の送付方法（Excel・PDF）を頼むのは現実的ですか

受注管理システムの提供元であるインプローブは、FAXと同時にExcelやPDFを送ってもらうと転記ミスが減り、テキストPDFなら内容をコピーできると述べています⁶。
取引先に一律の変更を求めるのは難しくても、注文量の多い取引先から相談すれば、OCRで読む対象を減らせます。
FAXでしか送れない取引先はOCRで受け、データを送れる取引先は別の取込で受けるという分け方も現実的です。

1. 1　出典：株式会社ピーエフユー（リコーグループ）「FAX注文書はOCRできる？精度を向上させる3つのポイント（デジタラクル コラム）」（2025年）
2. 2　出典：株式会社PFU（リコーグループ）「DynaEye 11 FAQ」（2026年確認）
3. 3　出典：株式会社PFU（リコーグループ）「DynaEye 11 製品ページ」（2026年確認）
4. 4　出典：AI inside株式会社「DX Suite よくある質問」（2026年確認）
5. 5　出典：株式会社PFU（リコーグループ）「AI-OCR『DynaEye 11』機能強化 プレスリリース」（2025年）
6. 6　出典：株式会社インプローブ「製造業での受注データ取込とは？FAX・EDI・Excel・PDF」（2026年確認）