インボイス対応AI｜経理の月8時間突合を1時間に減らす5ステップ

「インボイス制度が始まってから、月末の経理が完全に詰まった」——これは私が伴走している中小企業の経理現場でいちばん多く聞く一言です。取引先50社を超え、月100件以上のインボイスを1枚ずつ目視で「適格かどうか」「登録番号は本物か」「税率と端数は合っているか」と確認する作業が、月8時間以上を食い潰している現場が珍しくありません。

読み終わった後には、自社の現場で何から手をつけるかが具体的に見える状態になります。本記事ではインボイス対応AIで適格インボイスのチェックを自動化し、経理の月8時間突合を1時間以下まで減らす5ステップを、私が実際に現場で組み立てている設計図のまま解説します。

適格請求書の手作業チェックが経理を消耗させる構造

インボイス制度が始まってから、経理現場の負荷は単純に1.5倍ではなく、確認項目が増えたぶん「集中力を奪う作業」が一気に増えました。私が伴走している中小企業の経理現場では、取引先50社以上・月100件超の請求書を目視で突合し、月8時間以上を確認作業に費やしているケースが珍しくありません。経理の仕事の中身が「処理」から「判定」に変わってしまったというのが、いちばん大きな変化です。

月100件超を目視突合する経理の現実

適格請求書として認められるには、登録番号(T+13桁)・適用税率ごとの区分・税率ごとの消費税額・記載項目の整合といった要件をすべて満たす必要があります。これを毎月100件分、紙とPDFが混在した状態で1枚ずつ目で追っている経理担当者にとって、「どこで集中力が切れたか」によって見落としリスクが大きく変わります。1件あたり3〜5分でも、100件で5〜8時間に膨らみます。

突合精度が落ちる5つの典型パターン

私の経験では、現場で見落としが起きるのはほぼ次の5パターンに集約されます。「登録番号が空欄／T抜け／桁数違い」「税率8％と10％の区分記載漏れ」「消費税の端数1円ずれ」「品名は近いのに金額が一致しない」「請求日が30日以上前で計上月がずれる」。逆に言えば、この5パターンを機械的に検査できれば、人間の目は「最終承認」と「例外対応」だけに集中できます。

AI×GASによる適格請求書チェックの基本構造

仕組みの全体像はシンプルで、「読む」「照合する」「通知する」の3層に責任を分けることが基本です。読む層はAIが請求書PDFから登録番号・税率・金額・取引先名などを構造化データに変換し、照合する層はGASやスプレッドシートが国税庁公表サイトと自社の仕入計上データに突き合わせ、通知する層はSlackやメールで「要確認案件だけ」を担当者に渡します。1層でも省くと、現場で運用が回らなくなります。

「読む」「照合する」「通知する」の3層分担

読む層を全部AIに任せ、照合と通知も同じプロンプトで一気にやらせようとすると、月100件のうち5〜10件くらいは原因不明のミスが残ります。これは私が現場で何度も観察した失敗パターンで、AIに「判定」までさせると、なぜそう判定したかの根拠が追えないのが致命的です。「データ抽出はAI、判定ロジックはGAS、通知はチャットツール」と役割を明確に切るほど、運用は安定します。

必要なツール構成と接続関係

中小企業の現場で実装する場合、最小構成は次の4点で十分です。Google Drive(請求書PDFの集約箱)・Google スプレッドシート＋GAS(突合と業務ロジック)・生成AI API(PDFの構造化と曖昧マッチ)・Slackかメール(要確認通知)。会計ソフト側はfreeeや弥生のAPIで仕入計上データと連携します。freeeは2025年にAIエージェント向けのMCPサーバー(freee-mcp)をOSS公開しており、AIから直接会計データを操作する流れが本格化しています。新ツールを追加するより、すでに使っているスプレッドシートやSlackをそのまま活かす設計のほうが、定着率は圧倒的に高いです。

適格請求書の自動チェック5ステップ

ここからが本題で、私が現場で実際に組んでいる適格請求書AI自動チェックの設計を、5ステップで分解します。1ステップずつ「人間が判断していたものを、機械に任せる範囲を広げていく」という見方で読むと、自社で何から着手するかが見えやすくなります。

ステップ1：請求書PDFをAIで構造化データ化

受領した請求書PDFは、メールや郵送でフォーマットがバラバラなまま届きます。これを生成AIでまず「登録番号・取引先名・請求日・税率別の金額・消費税額・品目」の項目に構造化します。プロンプトでは「不明な項目は空欄で返す」「金額は半角数字に統一する」「日付はYYYY-MM-DD形式」と出力フォーマットを必ず固定するのが要点です。出力フォーマットを縛らないと、後続のGAS処理が壊れます。

ステップ2：登録番号(T+13桁)と国税庁公表サイトの突合

適格請求書発行事業者かどうかは、国税庁の「適格請求書発行事業者公表サイト」のWeb-API経由で番号照会できます。ステップ1でAIが抜き出した登録番号に対し、GASからAPIを叩いて「公表されているか」「公表名が請求書の社名と一致するか」「失効していないか」の3点を自動チェックします。番号が空欄、Tが抜けている、桁数が違うものは、ここで自動的に要確認フラグが立ちます。

ステップ3：税率・端数・記載項目の抜け漏れ検査

次に税率8％と10％が混在する取引で「税率ごとの区分記載がされているか」「税率ごとの合計額・消費税額が請求書面に明示されているか」「消費税の端数処理ルールが社内基準に沿っているか」を自動検査します。私の現場では「消費税端数±1円までは許容」「品名類似度80％以上は同一品目とみなす」といった許容範囲を最初に決めて、その閾値をGAS側に書き込んでいます。閾値を曖昧にしたまま自動化すると、毎日「これはどう扱うのか」を経理が判断する作業に逆戻りします。

ステップ4：仕入計上データとの自動マッチング

構造化された請求書データを、会計ソフト側の仕入計上データ(発注書・納品書ベース)と自動マッチングします。取引先名・金額・請求日の3軸で完全一致したものは「自動承認候補」、許容範囲内のずれは「要レビュー」、一致しないものは「要調査」と3段階に振り分けます。実務では完全一致は7〜8割で、残りの2〜3割を人間がチェックする運用に落ち着きます。最初から100％の自動化を狙わず、「人間が確認するロットを8時間→1時間に圧縮する」という発想が正解です。

ステップ5：要確認案件のSlack/メール通知＋証跡保存

最後に、要確認・要調査と判定された案件だけをSlackやメールで担当者に通知します。通知には「請求書PDFのリンク」「自動判定の根拠(どの項目がNGだったか)」「過去の類似案件のリンク」を必ず添えます。同時に、判定結果と判定根拠は監査用にスプレッドシートへ自動追記します。AIの判定ログを残しておかないと、税務調査で「なぜこの請求書を仕入控除に使ったか」を聞かれた時に説明責任が果たせません。

内製化ではなく外部に頼むべき4つのポイント

ここまで読めば自社のエンジニアでも作れそうと感じる方も多いはずです。実際に作ること自体は不可能ではありません。ただ、私の経験では、自社内製での運用が3〜6ヶ月以内に止まる失敗パターンが圧倒的に多いです。理由は4つあります。

法令改正・国税庁仕様変更への追随コスト

インボイス制度は施行後も経過措置・申告書様式・公表サイトの仕様が継続的に更新されます。一度組んだチェックロジックは、半年〜1年単位で必ず見直しが必要になります。社内で作った人が異動したり退職した瞬間に、改修が止まる現場を私は何度も見てきました。

GAS6分制限・大量PDFのタイムアウト対策

Google Apps Scriptには1回の実行が6分で強制終了されるという制約があり、月100件超の請求書をまとめて処理しようとすると必ずタイムアウトに引っかかります。バッチ分割・トリガー再起動・処理状況のステート管理など、本職のエンジニアでないと設計しにくい工夫が必要です。社内の片手間で組むと、ここで毎月のように手動再実行が発生します。

エラー検知と業務継続のための運用設計

AIのレスポンスエラー・APIの一時障害・PDFの読込失敗は、必ずどこかで起きます。これを「気づいたら止まっていた」のではなく、「止まったらSlackに通知が飛ぶ」「再実行ボタンが用意されている」状態にしておく運用設計は、業務システムを作り慣れた人でないと抜けます。エラー通知が未設定のまま運用に入ったために、月末まで止まっていることに誰も気づかなかった失敗実例が現場にあります。

AI判定基準のチューニングは現場知見が必要

私の考えでは、突合の自動化で最も重要なのは、AIに何をどう判定させるかのプロンプト設計です。「ここまでは自動承認、ここからは人間レビュー」という線引きは、その会社の取引先構成・税理士の指導・社内承認フローによって毎社違います。導入後の最初の1〜2ヶ月分は、必ず人間のダブルチェックを並走させて、AIの判定基準を会社ごとにチューニングしていく必要があります。AIの出力は、あくまで判断材料です。最終責任は人間が持つという設計を最初から組み込む必要があります。

ビフォーアフター：経理の月次クローズがここまで変わる

Before：現状の苦しい1ヶ月（請求書到着〜計上完了）

月初：取引先50社から請求書が紙・PDF・メール本文で届き、まずファイル整理に半日。月中：1件ずつ登録番号と税率をチェックし、社名のゆれや桁違いを目視で見つけて差し戻しメールを書く。月末：仕入計上との突合で社名表記ゆれや消費税端数のずれと格闘し、月次クローズが2〜3日後ろ倒し。経理担当者は本来やるべき資金繰り見立てや経営層への数字説明にほとんど時間を割けない、というのがBefore側の典型的な姿です。

After：導入後の楽な1ヶ月（自動チェック→例外対応のみ）

請求書がメールで届いた瞬間に自動でDriveに格納され、AIが構造化、GASが登録番号と仕入計上データを突合、要確認案件だけがSlackで担当者に届きます。私がfreee連携で毎月50件前後の請求書処理を構築した現場では、月12時間超かけていた請求書業務が、最終的に月1時間以下まで縮みました。経理担当者は「処理担当」から「例外判断と数字の語り部」に役割が変わり、月次クローズが3営業日早まった現場もあります。

違いを生んでいるのはツールではなく運用設計

同じAIと同じGASでも、運用設計次第で「結局1人の担当者がチェックし直して終わる」状態と「経理の月次が3日早まる」状態に分かれます。違いを生んでいるのはツールではなく、許容誤差の事前設定・例外通知の運用ルール・AI判定の責任分界の3つです。うちはまだBefore寄り、Afterに近づきたいと感じた方は、次のセクションで具体的な相談導線を案内します。

よくある質問

公開日：2026年5月