APチームの66%が今も手作業で請求書を入力しています。
その数字は減るどころか、増えています。

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

IFOLの「Accounts Payable Automation Trends 2025」レポートは、約200人のAPおよび財務プロフェッショナルを調査しました。そのうち78%が買掛金業務に直接従事しています。その結果は、一般的な認識とは一致しません。

66%がいまだに請求書データをERPや財務システムに手入力しています — 2023年の60%から増加。63%が請求書処理に週10時間以上を費やしており、2024年の52%から増加しています。財務チームの73%は完全には自動化されておらず、27%は自動化をまったく導入していません。

一方、Vic.aiの2025年AI Momentum Reportによると、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に入力し、POを手動で照合し、承認のためにメールで回覧し、無視する承認者を追いかけます。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チームが制御できるフォーマットではありません。

そして、さらに悪化します。ベンダーは請求書フォーマットを変更します。サプライヤーが請求システムをアップグレードする。レストランチェーンがテンプレートを再設計する。フリーランサーがある請求アプリから別の請求アプリに切り替える。それぞれの変更が、先月まで機能していたテンプレートを静かに壊します。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を開き、フラグされたデータと照合し、ベンダーにメールを送り、返答を待ち、修正データを再入力し、承認のために再ルーティングします。各例外の解決には15〜30分かかることがあります。

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

これが半自動化の罠です。企業は自動化に投資し、簡単な80%を削減しますが、残りの20%は元の100%よりも難しいことに気づきます。なぜなら例外がワークフローのリズムを壊すからです。チームの作業量は減っていません — 断片化され、コンテキスト切り替えの多い作業が増えているのです。Vic.aiはこれを「AP自動化のラストマイルはまだ手作業で歩かれている」と呼んでいます。

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

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

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

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

これから直接導かれる3つの含意があります：

1. テンプレートの作成や保守が不要。新しいベンダーの請求書も、10年間取引のあるベンダーと同じ方法で処理されます。システムは各文書を新たに読み、その構造を独立して理解します。

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

3. ベンダー横断のデータが1つの統合テーブルに集約される。「ベンダー」「請求書日付」「明細説明」「数量」「単価」「合計」など、必要な列名を定義すれば、元のレイアウトに関係なく、すべての請求書がその列にデータを出力します。1つのスプレッドシート、すべてのベンダー、テンプレート保守なし。

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

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

数字で見てみましょう。月間3,000件の請求書を300社のベンダーから処理する中堅規模のAPチームを例にします。

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

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