買掛管理チームの66%が、いまだに手作業で請求書を入力。
その数字は減るどころか、増えている。

APチームの66％が今なお手作業で請求書を入力。その割合は増加傾向にある。

IFOLの『2025年買掛金自動化動向』レポートは、約200名のAP・財務専門家（うち78％が買掛金業務に直接従事）を対象に調査を実施。その結果は、一般的な認識とは異なるものだった。

66％が今なお手作業で請求書データをERPや財務システムに入力しており、2023年の60％から増加。63％が週10時間以上を請求書処理に費やし、2024年の52％から上昇。財務チームの73％は完全自動化に至っておらず、27％は自動化をまったく導入していない。

一方、Vic.aiの2025年AIモメンタムレポートによると、AP専門家の37％が、手動データ入力を最大の課題として挙げており、高い処理コストや承認の遅延など、あらゆる業務上の問題を上回っている。

これは進歩の物語ではない。外から見れば解決済みに見えるが、実際はそうではない問題の物語だ。自動化ツールは存在し、ROIの根拠も明確である。それにもかかわらず、なぜ手動入力率は増加しているのか？

その答えは「企業がまだツールを購入していないから」ではない。ほとんどの企業が購入したツールが根本的な問題を解決していないからだ。根本的な問題はデータ入力が遅いことではなく、すべての請求書が異なる形式で届き、テンプレートベースの自動化がまさにその時点で機能しなくなることにある。

「手動データ入力」の日常的な実態

AP（買掛金）担当者であれば、このセクションは必要ありません。しかし、CFO、創業者、あるいは自動化予算を承認し「問題は解決した」と思い込んでいる方々 — これが実際にあなたのチームが行っている作業です。

請求書が共有受信箱にPDF添付ファイルとして届きます。誰かがそれを開き、仕入先名、請求書番号、日付、支払期日、明細行、小計、税額、合計金額を読み取ります。それらのすべての項目をNetSuite、SAP、またはQuickBooksに手入力します。請求書と発注書を手作業で目視照合し、承認のためにメールで回付します。そして、3日間返信がない承認者を追いかけます。

それを200件、1,500件、あるいは5,000件 — IFOL回答者の36%が毎月処理するボリュームで考えてみてください。

Redditのr/Accountingに投稿したあるAP担当者は、こう率直に述べています。「当社にはサプライヤーから毎月1,500～2,000件の請求書が届きます。AP自動化はもうほぼ解決されているとよく聞きますが、当社のプロセスは今だにこうです。請求書が共有受信箱にPDF添付で届き、誰かがそれを開き、ヘッダー情報をNetSuiteに手入力し、発注書と手動照合し、承認のためにメールで回付し、承認者が無視したら追いかけます。NetSuiteに組み込まれているOCR機能も試しましたが、請求書の半分でエラーになります。なぜなら、機械工場や原材料サプライヤーごとにフォーマットが異なるからです。」

この投稿には200以上の賛成票と、同様の経験を語る数十件のコメントが寄せられています。これらは小さな企業ではありません。中堅の製造業、流通業、サービス業で、毎月数百から数千件の請求書を処理しており、入力作業を行っているのは訓練を受けた会計士であって、データ入力係ではありません。

Ardent Partnersの2025年調査によると、手動処理の請求書1枚あたりのコストは15.97ドルで、一方、業界最高水準の自動処理では2.36ドルです。毎月3,000枚の請求書を処理する企業の場合、年間で49万ドルの差が生じます。これは、エラーや支払遅延、早期支払割引の機会損失によるコストを含んでいません。

フォーマットの問題：なぜベンダー請求書ごとにテンプレートが崩れるのか

もし請求書がすべて統一されたレイアウトに従っていれば、テンプレートベースのOCRは10年前にこの問題を解決していたでしょう。しかし、そうはなっていません。そして、今後もそうなることはないでしょう。

ドイツのベンダーは税の内訳をフッターに配置します。テキサスのサプライヤーは明細行の右側の列に配置します。シンガポールの請負業者は税をまったく表示せず、単価に含まれています。地元の機械工場は、手書きのメモが欄外に書かれたスキャンPDFを送ってきます。別の業者は、机の上の紙の請求書をスマホで撮影した写真をメールで送ります。

これらのフォーマットのバリエーションは、すべてテンプレートベースの自動化を機能不全にします。テンプレートOCRは、既知のレイアウト上のフィールドの位置を記憶することで機能します。「請求書番号は座標X,Yにあります。合計金額は座標A,Bにあります。」ベンダーが請求書テンプレートを変更したり、新しいベンダーを追加したりした瞬間、これらの座標は正しくなくなります。

これは例外的なケースではありません。これが標準です。中堅企業は平均して200～500の異なるサプライヤーから請求書を受け取っており、各社が独自のレイアウトを使用しています。ERPシステム、会計パッケージ、業界特化型SaaSツールは、APチームが制御できるフォーマットではなく、開発者が選択したフォーマットで請求書を生成します。

さらに悪いことに、ベンダーは請求書のフォーマットを変更します。仕入先が請求システムをアップグレードする。レストランチェーンがテンプレートを再設計する。フリーランサーがある請求アプリから別のアプリに乗り換える。こうした変更のたびに、先月まで問題なく動いていたテンプレートが静かに壊れます。買掛金チームがその破綻に気づくのは、データがおかしくなった時か、何週間も同じフィールドを手動で修正し続けていたことに気づいた時です。

テンプレートの罠：「自動化の拡大」が「メンテナンスの増大」を意味する時

ほとんどの自動化ベンダーが教えてくれない構造上のパラドックスがあります。

テンプレートベースの請求書処理は、ベンダー数に比例して拡大します。新しい仕入先が増えるごとに、新しいテンプレートの構築、テスト、保守が必要になります。ベンダーが20社ならテンプレートも20個。管理可能です。しかし、中堅のメーカーや流通業者では標準的な200社になると、テンプレートは200個になります。ベンダーがフォーマットを変更するたびに、それぞれを更新する必要があります。そしてベンダーは定期的に、しかも連絡なしに変更を行います。

Infrrdによる請求書解析自動化の分析は、それを率直に指摘しています。「テンプレートベースのシステムに新しいベンダーを追加するたびに、1枚の請求書を正確に処理できるようになる前に設定作業が必要です。仕入先数が増えたり、オンボーディングが急ピッチで進むと、テンプレートのバックログがボトルネックになります。チームは請求書を処理するよりも、テンプレートの管理に多くの時間を費やすことになります。これは自動化が本来達成すべきことの正反対です。」

規模が大きくなると、計算は逆転します。200種類のテンプレートを維持するのに専任1人、3,000件の請求書を手入力するのに2人かかるなら、それは自動化ではなく、データ入力の労働をテンプレート保守の労働に置き換えただけです。コストは移動したのであって、消えたわけではありません。

だからこそ、66%のチームが「自動化」を導入しながらも、いまだに手作業でデータを入力しているのです。彼らは、主要20社のベンダーからの請求書の80%を自動化するツールを購入しましたが、残りの180社のベンダー（ツールが解析できないフォーマット）からの請求書は、いまだに手作業で処理しています。ツールはあります。動いています。しかし、作業の大部分は依然として人間の手に委ねられています。

例外スパイラル：請求書の20%が時間の80%を消費する

部分的に自動化されたAP部門でも、ほとんど誰も測定していない作業のカテゴリがあります。それは例外処理です。

2025年版「State of ePayables」レポートの調査によると、約22%の請求書で例外処理が必要です（PO番号の欠落、金額の誤り、フォーマットの異常、重複送信など）。手動プロセスでは、これらの例外は流れの一部にすぎません。しかし自動化プロセスでは、それらは障害となります。

自動化は例外を検出し、処理を停止し、通知を生成します。そして…人間が介入しなければなりません。元のPDFを開き、検出されたデータと照合し、ベンダーにメールを送り、返答を待ち、修正データを再入力し、承認のために再ルーティングします。1件の例外解決に15～30分かかることもあります。

計算してみましょう。月3,000件の請求書 × 22%の例外率 = 660件の例外。1件あたり20分として、220時間。これはフルタイム従業員の月間キャパシティを超える時間を、例外処理だけに費やしていることになります。しかも、これは自動化がすでに請求書を「処理」した後の話です。

これが半自動化の罠です。企業が自動化に投資し、簡単な80%を削減すると、残りの20%は例外によってワークフローのリズムが崩れるため、元の100%よりも困難であることが判明します。チームの作業量は減らず、むしろ断片化され、コンテキストスイッチの多い作業が増えます。Vic.aiはこれを「AP自動化のラストワンマイルは依然として人手に頼っている」と呼んでいます。

テンプレートベースOCRが限界に達する理由——そしてそれを超える方法

これまでの3つのセクションでは、1つの根本的な問題を説明してきました。フォーマット依存性です。テンプレートOCR、ルールベース抽出、従来の機械学習モデルはすべて同じ制限を共有しています——データが「どこにあるか」を知る必要があり、「何であるか」を知らないのです。

テンプレートシステムは座標を見ます。「請求書番号はページのどこにあるか？」と問います。その答えはベンダーごとに異なります。視覚言語モデル（VLM）は意味を見ます。「このページの何が請求書番号として機能するか？」と問います。その答えは、それがどこにあっても同じです。

これはわずかな改善ではありません。カテゴリーの違いです。VLMベースのシステムに「請求書番号」「ベンダー名」「支払期日」「合計金額」を抽出するよう指示すると、期待される位置にある単語をスキャンするのではなく、人間と同じように文書を読み、「INV-2025-08472」が「請求書番号」「参照番号」「文書番号」といったラベルの横にある場合、それがページ上のどこにあっても請求書番号であると理解します。

これから直接的に3つの意味が導き出されます：

1. テンプレートの作成や管理は不要。 新規取引先の請求書も、10年来の取引先のものも、同じ方法で処理されます。システムは文書を毎回新たに読み取り、その構造を独立して理解します。

2. フォーマット変更でパイプラインが止まらない。 仕入先が請求書のレイアウトを変更しても、VLMは位置ではなく意味的な役割でフィールドを見つけます。何も更新する必要はありません。

3. 複数取引先のデータが1つの統合テーブルに集約される。 「取引先」「請求日」「明細内容」「数量」「単価」「合計」など、必要な列名を定義するだけで、元のレイアウトに関係なくすべての請求書データがその列に出力されます。1つのスプレッドシート、すべての取引先、テンプレート保守は不要です。

これは理論ではありません。「データはどこにあるか」（テンプレートOCR）から「このデータは何を意味するか」（VLM）へのアーキテクチャの転換こそが、フォーマット問題を大規模に解決可能にするのです。

AI抽出に切り替えると実際に何が変わるのか

数字で具体的に見てみましょう。300の取引先から月3,000件の請求書を処理する中堅規模の買掛金チームの場合：

VLM側のワークフローは簡単です。請求書をアップロードし（ドラッグ＆ドロップ、フォルダからの一括アップロード、またはベンダーが直接提出できるコレクションリンクの共有）、抽出したい列名を指定し、すべてのデータが統合された1つのExcelファイルをダウンロードするだけです。Google Sheetsを使用している場合、アドオンを使えばスプレッドシートから離れることなく作業が可能で、抽出されたデータがアクティブなシートに直接追加されます。

また、抽出以上の機能が必要なチームには、計算列を使用して抽出中に実行する計算を定義できます。数量×単価から明細行の合計を計算する必要がありますか？請求された合計が明細行の合計と一致しない請求書にフラグを立てたいですか？計算を一度定義すれば、AIがすべての請求書に自動的に適用します。バッチ処理ワークフローの詳細なチュートリアルについては、複数のPDFから請求書データを一括抽出して1つのExcelシートにまとめる方法のガイドをご覧ください。