協力会社の請求書処理は、OCRの読み取り精度を上げても自動化されません。詰まるのは工事番号との突合と、合わなかったときの差し戻し先です。受付チャネルの整理 → 電帳法上の分岐 → 読み取り項目の絞り込み → 突合設計、の順で組むのが実装の定石です。
なぜ協力会社の請求書はOCRだけで自動化できないのですか？
OCRが解くのは「紙面の文字を取る」工程だけで、請求書処理の工数はその手前と後ろに偏っているからです。
建設業の支払業務を分解すると、おおよそ次の工程になります。
| 工程 | 内容 | OCRで解けるか |
|---|---|---|
| 1. 受領 | FAX・郵送・メール添付・メール本文・ポータルから受け取る | 解けない |
| 2. 仕分け | 誰宛の請求か、どの現場かを判別する | 一部 |
| 3. 読み取り | 請求元・金額・明細を取る | 解ける |
| 4. 紐付け | 工事番号・注文書番号に結びつける | 解けない |
| 5. 突合 | 注文金額・出来高・既請求累計と照合する | 解けない |
| 6. 差し戻し | 合わない分を現場か協力会社に返す | 解けない |
| 7. 承認・原価計上 | 承認後に原価へ反映する | 解けない |
OCRが担うのは工程3だけです。そして経理担当が実際に時間を取られているのは、工程4〜6です。「A社から届いた請求書がどの現場のものか分からない」「注文書の金額と合わないので現場監督に確認する」「先月の請求と重複していないか台帳を見に行く」。この往復が処理時間の本体です。
したがって、読み取り精度が95%か98%かという議論より先に、合わなかったときに誰にどう返すかを決めるほうが効きます。
どこから手を付ければよいですか？（受付チャネルの整理）
最初にやるのは受付チャネルの棚卸しです。ここを飛ばすと、後工程のすべてが例外処理だらけになります。
実際の現場で並存しているチャネルは、たいてい次の5つです。
- FAX — 複合機で紙出力される運用と、PDFとしてメール転送される運用が混在している
- 郵送（紙） — 月末に本社経理へ届く。現場宛に直接届くケースもある
- メール添付PDF — 協力会社ごとにファイル名の付け方がバラバラ
- メール本文 — 「今月分は◯◯円でお願いします」と本文だけで送られてくる
- 請求書ポータル／自社の協力会社サイト — 導入済みなら最も扱いやすい
棚卸しの手順は次の通りです。
- 直近3か月分の請求書を、協力会社ごとにチャネル別で数える
- 「1社が毎月同じチャネルで送ってくるか」を確認する（月によって変わる会社が必ずいます）
- 現場宛に直接届いているものが何割あるかを確認する
- 手書き請求書、社判のみで書式がない請求書を別枠で数える
この棚卸しの結果、上位数社が全体の大半を占めることがほとんどです。その上位数社のチャネルを1つに寄せるだけで、自動化の対象範囲が一気に単純になります。 システムを作る前に、営業日を決めて「来月からPDFをこのアドレスに送ってください」と依頼するほうが早い、という結論になる場合もあります。
チャネルを寄せきれない場合でも、システム側には必ず「どのチャネルから入ってきたか」をデータ項目として持たせます。後述する電帳法の扱いがチャネルによって分かれるためです。
電子帳簿保存法の対応は請求書処理のどこに効いてきますか？
効くのは「受領した瞬間の分岐」と「保存後に検索できるか」の2点です。
大枠の整理は次の通りです。なお電子帳簿保存法は改正が続いている領域のため、以下は考え方の整理であり、自社への適用可否・最新の取扱いは顧問税理士または所轄税務署にご確認ください。
| 受領形態 | 電帳法上の位置づけ | 設計上の注意 |
|---|---|---|
| メール添付PDF／ポータルからのダウンロード | 電子取引データ。電子のまま保存する取扱いが基本 | 紙に出して紙だけ保管する運用にしない |
| 紙で郵送・手渡し | 原本は紙。スキャナ保存の要件を満たせば電子化できる | スキャン後の原本の扱いを社内規程で決める |
| FAX（複合機で紙出力） | 紙で受領した扱いになる整理 | 出力運用かPDF受信運用かを統一する |
| FAX（PDFで受信） | 電子取引データとして扱う整理 | どちらの運用かを社内で明文化する |
システム設計に落ちてくる要件は、主に次の2つです。
真実性の確保：受け取ったデータが後から書き換えられていないことを担保する仕組みが必要です。タイムスタンプの付与、訂正・削除の履歴が残る（または訂正削除ができない）システムでの保存、あるいは訂正削除防止に関する事務処理規程の整備、といった方法が示されています。開発側から見ると、「保存後のファイルを差し替えられるUIを作らない」「差し替えたなら履歴を残す」という設計制約になります。
可視性の確保：保存したデータを、取引年月日・取引金額・取引先といった項目で検索できる状態にしておく必要があります。ここがOCRと直結します。OCRで取った値をそのままファイル名やメタデータに書き込めば検索要件を満たしやすくなり、逆にOCRを入れないと担当者が手で命名規則を守り続けることになります。
つまり、電帳法対応はOCR導入の副産物ではなく、OCRを入れる理由そのものになり得ます。検索用のメタデータを人手で入力し続ける運用は、月末に必ず崩れます。
OCRで読み取る項目はどう決めますか？
全項目を読ませようとすると精度が落ち、確認工数が増えます。項目を3つに分類してください。
A. 必ず読み取る（自動確定させる）
– 請求元名称
– 請求日／締め日
– 請求金額（税抜・消費税・税込）
– 請求書番号
この4群は書式が違っても位置と表現が安定しており、突合の起点になります。
B. 読み取るが人の確認を前提にする（候補提示）
– 現場名・工事名
– 工事番号／注文書番号
– 支払期日
– 振込先口座
現場名は表記ゆれの巣です。「◯◯様邸新築工事」「◯◯邸」「◯◯様邸（追加）」が同じ現場を指します。ここを自動確定させると原価が別現場に積まれます。
C. 読み取らない（当面は対象外にする）
– 明細行の全項目
– 手書きの備考
– 出来高内訳の内訳
明細行は、協力会社ごとに粒度がまるで違います。1行で「◯月分工事一式」と書く会社と、歩掛単位で20行書く会社が混在します。明細まで構造化しようとした瞬間、プロジェクトの難易度が跳ね上がります。 原価管理上、明細まで必要なのか、工種単位の合計で足りるのかを先に決めてください。多くの場合、支払業務の自動化だけならCは不要です。
振込先口座については、口座変更を装った詐欺メールへの警戒もあり、自動更新はさせず「前回と異なる」ことだけを検知して人に上げる設計が安全です。
工事番号との紐付けはどう設計しますか？
段階的な絞り込みにして、単一に定まらないときは自動確定させないのが原則です。
紐付けの判定順序は次のように組みます。
- 請求書に工事番号が印字されている → 番号の実在チェックのみ行って確定
- 注文書番号が印字されている → 注文書マスタから工事番号を引く
- 番号なし・現場名のみ → 「請求元 × 請求対象月 × 未完了の注文書」で候補を絞る
- 候補が1件 → 確定（ただし確定理由をログに残す）
- 候補が複数、または0件 → 自動確定せず、候補リストを付けて人に回す
ここで効くのが注文書側のデータ品質です。請求書のOCR精度を上げるより、自社の注文書マスタに工事番号と現場名の別名（略称・旧称・施主名表記）を持たせるほうが、紐付け率は上がります。
この「入力側の整備で読み取り側の負荷を下げる」考え方は、当社がイーリアルティ様に構築した転記エージェントでも同じでした。業務マニュアルが未整備の状態からの着手でしたが、転記そのものを自動化したことで、マニュアルを作り込む必要自体が減りました。属人的な手順を文書化してから自動化するのではなく、自動化することで文書化すべき手順を消すというアプローチです。
なお、工事番号が請求書に印字されるかどうかは、こちらから協力会社に注文書番号の記載を依頼できるかにかかっています。開発の前に、上位数社へ「注文書番号を請求書に記載してください」と依頼するだけで、判定1で確定する割合は上がります。
突合エラーは誰にどう返しますか？
差し戻し先の判断基準を、エラーの種類ごとに事前に決めておきます。これが設計の本体です。
| エラー種別 | 一次判断者 | 返し方 |
|---|---|---|
| 工事番号が特定できない | 経理 | 候補提示。決まらなければ現場監督へエスカレーション |
| 注文金額を超過している | 現場監督 | 追加工事の指示有無を確認。指示があれば注文変更を先に処理 |
| 出来高査定と請求額が乖離 | 現場監督 | 査定根拠と併せて協力会社へ差し戻し |
| 既請求累計との重複疑い | 経理 | 過去請求書の該当箇所を並べて提示 |
| 請求元が未登録 | 経理 | 取引先マスタ登録を先に実施 |
| 振込先が前回と相違 | 経理（要ダブルチェック） | 電話等の別経路で確認。メール返信での確認で完結させない |
設計上の要点は3つです。
- エラーを1つのリストに混ぜない。 経理が見るべきものと現場が見るべきものを分けて配信します。混ぜると全員が全件を見に行き、結局誰も見なくなります。
- 差し戻し理由を協力会社に伝える文面まで自動生成する。 差し戻しの手間の大半は、原因を説明する文章を書くことです。
- 締め日から支払日までの日数に応じて、エラーの通知タイミングを変える。 月末に全件がまとめて出てくる設計にすると、最も忙しい日に確認作業が集中します。請求書が届いた時点で即時に判定し、随時通知する構成にします。
この仕組みでできないこと・限界は何ですか？
過大な期待を持って始めると、必ず「導入したのに使われない」状態になります。先に限界を共有します。
- 手書き請求書の完全自動化はできません。 崩し字・かすれ・押印のかぶりがある伝票は、確認工数がむしろ増えます。手書きで送ってくる会社は、書式提供やポータル利用への切り替えを個別に依頼するほうが早く解決します。
- 出来高の妥当性は判定できません。 システムができるのは「注文金額と請求額が合っているか」「既請求累計と矛盾しないか」の算術的な照合までです。工事が本当にその出来高まで進んでいるかは、現場が判断する領域です。
- 電帳法の適合可否を保証することはできません。 開発側が担保できるのは、訂正削除の履歴が残ること、検索項目が保持されていること、といった仕組み面です。自社の運用が要件を満たしているかの最終判断は、顧問税理士・所轄税務署へご確認ください。
- 明細行の完全構造化は費用対効果が合わないことが多いです。 工種単位の集計で足りるなら、明細は画像のまま添付しておくほうが現実的です。
- 法改正への追随は運用の話になります。 保存要件や検索要件は改正が続く領域です。改修が必要になる前提でシステムを組み、規程と運用ルールをセットで持つ必要があります。
まとめ
- 協力会社請求書の自動化で詰まるのはOCR精度ではなく、工事番号との紐付けと差し戻し設計である
- 着手順は「受付チャネルの棚卸し → 電帳法上の分岐の整理 → 読み取り項目の3分類 → 突合ルール → 差し戻しフロー」
- 読み取り項目は「自動確定」「候補提示」「対象外」の3つに分ける。明細行は当面対象外にするのが現実的
- 電帳法の検索要件（取引年月日・取引金額・取引先）とOCRの出力項目は直結する。人手の命名規則運用は月末に崩れる
- エラーは種別ごとに一次判断者を決め、経理と現場でリストを分けて配信する
よくある質問
Q. 協力会社の請求書はOCRだけで自動処理できますか？
できません。OCRが解くのは「紙面の文字を取る」工程だけです。実務で詰まるのは工事番号との紐付け、注文金額・出来高との突合、差し戻し先の判断です。OCR導入前に受付チャネルの一本化と工事コードの表記ゆれ整理を行わないと、精度を上げても手戻りは減りません。
Q. 紙で届いた請求書とPDFで届いた請求書は、電子帳簿保存法上の扱いが違いますか？
違います。メールやWeb経由で受け取った請求書は電子取引データとして電子のまま保存する取扱いが基本で、紙で受領したものはスキャナ保存の要件を満たせば電子化できる、という整理です。要件は改正が続く分野のため、適用可否は顧問税理士・所轄税務署にご確認ください。
Q. FAXで届く請求書はどう扱えばよいですか？
複合機で紙出力してから受け取ったのか、PDFのまま受信したのかで扱いが分かれます。実務上は受信方法を1つに統一するのが最も安全で、システム側でも「どのチャネルから来たか」をデータに保持して後から証跡をたどれるようにしておきます。判断は税理士にご確認ください。
Q. 工事番号が請求書に書かれていない場合はどうしますか？
現場名・注文書番号・請求元・請求月の4つを使って候補を絞り、単一に定まらない場合は自動確定させず候補を提示して人が選ぶ設計にします。無理に推測で確定させると原価が別現場に積まれ、月次締め後に発覚して修正工数が跳ね上がります。
Q. この種の仕組みはどのくらいの規模から作れますか？
1業務に絞ったかなり小さなプロジェクトなら数十万円から着手でき、対象範囲が広がると数百万円前半のレンジになります。実際の金額は業務種類数、入力データの状態、既存システム連携、求める精度で変わります。まず請求書1種類・1チャネルから始める進め方も可能です。
ご相談について
エクサテックは、不動産・建設の現場に入り込んで仕組みを設計し、Webアプリの実装まで同一チームで行っています。イーリアルティ様の転記エージェントでは、契約の前段階から何度も現場に足を運び、困りごとを理解するところから始めました。
「まず自社の請求書がどのチャネルから何件来ているか整理したい」という段階でも構いません。現状の受付フローをお聞かせいただければ、どこから着手するのが妥当かを一緒に検討します。
