経理担当者が生成AIで証憑不備を事前発見するまで

午前八時、青葉商事の経理部には、複合機の低い音とキーボードをたたく音が重なっていた。窓から差す春の光が、机の上の紙の領収書と、開きっぱなしのPDF画面を白く照らしている。春はコーヒーをひと口飲み、今日の支払分を一枚ずつ手に取った。

春は、書類の端をそろえるのが好きだった。小さなずれにも気づく性格で、申請者の名前や日付を、いつもていねいに確かめていた。けれど、月末が近づくと、整えても整えても書類の山は低くならなかった。

紙の領収書には「山田商店」と、少し右上がりの文字で書かれていた。金額の最後の数字はインクがにじみ、税区分の欄には、申請画面の「課税仕入れ」と違う印がついている。春は領収書を画面の横に置き、眉を寄せた。

「この山田商店は、どの山田商店だろう」

会計システムの取引先欄には、「山田商店株式会社」と表示されていた。共有フォルダのPDF請求書には「YAMADA SHOTEN」とあり、過去の台帳では、さらに別の略称が使われている。名前は似ているのに、住所や担当部署まで一度に比べられる画面はなかった。

春はメールソフトを開き、検索窓に「山田」と入力した。古い見積書、営業部からの転送メール、昨年の支払確認が次々に並び、画面の端で読み込みの丸がくるくる回る。会計システムと台帳とメールを行き来するうち、机の上には確認途中の書類が三つの小さな山になった。

「前に同じ名前の会社があった気がする。でも、どのメールだったかな」

そのとき、後ろから部長の声がした。部長の手には、営業部から届いた経費精算の一覧がある。添付されたPDFには領収書がついていたが、申請の日付と利用日が合わず、摘要には「取引先訪問」とだけ書かれていた。

「春さん、支払処理だけでなく、規程違反がないかも見ておいてください。税区分の誤りや、同じ領収書の重複も、支払う前に気づけると助かります」

「はい。確認してから回します」

春はうなずいた。声は落ち着いていたが、指先は止まらなかった。取引先名、利用日、金額、税区分、領収書の有無を、ひとつずつ申請画面と見比べる。ひとつの欄が空いているだけでも、申請者へ戻して、理由を書いてもらわなければならない。

山田商店の領収書に戻ると、今度は別の違和感が見えた。紙には税額の記載があるのに、経費申請では税抜金額だけが入力されている。過去の仕訳を見ると、同じ店の昼食代は「会議費」、別の日の品物は「消耗品費」になっていた。

「同じ店でも、買ったものが違う。名前だけでは決められないな」

春は、取引内容を確かめるために営業部へメールを書いた。送信ボタンを押す前に、似た内容のメールが以前にもあったことを思い出す。受信箱の奥から探し出したメールには、「前回も確認に時間がかかったので、今回は急ぎでお願いします」と書かれていた。

時計の針が進むたび、支払日が近づいてくる。プリンターから新しい請求書が吐き出され、控えめな音を立ててトレーに重なった。春が一枚を取ると、そこにも取引先名の表記と税区分の違いがあった。

机の右側では、確認済みの書類がきれいに並んでいる。左側では、住所を照らし合わせるもの、申請者に聞くもの、もう一度規程を読むものが増えていた。会計システム、共有フォルダ、メール、過去の台帳はすべて開いているのに、証憑の全体はまだ見えなかった。

春は、画面の隅に表示された確認待ちの件数を見つめた。紙の領収書を指で押さえながら、見落とした一枚が支払後に見つかったら、仕訳だけでなく規程の確認もやり直しになると思った。AI-OCRや生成AIという言葉は聞いたことがあったが、青葉商事の机では、まだ人の記憶と検索だけが頼りだった。

「このままでは、気づけるものまで見落としてしまうかもしれない」

春はそうつぶやき、次のPDFを開いた。複合機はまた紙を吐き出し、確認待ちの証憑は、朝の光の中で静かに増えていった。

支払処理の直前、春は請求書と経費申請の不一致を見つけた。画面の時計が静かに進むなか、青葉商事の経理部には、紙をめくる音とキーボードの音が重なっていた。支払予定の一覧には、確認を終えていない取引がまだ残っていた。

春は、営業部から届いた請求書を取引先マスタと照らし合わせた。請求書には「山田商店株式会社」とあるが、マスタには「山田商店」と登録されている。過去の仕訳画面では、英字の「YAMADA SHOTEN」も同じ取引先として並んでいた。

「名前が違うだけなら、いつもの表記ゆれかもしれない。でも、請求書の中身も見ないと」

春は請求書の明細に目を移した。金額と取引日は読めたが、税区分の印字が薄い。紙の領収書を拡大しても、税率を示す部分はかすれていた。申請画面では、申請者が別の税区分を選んでいる。

「請求書は課税仕入れ。申請は対象外になっている……」

春は、画面を何度も見比べた。申請者の摘要には「展示会備品」とあるが、請求書には「備品一式」としか書かれていない。領収書の端には手書きの文字があり、発行日らしい数字の一部も、インクのにじみで読みにくかった。

隣の席の美穂が、椅子を少し近づけた。

「申請者に聞けそう？」

春は社内チャットを開いた。申請者の名前の横には、外出中を示す表示が出ていた。メッセージを送ったが、すぐに返事が届く気配はなかった。

「外に出ているみたい。取引先にも確認したいけれど、担当者の連絡先がすぐに出てこない」

春は契約書の保管場所を検索し、古いメールを開いた。山田商店から届いた過去の請求書には、税区分がはっきり書かれているものもあった。ただし、今回と同じ商品名はなく、同じ条件の取引だと決めることはできなかった。

そのとき、支払担当の理子が後ろから声をかけた。

「春さん、この請求書は今日の支払予定に入っています。保留にしますか、それとも確認済みにしますか」

「まだ決められない。税区分を確認できないまま進めるのは怖いです」

理子は支払一覧を見つめた。ほかの請求書にも、取引先名の表記が少し違うものがあった。経理部の空気が変わり、何人もの指が同時にキーボードを打ち始めた。

春は申請を差し戻した。理由には、取引先名の確認、税区分の再選択、読みにくい領収書の再提出を書いた。けれど、申請者が戻るまで、正しい情報はそろわない。

「差し戻しはできました。でも、今日中に戻ってこなかったら……」

春の声が小さくなった。理子は支払予定の一覧を確認し、山田商店の行に保留の印を付けた。金額を確定できないわけではない。だが、根拠となる証憑に不明な部分があるため、支払だけを先に進めることもできなかった。

少しして、課長の佐伯が経理部に入ってきた。春は請求書と申請画面を並べ、見つかった違いを順に説明した。佐伯は黙って画面を見たあと、請求書の薄い文字に目を近づけた。

「不備を見つけたことは大事です。けれど、支払処理の直前まで分からなかったことのほうが、もっと大きな問題です」

春は返事をせず、机の上の紙を見た。今回の不備は、入力を一度直せば終わるものではなかった。申請者への差し戻し、取引先への確認、支払予定の変更、過去の仕訳の検索が、ひとつの請求書から広がっている。

「証憑を受け取った時点で、取引先、金額、日付、税区分を見られていたら……」

「社内規程との確認も、その場でできれば手戻りは減りますね」と美穂が続けた。「紙やPDFを読み取るAI-OCRと、内容の意味を確かめる生成AIを組み合わせる方法もあります。AI-OCRは文字を読む道具で、生成AIは項目同士の違いを見つける道具です」

春は、画面の片隅にある確認待ちの一覧を見た。そこには山田商店の請求書のほか、取引先名が少し違う証憑や、税区分の確認が必要な申請が並んでいる。どれも、人が一枚ずつ開き、記憶と検索で確かめるしかなかった。

「見つけた不備を直すだけでは、追いつかないのかもしれません」

佐伯は静かにうなずいた。支払予定の一覧には保留の印が残り、確認待ちの証憑は消えなかった。春はその画面を閉じずに、次の一枚を開いた。

蒼は、春を小さな会議室へ誘った。机の上には紙の領収書があり、画面にはメールで届いたPDF請求書が並んでいた。今日は、証憑チェックの流れを一緒に試す日だった。

「春さん、この二つを同じ画面に取り込んでみよう」

蒼がスキャナーに領収書を通すと、紙の画像が画面へ移った。PDFも、指定した箱へ入れるだけで表示された。ばらばらだった証憑が、ひとつの一覧に集まっていく。春は、いつも机の上で探していた書類が、静かな列になっていくのを見つめた。

「まず、AI-OCRが文字を読みます。取引先名、金額、日付、税区分、請求番号、明細です」

画面の中で、領収書の文字に細い枠がついた。「山田商店」と読まれた名前は、取引先名の欄に入った。金額と取引日も、請求番号も、決められた項目へ整理された。手書きの数字には、読み取り結果と信頼度も添えられていた。

「AI-OCRは、文字を読む虫めがねです。紙やPDFを、あとから検索できるデータに変えてくれます」

「では、生成AIは何をするのですか」

「読んだ文字を、そのまま正解にはしません。取引先マスタや社内規程、過去の仕訳と比べて、違いを説明する係です」

蒼は、画面の参照先を順に開いた。取引先マスタには「山田商店株式会社」と登録されている。経費申請には「山田商店」とあり、会計システムには「YAMADA SHOTEN」と残っていた。生成AIは三つを同じ候補として示し、「表記は異なるが、住所と登録番号が一致」と理由を添えた。

次の欄には、金額と日付の照合結果が出た。領収書の金額は申請内容と一致していたが、利用日は申請日と少し離れていた。生成AIは「申請日ではなく利用日を確認してください」と表示し、確認できなかった項目を空白のまま残した。

「ただエラーと出すのではなく、どこを見ればよいかを返すのですね」

「そうです。税区分も、経費規程と過去の仕訳を見ます。たとえば会議費の候補でも、参加者や目的が足りなければ、判断できないと伝えます」

春が別のPDF請求書を開くと、税区分の欄が申請と違っていた。生成AIは、適格請求書発行事業者番号を国税庁の公開情報と照合する欄も示した。さらに、同じ請求書番号と金額が過去の一覧にないかを調べ、「重複の可能性は低い」と理由つきで返した。

「勘定科目も候補を出せます。品目や摘要を読み、過去仕訳と勘定科目マスタから、近いものを示します。ただし、候補は候補です」

蒼がそう言うと、画面には「消耗品費」と「会議費」が並んだ。過去の似た取引は消耗品費だったが、今回の摘要だけでは決めきれない。そこには赤い印で要確認と表示された。

「信頼度が高く、内容も一致したものは次へ進めます。でも、読めない文字や不一致があるものは、人に戻します。AIに無理に決めさせないのが大切です」

春は、山田商店の領収書を見た。以前なら、過去のメールを開き、台帳を探し、規程を読み直していた。今は、何が一致し、どこが分からないかが、一枚の画面に並んでいる。確認する順番まで見えると、胸の奥の重さが少しほどけた。

「最後の転記は、RPAに任せられます」

蒼がボタンを押すと、確認済みの取引だけが会計システムへ移り、結果一覧も作られた。RPAは決められた画面へ同じ内容を運ぶ係だ。承認や税務判断、例外取引を任せる係ではない。最終的な確認者と承認者は、一覧に名前を残す設計になっていた。

「便利でも、財務情報を個人向けアカウントへ貼り付けてはいけません。Microsoft Azure OpenAI Serviceのような法人向け環境を使う場合も、契約と設定を先に確かめます」

蒼は、紙を取り込む場所、生成AIが読むデータ、判定結果を返す場所を図にした。誰が承認するかも、図の端に書いた。操作記録と確認履歴を残せば、あとから元の証憑へ戻れる。春は、仕組みは便利さだけでなく、戻れる道まで用意して初めて安心になるのだと感じた。

「いきなり全部を自動化するのではなく、まずは一つの部門と、よく出る請求書だけで試しましょう。春さんが確認した結果も残せば、表記揺れや科目の迷いを次の判定に生かせます」

窓の外で、春の風が植木の葉を揺らした。確認待ちの証憑は、まだ机の上に残っている。それでも春は、山積みの紙ではなく、試す範囲を選べる仕事として見られるようになっていた。

「やってみよう。まずは山田商店を含む代表的な取引先から始めて、私が一件ずつ確かめます」

蒼はうなずき、画面に小さな検証用の箱を作った。春は最初の領収書をそこへ置いた。虫めがねのような読み取りと、質問を返す生成AIが、静かに動き始めた。

青葉商事は、請求書、領収書、経費精算の証憑を使った小さなPoCを始めた。いきなり全社へ広げず、営業部の一部と経理部だけで、AI-OCRと生成AIの判定を確かめる実験だった。

「PoCは、いきなり本番にせず、小さく試して確かめることです。今回は、100〜500件程度を集め、期間は2〜4週間程度にしましょう」

蒼は、社内RAGに登録された資料を開いた。RAGとは、社内規程や過去データから関係する情報を探し、生成AIの回答に添える仕組みだと、蒼はやさしく説明した。二人は、経理におけるAI活用の進め方にある検証の目安も参考にした。

春はMicrosoft Excelに、証憑番号、発行元、取引日、金額、税区分、勘定科目、判定結果の列を作った。PDFと紙の領収書はAI-OCRで読み取り、読み取ったデータを「01_取込」フォルダへ置く流れにした。Microsoft Power Automateで検証用の表へ移し、最後は必ず春が確認する設定にした。

最初の実行で、画面に赤い表示が続いた。机の上では「山田商店」、請求書では「山田商店株式会社」、過去仕訳では「YAMADA SHOTEN」となっていたため、AIは三つを別会社と判断したのである。

「発行元が不一致です。参照したマスタには、同じ会社だと分かる情報がありません」

春は、表示された理由を読んだ。AIが気まぐれに間違えたのではなく、取引先マスタに別名がなかった。表記の違いを人はすぐ分かっても、最初の設定だけでは、AIにも同じ会社だと分からなかった。

次に、手書き領収書でつまずいた。金額欄の「8」をAI-OCRが「3」と読み、3,600円の仕訳候補を作りかけたのだ。画像の横に元の領収書を表示し、春が止めたため、会計システムへ登録されることはなかった。

春は過去の正しい仕訳と、担当者が直した履歴を一行ずつ並べた。YAMADA SHOTEN → 山田商店株式会社、旧社名 山田物産 → 山田商店株式会社、消耗品費 → 会議費、課税仕入10％ → 軽減税率対象外。画面の修正前と修正後を見比べるうちに、AIを賢くする前に、会社のマスタと過去データを整えないといけないことが、春の手元にはっきり見えてきた。

春は取引先コードを変えず、別名、略称、旧社名をマスタへ追加した。勘定科目と税区分にも正式な表記を登録し、同じ意味の言葉を勝手に増やさないようにした。確認した履歴は、修正者と修正日時を残してExcelに保存した。

生成AIへの指示も変えた。結果を「正常」と一言で返さず、項目ごとに「一致」「不一致」「確認不能」のどれかを出し、その理由と参照元を添える形にした。発行元は「不一致」、理由は「請求書の山田商店とマスタの山田商店株式会社を照合できない」、参照元は「取引先マスタ」と表示される。

「確認不能は、無理に一致へ寄せません。専用の『要確認』箱へ送りましょう」

手書きの数字がぼやけたもの、領収書はあるが日付が読めないもの、請求書番号が空欄のものは、その箱へ入った。AIが自信のない証憑を正常扱いしないため、春は元画像を開き、人の目で確かめられた。

二週目には、日付と金額のルールを加えた。申請日より後の利用日、社内規程の上限を超える金額、同じ取引先・日付・金額の重複を確認した。例外的な返品や複数税率の請求書も混ぜ、ルールを足したことで見落としが増えていないか、春は正常な取引と並べて確かめた。

毎週金曜、春はAIの判定と人が修正した結果を突き合わせた。Microsoft Excelには、正答率、1件あたりの処理速度、例外発生率、差し戻し件数を週ごとに記録した。4週程度で正答率90％以上を目指す方法もあるが、それは保証された結果ではなく、青葉商事が検証の進み具合を見るための目安だった。

三週目の終わりにも、「要確認」の箱は空にならなかった。それでも、理由のない赤いエラーは減り、春は修正する場所をすぐ開けるようになった。支払日前の机には、見落としを恐れてメールと台帳を行き来する時間の代わりに、元画像と修正履歴を並べた静かな確認の時間が流れていた。

検証を始めてからしばらくたった朝、春が処理画面を開くと、問題のない証憑はすでに次の工程へ進み、画面には黄色い「要確認」だけが残っていた。以前は、紙とPDFを最初から読み直し、メールや会計システムを何度も往復していた。机の上に積まれていた確認待ちの束も、今朝は見当たらなかった。

一覧には、取引先、金額、取引日、税区分の確認結果が並んでいた。取引先マスタと名前が合い、金額と日付に矛盾がなく、税区分も社内ルールと一致した証憑は、静かに次の工程へ流れている。不一致や読み取りにくい文字があるものだけが、黄色い印をつけて春を待っていた。

「前は、全部を同じ重さで見ていたのに」

春は小さく息を吐いた。画面の白い部分が広くなったぶん、黄色の印は目についたが、その色には理由があった。確認する順番が、ようやく見えるようになっていた。

春は、黄色い証憑を一枚開いた。生成AIの理由欄には、「取引先名の表記がマスタと異なる」「税区分を判定できない」「領収書の金額が読み取りにくい」と表示され、比較したマスタや過去の仕訳もそばに示されていた。ただ「エラー」と出るのではなく、どこを見ればよいかが短い言葉で残っていた。

一枚目は、机の端にあった「山田商店」の領収書だった。画面には「山田商店株式会社」と表示され、過去の台帳には「YAMADA SHOTEN」と記録されている。AIは同じ取引先の候補を示したが、春は候補をそのまま確定せず、過去の修正履歴を開いてからマスタの登録を確認した。

次の請求書では、税区分の候補が二つに分かれていた。品目の文字は読めていたが、契約書の記載と請求書の摘要が少し違っていたためだ。春は蒼を呼び、契約書と社内規程を並べて確認した。

「候補は、答えではなくて入口だね」

「そうです。税務判断や例外取引は、最後まで人が見ます」

二人はAIの候補を採用せず、契約内容と社内規程に照らして処理を保留した。春が確認理由を書き込むと、その証憑は黄色いまま残ったが、次に同じ内容が出たときに参照できる記録になった。

蒼は、机の横に置いた導入検討資料を開いた。そこには、業務領域ごとの導入効果の目安として、入力・仕訳は約85％、請求書・支払は約80％、経費精算・立替は約75％と記されていた。これらは青葉商事の実績ではなく、社内RAG検索結果「導入効果・具体例」にある参考値だった。

「数字は、結果として掲げる前に、何を測ったものかを確かめよう」

蒼の言葉に、春はうなずいた。二人はその数値を社内資料の成果欄には写さず、導入前後の仕訳処理時間、差し戻し件数、エラー率、例外処理の量を記録する欄を検証表に作った。青葉商事の数字は、これから自分たちの記録で確かめることになった。

検証表の成功基準には、「手動確認と同等以上の精度」と「処理時間50％削減」と春が記入した。この50％は、青葉商事が設定した検証目標であり、達成実績ではない。出典は、社内RAG検索結果「PoCで測定すべき指標」と表の端に添えられた。

蒼の端末には、経理AIエージェント開発・構築の完全ガイドも開かれていた。資料には、ZOZO、タイミー、明治安田生命、頌徳会の導入事例が並んでいた。二人は事例の数字を青葉商事の成果と混同せず、月次決算日への影響や、担当者の工数をどう測るかという視点だけを参考にした。

昼前、春の確認方法はすっかり変わっていた。すべての証憑を最初から読み直すのではなく、AIが理由をつけて残した例外を、黄色い順番に開いていく。確認を終えたものは次の工程へ進み、判断を保留したものには、契約書や規程への参照が残った。

窓から差す光が、昨日までより明るく見えた。春の指は、画面の中を迷って行き来するのではなく、理由のある場所で止まっていた。黄色い「要確認」はまだ残っていたが、それは仕事が滞った印ではなく、人が判断すべき場所を知らせる小さな灯りになっていた。

夕方の経理部では、朝に積まれていた領収書と請求書の山が、きれいに消えていた。画面に残っているのは、人の確認が必要な証憑だけだった。

春は椅子を少し引き、最後の一枚を開いた。窓の外は薄い橙色で、プリンターの音も、朝よりずっと小さくなっていた。

「前なら、ここから全部を見直していたな」

表示された領収書には、取引先名と金額が正しく読み取られていた。AI-OCRが紙の文字を拾い、生成AIが取引先マスタと照らし合わせた結果だ。けれど、税区分の欄には、赤い文字で「確認不能」と出ていた。

「読めないところを、読めたことにしないんだね」

蒼が春の画面をのぞき込んだ。領収書の印字がかすれていて、軽減税率の対象かどうかを、画面の情報だけでは決められなかった。

春は取引内容を確認した。社内規程を開き、同じ店の過去の仕訳も見た。今回は会議用の弁当で、税区分は規程に沿って処理できると分かった。

「これは私が確認した、と残しておこう」

春は税区分を修正し、判定理由の欄に「会議用の飲食物。社内規程の該当項目を確認」と入力した。承認ボタンを押すと、担当者名と確認時刻も履歴に記録された。

蒼はその履歴を見ながら、取引先マスタの表記を整えた。店名の略称と正式名を同じ取引先として結び、今回の税区分のルールも照合条件に加えた。

「次に似た領収書が来たら、ここを手がかりにできるね」

「そう。でも、迷うものまで自動で決めないようにしておく」

画面の左側では、読み取りと照合に問題のなかった証憑が、仕訳や承認の次の処理へ静かに進んでいた。右側には、文字のかすれや規程との違いがあるものだけが並んでいる。高い確かさのものは流れ、曖昧なものは人のところへ戻る。その流れが、経理部の日常になっていた。

壁には新しい運用表が貼られていた。「個人アカウントでは証憑を扱わない」「法人向けの環境を使う」「保存先と承認経路を定期的に確認する」。誰がいつ何を直したか分かる監査ログも、確認する項目に入っていた。

春は運用表の端を指で押さえた。

「便利になっても、最後に確かめた人と理由は消さないんだね」

蒼は小さくうなずいた。生成AIの答えだけを残すのではなく、人が見た記録も一緒に残す。それが、月末の確認や内部統制の場でも、経理部を支えていた。

やがて、画面の「要確認」が一つずつ消えていった。最後の一枚を承認すると、春の画面は静かな白に戻った。

窓の外には、青葉商事の建物を照らす街灯がともっていた。春は更新された取引先マスタを保存し、明日の受信箱を開いた。

「明日の一枚は、明日の人が見ればいい」

そう言って春が席を立つと、経理部には、朝とは違う静けさが残った。机の上に紙の山はなく、次の証憑を受け取る場所だけが、明るく整っていた。