請求書処理をAIで自動化｜書式の違いを吸収し経理は確認に集中できる

請求書処理のどこに時間がかかっているか

請求書の処理は、届いたものを読んで、内容が正しいかを確かめて、支払データとして会計側へ渡す作業に分かれます。このうち時間がかかるのは、多くの場合「読む」ところではありません。

届く経路が揃っていないこと、書式が発行元ごとに違うこと、そして中身が正しいかどうかを人が毎回確かめていることが、処理量を押し上げます。メールの添付PDF、郵送されたものをスキャンしたファイル、取引先のポータルからダウンロードする形式が混在していると、その入口ごとに手作業が発生します。

書式の違いも、発行元が使う請求書発行サービスの違いとしてそのまま表れます。freeeやマネーフォワードのように発行に使うサービスが違えば、同じ項目が同じ位置にあるとは限らず、項目の呼び方も揃いません。同じ「合計」が税抜のことも税込のこともあります。

自動化を考えるときは、この3つのうちどれを機械に任せ、どれを人が持つかを先に分けます。分けずに全体をまとめて自動化しようとすると、精度の話に議論が寄って進まなくなります。

書式ごとにテンプレートを作る方法が続かない理由

請求書の読み取りは、以前から「発行元ごとに読み取り位置を登録する」やり方で行われてきました。件数が多い取引先が数社に限られている場合はこれで足ります。ただし対象を広げると維持できなくなります。理由は4つあります。

登録するテンプレートが取引先の数だけ増えます。 取引先が増えるたび作業が発生し、担当が固定化します。

同じ発行元でも様式が変わります。 発行側がサービスを変えたり請求書のレイアウトを更新すれば、登録済みの読み取り位置はずれます。ずれたことは、抽出値がおかしくなってから気づきます。

明細の行数が毎回違います。 位置を固定する方式は、行数が可変な表と相性がよくありません。

新しい取引先の初回請求書は、必ず未登録です。 つまりテンプレート方式は、いちばん間違いやすい初回を自動化できません。

AIで読み取る場合は、位置ではなく意味で項目を取ります。「ご請求金額」「合計金額」「お支払金額」が同じ項目を指していると扱えるため、初めて見る書式でも抽出できます。代わりに、出力が毎回同じとは限らないという性質を持ちます。設計の重心は、読み取り精度を上げることから、間違っていた場合に検出して止める仕組みを持つことへ移ります。

書式の違いは具体的にどこに出るか

「書式が違う」と一言で言っても、機械にとっての難しさは項目ごとに変わります。どこに違いが出るかを分けておくと、抽出の段階で吸収できるものと、抽出だけでは確かめられず突合で受け止めるものを切り分けられます。

違いが出るところ	書かれ方の例	機械側の受け止め方
項目の呼び方	ご請求金額／合計金額／お支払金額	意味で読む方式なら抽出で吸収できる
金額が税抜か税込か	同じ「合計」が税抜のことも税込のこともある	単独では判別できない。税率ごとの内訳と明細合計から検算して決める
明細の作り	1行だけのものから数十行の表まで	行数を固定しない。見出し行と小計行を明細本体と混ぜない
支払期日の書き方	2026年9月30日／9/30／月末締め翌月末払い	日付でないものは支払条件として取り、取引先マスタと突き合わせる
振込先の書き方	本文中の1行、欄外の注記、複数口座の併記	抽出はするが自動では通さない。マスタとの照合結果で人へ回す
請求書番号	通番、日付入り、取引先側の管理番号のみ	番号だけでは重複を判定できない。取引先との組み合わせで見る
紙や手書きの混入	印影の重なり、手書きの追記、傾いたスキャン	確信度が低いものは抽出値を採らず確認へ回す

自動で通せるのは、別の値と突き合わせて確かめられるものだけです。項目の呼び方や明細の行数は、読み取りの段階で吸収できます。税抜か税込か、支払期日の条件、振込先は、請求書1枚の中だけでは正しさを確かめられないため、マスタや発注情報との突合を挟みます。書式のばらつきに合わせて読み取りを作り込むより、確かめる相手を先に用意するほうが、対象の取引先を広げたときに崩れにくくなります。

読み取り方式そのものの違いは AI-OCRと生成AIの違いは位置で読むか意味で読むか で扱っています。

取り込みから会計連携までの流れ

処理を段階に分けると、設計すべき箇所がはっきりします。

1. 受け取り … 請求書用のメールアドレスや共有フォルダに集約し、届いた時点で一意のIDを振る
2. 判別 … 請求書か、見積書か、納品書か、それ以外かを分ける。1つのメールに複数枚が入っている場合の分割もここで行う
3. 抽出 … 取引先名、請求書番号、請求日、支払期日、税率ごとの内訳、税額、合計、振込先、明細を取る
4. 検算と突合 … 抽出した値そのものが整合しているかを機械で確かめる
5. 確認 … 機械で確定できなかったものだけを人に回す
6. 登録 … 会計や支払のシステムへ支払データとして渡す

1の受け取りでは、原本をどこへどう残すかも同時に決まります。メールなど電子データで受け取ったものと、郵送分をスキャンしたものでは保存に求められる扱いが違うため、処理の経路を引く前に保存先を決めておきます。保存の要件と自動化の噛み合わせは 電子帳簿保存法に対応した請求書処理の自動化 で扱っています。

6の登録では、渡す形式のほかに、どの勘定科目でどの月に計上するかが決まります。会計システムへの接続方法や二重計上への備えは 請求書のAI自動仕訳はどこまで任せられるか で扱っています。この記事では、そこへ渡せる状態の請求データを作るまでを対象にします。

このうち4が抜けている構成をよく見かけます。抽出したあと、いきなり人の目視確認に回す形です。これだと自動化しても確認の負担が減りません。機械で確かめられることは機械に任せます。

機械で確かめること	突き合わせる相手	合わなかったときの扱い
明細の合計と請求合計の一致	同じ請求書内の値	抽出の誤りを疑い、該当項目を人の確認へ
税率ごとの対象額から計算した税額	請求書に記載の税額	税区分の判断が必要なため人の確認へ
請求書番号と取引先の組み合わせ	過去に登録した請求データ	重複請求として止める
取引先名	取引先マスタ	候補を示して人が選ぶ
振込先の口座	マスタに登録された口座	金額にかかわらず人の承認へ
請求金額	発注書や契約で決まっている金額	差の理由が説明できるまで登録しない

ここで合わなかったものだけが、人の確認対象になります。

人が確認を残す箇所

支払は間違えると取り戻しにくいため、確認をすべて機械に任せる設計にはしません。ただし全件を人が見る必要もありません。実務で人の判断が要るのは、次の3種類に集約されます。

人が持つ判断	人へ回す条件	自動で通さない理由
金額	検算が合わない／発注額と差がある／上限額を超える	事故の規模を上限額で抑えられる
振込先	マスタに登録がない口座、登録と違う口座	変更の真偽が請求書だけでは判断できない
税区分	税率の混在、非課税・不課税、適格請求書の判定	自社の会計処理の方針に依存する

金額。検算が合わなかった場合、発注時の金額と差がある場合、そして一定額を超える場合です。金額の上限を決めて、それ以上は必ず人が承認する形にしておくと、自動化の範囲を広げても事故の規模が抑えられます。

振込先。取引先マスタに登録がない口座、または登録と違う口座が書かれている場合は、金額の大小にかかわらず人へ回します。振込先の変更は、本当に変更された場合と、そうでない場合の区別が請求書だけでは付きません。ここを自動で通す設計にしない、という判断は最初にしておいたほうがよいです。

税区分。税率が混在する請求、非課税や不課税が含まれる請求、適格請求書として扱えるかの判定などは、自社の会計処理の方針に依存します。AIが決めるのではなく、候補を示して人が選ぶ形にします。勘定科目や部門の割り当ても同じ扱いにすると、後から仕訳を直す手間が減ります。登録番号の照合や経過措置の扱いをどこまで機械に任せられるかは インボイス制度に対応した請求書チェックをAIで自動化する で扱っています。

確認の画面は、元の請求書の画像と抽出値を並べて表示し、抽出値がどこから取られたかが分かるようにします。人が直した内容は記録しておき、同じ取引先で同じ直しが繰り返されるなら、その取引先固有のルールとして持たせます。確認を単なる目視で終わらせず、次回の入力にする設計です。

例外を差し戻す経路

自動化の設計で抜けやすいのは、処理できなかったものの行き先です。

読み取れないほど画質が悪い、必要な項目が書かれていない、発注していないものが請求されている、金額が合わない。こうした請求書は、社内で直せるものと、発行元に再発行や訂正を依頼しないと進まないものに分かれます。この2つを分け、それぞれの宛先と期限を決めます。

差し戻したものには状態を持たせます。誰に返したか、いつ返したか、返答があったか。状態を持たせないと、差し戻したまま止まっている請求書が締めの直前に出てきます。滞留しているものを一覧で見られるようにし、期限を超えたら通知する仕組みまで含めて、ようやく運用に乗ります。

月次締めに間に合わせるための段取り

請求書処理には締めという期限があります。処理にかかる時間が短くなっても、期限を越えたものが毎月残るなら、経理側の負担は変わりません。件数を減らす設計とは別に、締めまでの段取りを決めておきます。

決めること	何を基準に決めるか	決めていないと起きること
当月に含める受け取りの締め切り	会計側が計上を確定させる日	締めの当日に届いた請求書の扱いを毎月その場で判断する
未着の洗い出しをいつ行うか	前月までの計上実績	締めた後に請求書が出てきて、計上する月がずれる
差し戻したものの回答期限	発行元へ依頼してから戻るまでの実績	差し戻したまま止まり、締めの直前に残る
人の確認に回る件数の上限と担当	締め前に集中する日の件数	自動化しても確認待ちが積み上がり、期限に間に合わない
間に合わなかった分の扱い	会計側のルール	月ごとに扱いが変わり、後から数字を説明できない

未着の洗い出しは、届いた請求書だけを見ていても分かりません。前月までに計上があって当月まだ受け取っていない取引先を突き合わせて出す形にすると、機械で毎月同じ手順で行えます。届いていないことに気づくのが締めの後だと、計上する月がずれ、修正の手間が処理の自動化で得た分を上回ります。

確認に回る件数は、締め前の数日に集中します。ここで人の手が足りないと、抽出と検算が自動で終わっていても登録まで進みません。自動化の範囲を広げる判断は、精度の平均値ではなく、集中する日に確認へ回った件数を見て決めたほうが実態に合います。

間に合わなかった分は、翌月に回すのか、金額を仮で計上するのかを先に決めます。ここは会計側のルールなので、自動化の設計より前に確認します。

見積書の取込や受発注メールの処理との違い

同じ書類の自動化に見えても、請求書、見積書、受発注メールは要件が違います。最初にどれを手がけるかの判断材料になるため、違いを押さえておきます。

見積書の取込は、間違いが見つかるタイミングが早く、取引が成立する前に修正できます。件数も請求書より少ないことが多いです。一方で、比較や検討のために項目を揃える必要があり、書式の違いを吸収する要求は請求書より強く出ます。

受発注メールの処理は、添付ファイルよりも本文の文章から意図を読む比重が高くなります。「先日の見積の数量を10から12に変更してください」といった書き方に対応する必要があり、しかも出力が社外への返信になります。人の確認を外しにくい領域です。

請求書の処理は、出力が社外に出ません。渡す先は会計や支払のシステムで、渡すべき形も決まっています。さらに、抽出した値が正しいかを発注情報や計算との突合で確かめられます。正解が機械で確認できる範囲が広いという点で、最初の対象に向いています。

まず1業務から始めるときの切り出し方

全体を一度に置き換えようとすると、要件が広がって着手できません。範囲を絞ります。

経路を1つに限る。 メールの添付PDFだけを対象にし、郵送分は当面これまでのやり方を続けます。

対象の取引先を絞る。 件数の多い上位の発行元に限定します。ここで書式の違いへの耐性が確かめられます。

期間を締め1回分に限る。 1か月分を通してみると、月末に集中する量や例外の出方が分かります。

最初は人の確認を全件残す。 抽出と検算だけを自動化し、承認は従来どおり人が行います。この段階で、抽出値の直しがどこに集中するかを記録します。自動で通してよい条件を、この記録から決めます。

次の範囲は記録を見て決める。 直しがほとんど発生しなかった項目と金額帯から、人の確認を外していきます。始める前に「何割まで自動化する」と決め打ちしないほうが、判断を間違えにくくなります。

進める前に用意しておくものは、対象業務の現在の手順、取引先マスタと登録口座の情報、会計側の受け取り形式（インポートするファイルの仕様か接続の口か）、承認の権限者、そして運用を直し続ける担当です。特に最後の1つは、決まっていないと数か月で使われなくなります。開発全体の進め方は AIエージェント開発の進め方 で扱っています。

こうした業務ごとの改善を、外部に都度依頼するのではなく社内で回せるようにする進め方は AI内製化の進め方 を参照してください。請求書処理は入口と出口が決まっているため、社内で改善を回す最初の題材にしやすい業務です。

まとめ：請求書処理を自動化するときの要点

• 時間がかかっているのは読み取りより、経路の不統一と人による全件確認である。どれを機械に渡すかを先に分ける
• 書式の違いは項目ごとに難しさが変わる。呼び方や明細の行数は読み取りで吸収でき、税抜か税込か・支払期日の条件・振込先は突合で受け止める
• 発行元ごとに読み取り位置を登録する方式は、取引先が増え様式が変わると維持できない。初回の請求書を自動化できないという弱点もある
• 抽出のあとに検算と突合を置く。明細合計との一致、税額の再計算、重複請求、マスタとの照合は機械で確かめられる
• 人が持つのは金額、振込先、税区分の3点に絞る。振込先がマスタと違う場合は金額にかかわらず人へ回す
• 処理できなかったものの差し戻し先と期限、滞留の通知までを設計に含める
• 締めまでの段取りを別に決める。受け取りの締め切り、未着の洗い出し、確認に回る件数の上限、間に合わなかった分の扱いを先に置く
• 始めるときは経路と取引先と期間を絞り、承認は人に残したまま抽出だけを自動化して記録を取る

Augueでは、書類の読み取りから既存システムへの連携までを含めたAIエージェントの開発に対応しており、どこまでを自動化しどこに人の承認を残すかの設計から一緒に検討できます。自社の請求書処理を自動化の対象にできるか判断したい方は、是非ご相談ください。

関連する記事

読み取った後の勘定科目の判定と会計システム連携は 請求書のAI自動仕訳はどこまで任せられるか、原本の保存要件との噛み合わせは 電子帳簿保存法に対応した請求書処理の自動化、適格請求書の要件を満たすかの確認は インボイス制度に対応した請求書チェックをAIで自動化する で扱っています。読み取り方式の選び方は AI-OCRと生成AIの違いは位置で読むか意味で読むか を参照してください。

開発の進め方や見積の考え方は AIエージェント開発の進め方、社内で改善を回せる体制づくりは AI内製化の進め方、業務全体を棚卸ししてAI化の対象を決める段階なら 企業のAIネイティブ化の進め方 を参照してください。

よくある質問

請求書処理の自動化はどこから始めるとよいですか？

経路を1つに絞ることから始めます。メールの添付PDFだけを対象にし、件数の多い取引先と締め1回分に限って通してみる形です。最初は承認を全件人に残し、抽出と検算だけを自動化して、抽出値の直しがどの項目に集中するかを記録します。自動で通してよい条件は、その記録から決めます。

AIで読み取る方式と、発行元ごとにテンプレートを登録する方式の違いは何ですか？

テンプレート方式は読み取り位置を座標で登録するため、取引先が増えるたびに登録作業が発生し、様式が変わるとずれます。新しい取引先の初回請求書は必ず未登録です。AIは位置ではなく項目の意味で読むため初めて見る書式でも抽出できますが、出力が毎回同じとは限りません。そのため、読み取り精度を上げる作業より、誤った値を検出して止める仕組みに手を入れたほうが早く安定します。

人の確認はどこまで残すべきですか？

金額、振込先、税区分の3点に絞ります。検算が合わない場合と発注時の金額に差がある場合、一定額を超える場合は人が承認します。取引先マスタに登録がない口座や登録と違う口座が書かれている場合は、金額の大小にかかわらず人へ回します。

読み取りの精度はどれくらい出ますか？

一律の数字は出せません。扱う書式のばらつきと、項目の書き分けの程度で変わります。判断材料になるのは、締め1回分を通して項目ごとに直しの発生率を測った結果です。精度の見込みを先に決めようとすると着手できません。誤りを機械で検出できる範囲を広げるほうが、結果として通せる件数が増えます。

会計システムへはどう渡しますか？

会計側が持つインポート形式に合わせるか、接続の口を使うかのどちらかです。どちらを選ぶかは会計システム側の用意で決まるため、読み取りの仕組みを作る前に確認しておきます。いずれの場合も、検算と突合を通ったものだけを渡す構成にし、取込の前後で件数と合計金額を照合できるようにしておきます。

インボイス制度や電子帳簿保存法への対応はどう関わりますか？

適格請求書として扱えるかの判定や税区分の割り当ては、自社の会計処理の方針に依存します。AIに確定させず、候補を示して人が選ぶ形にします。保存の要件そのものは制度の指針を確認し、要件を満たす保存先へ原本を残す前提で処理経路を設計します。