OCRとChatGPTで請求書処理を自動化する方法

要点： レイアウトを理解するOCRと、抽出したテキストを構造化された請求書項目に変換する言語モデルを組み合わせ、確信度がしきい値を下回るもの、そして仕入先の銀行口座情報の変更はすべて例外なく人に回します。入力と照合は技術がよく処理します。請求書詐欺は処理しません。そして実際に金額が動くのはそちらです。

買掛金処理は、ほかは自動化された経理業務の中に最後まで残る、本当に手作業の工程のひとつです。請求書がPDFで届き、誰かがいくつかの数字を読み取り、会計システムに打ち込み、上長に承認を催促し、あとで「いつ支払われますか」という仕入先のメールに返信する。これを月に二百回。

これはまさに今のAIが得意とする仕事の形です。多くの解説が飛ばすのは、この取り組みが純粋な利得になるのか新たな負債になるのかを決める部分です。自動化された買掛金パイプラインは、メールの受信箱から銀行の支払データまでを自動でつなぐ経路でもあります。検証を誤れば、仕入先を最も巧妙に騙った相手へ送金するための、速く記録も整った仕組みを作り上げたことになります。

買掛金の時間は実際どこに消えているのか

自動化の前に測ってください。ここでの思い込みはたいてい外れます。

請求書データの入力。 仕入先、請求書番号、日付、通貨、明細、税額、合計を書類から読み取ってシステムに打ち込む作業。退屈で間違いやすく、そしてAI抽出がほぼ丸ごと取り除ける部分です。

照合。 その請求書が、実際に発注し受け取ったものに、合意した価格で対応しているかの確認。部分的に自動化できますが、突き合わせる発注データと入荷記録があるかどうかに完全に依存します。

承認の催促。 たいてい時計の上では最大の塊です。請求書が九日間止まっているのは誰かが入力しているからではなく、予算責任者の受信箱で他の四百通の後ろに並んでいるからです。抽出だけ自動化して承認をそのままにすれば、買掛金回転日数はほとんど動きません。

例外処理。 発注番号の欠落、数量の不一致、返品値引、分割納品、通貨の取り違え。時間を不釣り合いに食い、しかも自動化の恩恵が最も小さい領域です。

このうちAI抽出が完全に解決するのは最初の一つだけです。それでも取り組む価値はありますが、誰かがこれで投資対効果を書き始める前に、期待値は正しく置いてください。

パイプラインを組む——まずOCR、次にAI抽出

なぜOCRと言語モデルは別の仕事なのか

この二つをひとつの工程として扱うことが、自作パイプラインの躓きどころです。

OCRはピクセルを文字と、その紙面上の位置に変換します。成熟した文書AIサービス——Google Document AI、AWS Textract、Azure AI Document Intelligence、ABBYY——はレイアウトを含む出力を返します。バウンディングボックス付きの単語、検出された表構造、多くの場合すでに暫定的に特定されたキーと値の組。この幾何情報は思われている以上に重要です。ある数字が合計だと分かるのは、近くに「Total」という語があるからだけでなく、それが紙面のどこにあり隣に何があるかによる部分が大きいのです。

モデルの仕事はその後から始まります。ラベルの揺れた乱雑なテキストを、きれいな構造化レコードに変えること。「Inv. No.」「Invoice #」「Ref」はすべて同じ意味です。03/04/26には互換性のない三通りの読み方があります。明細が二行に折り返されていることもあります。この正規化の判断こそがモデルの役割です。

マルチモーダルモデルは請求書の画像を直接読みOCRの呼び出しを省くこともでき、きれいなデジタルPDFではしばしばうまくいきます。一日に数枚の会社なら妥当な選択です。量がある場合は二段構えのほうがたいてい優れています。書類あたりのコストが安いこと。OCR結果を保存しておけば、プロンプトを変えたときに元ファイルを再処理せず抽出だけ回し直せること。そして、ある値が紙面のどの領域から来たかを指し示せること。最後の一つは、監査人に「この数字の出どころは」と最初に聞かれたときに効いてきます。

どちらの経路をとるにせよ、固定スキーマに対する厳密なJSONを求め、見つからない項目はもっともらしい値を推測せずnullを返すよう明示してください。欠落した項目は人に回りますが、自信を持って捏造された項目は回りません。

確信度のしきい値と承認ゲートはどう設計するか

三点照合が伝統的な統制です。請求書は発注書と入荷記録に、明細単位で、設定した許容差の範囲内で一致していなければなりません。発注書の運用規律がなければこの統制はそもそも存在せず、どれだけAIを足しても代わりにはなりません。

確信度には二種類あり、信頼できるのは一方だけです。モデルの自己申告は弱い信号で、モデルは自信を持って間違えることが十分にできます。内部整合性のほうがはるかに有用です。明細の合計は小計と一致するか。小計に税を足すと記載の合計になるか。その仕入先はマスタに存在するか。この請求書番号は重複ではないか。その税率はその法域で妥当か。こうした算術と参照の検査は、どんな自己申告スコアよりも多くの実際の誤りを捕まえますし、実装も安上がりです。

そのうえで、確信度だけでなくリスクで振り分けます。次のものは必ず人に回します。自分で決めた金額を超えるもの、初めて登場する仕入先、支払情報が登録内容と異なるもの、重複の疑いがあるもの。

絶対の規則として扱う価値があるのは一つだけです。抽出は買掛計上まではしてよいが、支払の実行は決してしてはならない。承認済みの買掛金までのストレートスルー処理は妥当な目標です。口座から金が出るところまでのストレートスルー処理は、確信度がいくつであっても妥当ではありません。

実例——受信箱のPDFから承認済みの買掛金まで

仕入先が買掛金専用のメールボックスに請求書を送ります。パイプラインは添付のハッシュを計算し、処理済みのものと完全に同一の重複を即座に破棄します。仕入先は再送してくるので、これを最初に置く価値があります。

OCRがレイアウト付きのテキストを返します。抽出工程はそれとスキーマをモデルに渡し、構造化レコードを受け取ります。仕入先、税務登録番号、請求書番号と日付、通貨、明細、税額、合計、支払条件、そして書面に印字された銀行口座情報。

次に検証が走ります。これはモデルではなくごく普通のコードで行います。算術が合うこと。仕入先がマスタに解決できること。その仕入先に対して同じ請求書番号が存在しないこと。通貨が実際に取引しているものであること。続いて照合です。発注書を見つけ、数量と価格を明細ごとに比べ、入荷記録を確認します。きれいな一致なら買掛の下書きが作られ、元のPDFが添付され、OCRの座標も保存されるので、どの数字も紙面上の位置まで遡れます。

ここからが、この工程の価値を証明する検査です。この請求書の銀行情報を、その仕入先について登録している情報と比較します。完全一致なら通常どおり承認待ちへ。どこかが違えば——口座番号、銀行、受取人名、SWIFTコードの変更だけであっても——そこで止まり、名指しされた担当者による帳票外の確認に回ります。そのメールへの返信ではありません。電話です。しかもこの請求書が届く前から登録してあった番号にかけます。

そのあとの承認はこれまでどおり進み、買掛金は人が実行する支払バッチに入ります。AIは入力と照合の大半を取り除きました。そして送金するかどうかの判断には一歩も近づいていません。

AI請求書抽出 vs 専用買掛金ソフト vs 手入力

• 導入コストと期間 — 手入力の勝ち。導入するものがありません。自作のAIパイプラインは数週間の作業です。既製の買掛金ソフトはその中間で、会計システムが対応済みなら設定は数日程度です。
• 請求書一枚あたりの運用コスト — 量があればAIパイプラインが最も安く済みます。既製ソフトは書類数かユーザー数の課金が多く、量が増えると最大の費目になり得ます。手入力は無料に見えますが、人件費という形で払っているだけです。
• 状態の悪い書類での精度 — 既製の買掛金ソフトの勝ちで、僅差ではありません。ベンダーは劣悪な写真を含む何百万枚もの実物で学習させています。汎用モデルはきれいなPDFでは立派ですが、折れた紙を斜めから撮った画像では明確に弱くなります。
• 承認ワークフローと監査証跡 — 既製ソフトの明確な勝ち。承認経路、代理、しきい値、改ざんできない監査ログは付加機能ではなく製品そのもので、これらをきちんと作り直すことが自作パイプラインの作業量の大半です。
• 特殊な会計システムとの適合 — 自作パイプラインの勝ち。台帳が地域固有だったり、古かったり、大きくカスタマイズされていたりすると、既製のコネクタは存在しないことが多いのです。
• 標準搭載の詐欺対策 — おおむね既製ソフトですが、製品差が大きいので前提にせず選定時に名指しで確認すべき項目です。「仕入先の銀行情報変更アラート」が、名前を挙げて聞くべき機能です。

率直な指針としては、月に百枚を下回るなら抽出を自動化する前に承認ワークフローを直してください。それを超えるなら、まず既製の買掛金ソフトを評価し、既製品がどうしても自社台帳に届かないときにだけ自作してください。作り直すことになるものの大半は、賢い部分ではなくワークフローと監査の仕組みだからです。

誰にも自動化できない詐欺の側面

書き換えられた銀行口座がすべてです。 成熟した請求書詐欺は偽の会社ではありません。実際に発注した商品に対する実在の請求書で、項目がひとつだけ変わっています。それ以外はすべて完璧に整合します。だからこそ、算術的な正しさを見る検査をことごとくすり抜けます。

類似ドメインと乗っ取られた返信スレッド。 そのメールは仕入先と一文字違いのドメインから来ているかもしれませんし、アカウントを侵害されたあとの仕入先の本物のメールボックスから来ているかもしれません。後者では、攻撃者は本物のやり取りの履歴の上に返信しています。

急かしが手がかりです。 期限前の支払いを迫る、供給が止まると警告する、「銀行取引の変更」を直前に知らせたことを詫びる。急かしは、誰かに検証の一歩を飛ばさせるために存在します。

モデルが読むのは書類であって状況ではありません。 抽出モデルは紙面に印字された口座を正確に報告します。それが与えられた仕事です。その口座が本当に仕入先のものかについて、モデルは何の見解も持ちません。

もともと持っていた情報に照らして、帳票外で確認します。 支払情報の変更があれば必ず、変更が申し出られる前から登録されていた番号へ電話をかけ、しかもその請求書を処理している本人以外がかける。ワークフロー上で飛ばせないようにし、ここで慎重になることが誤りとされることは決してないと全員に周知してください。

正しく進めるために——支払データの統制、メールセキュリティ、ITに任せる範囲

請求書は中立な書類ではありません。仕入先の銀行情報、交渉した価格、契約参照、そして実在する人の氏名を含みます。どの事業者のどの階層を使うのかを意識的に決め、それに実際に適用されるデータ取り扱いと学習利用の条件を読んでください。ビジネス向けやAPI階層は消費者向けチャット製品と異なるのが普通ですし、条件は変わるので提供元の最新ドキュメントで確認してください。書類は自社アプリケーションからAPI経由で流し、担当者が添付をチャット画面に貼る運用は避けます。

このパイプラインにはAPIキー、メールボックスへの接続、会計システムへの書き込み権限が要ります。この組み合わせは機微として扱う価値があります。キーはシークレット管理に置き、メールボックス接続は買掛金用の一箱だけに限定し、会計連携は買掛の下書きを作るのに必要な最小限の権限だけにします。AI+サポートはこの種のパイプラインを最初から統制された形で立ち上げることを支援し、管理型ITサポートは依存する人が一人でなくなったあとのID、アクセス、ライフサイクルを引き受けます。

メールボックスそのものが、いまや支払プロセスの本番入力です。求められるものが変わります。ドメインの認証設定、類似送信ドメインを捕まえるフィルタリング、仕入先スレッドの挙動がおかしいときのアラート。まさにマネージドメールセキュリティが存在する理由であり、買掛金自動化と並行して打てる最も効果の大きい一手です。午後を無駄にする失敗ではなく、六桁の損失を出す失敗のほうに効くからです。関心が仕入先請求書ではなく経費側にあるなら、姉妹記事のChatGPTとQuickBooks/Xeroで経費仕訳を自動化するがその業務を扱っています。Brocentは2007年の北京での創業以来アジアで管理型ITを提供しており、本社はシンガポール、2016年から香港オフィスを構えています。

よくある質問

スキャンや写真の請求書をAIは確実に読めますか？

役に立つ程度には確実ですが、無人で任せられるほどではありません。きれいなデジタルPDFは非常によく抽出でき、平らなスキャンもたいてい問題ありません。暗い場所で斜めに撮った写真、折れたファクス、印字の上の手書き注記で精度は落ち、しかも静かに落ちます。出力は相変わらず自信ありげに見えるからです。

AIが抽出した請求書を自動で支払ってよいですか？

いけません。抽出と計上の自動化は妥当ですが、支払実行の自動化は確信度に関係なく妥当ではありません。支払ゲートに人を残す時間的コストはごくわずかで——支払はどのみちまとめて処理します——抽出の誤りと実際に口座から金が出ることの間に立つ統制はこれです。

現実的な精度はどのくらいですか？

宣伝上の数字を信じず、自分で測ってください。精度は書類構成でほぼ決まります。実物の請求書を数百枚通し、人が抽出した結果と項目ごとに突き合わせ、書類単位ではなく項目単位で誤りを数えます。項目精度98%でも、少なくとも一項目が誤っている請求書の割合は無視できません。合計、銀行情報、請求書番号は別々に追ってください。

書き換えられた口座はどう捕まえますか？

仕入先ごとに登録された支払情報を保持し、届いた請求書すべてを自動で突き合わせ、差異があれば無条件で止めます。確認は、もともと持っていた番号への電話で、しかも請求書を処理している本人以外が行います。メールへの返信で確認しないこと、変更を申し出たのと同じメールに書かれた新しい番号を受け入れないこと。

仕入先の請求書をAI事業者に送っても安全ですか？

意識的に下すべき判断です。請求書には第三者の銀行情報と個人データが含まれるので、自社が使う階層について事業者の現行条件が保持と学習利用をどう定めているか、処理される地域が自社の義務に合うか、仕入先との契約が相手方の情報について何を約束しているかを確認してください。ビジネスまたはエンタープライズのAPI階層なら許容し、消費者向けチャット製品は許容しないと結論する組織が多くあります。

抽出を自動化しても発注書は必要ですか？

これまで以上に必要です。自動処理を安全にしているのは三点照合であり、それには突き合わせる発注書と入荷記録が要ります。発注書がなければ、パイプラインは請求書が算術的に正しく内部整合していることまでしか確認できません。それは、その商品を発注し、受け取り、その価格に合意したことの確認とは別物です。

まずどこから

何かを作る前に一週間かけて測ってください。請求書の枚数を数え、各段階の時間を計り、遅延のうちどれだけが入力で、どれだけが受信箱で止まった承認かを突き止めます。答えが承認なら、まずそこを直してください。安上がりで効果の大きい取り組みです。入力が本当に制約なら、きれいなPDFが届く仕入先カテゴリひとつで試験運用し、最初の一か月は人がすべての抽出を確認し、そして何よりも先に銀行情報の突き合わせを実装してください。パイプラインとメールボックスの統制、権限モデルを、経験のある相手にまとめて整えてほしいなら、お問い合わせください。