保存の要件と、自動化の設計が噛み合わない場所
請求書処理をAIで自動化する話と、電子帳簿保存法に対応する話は、社内では同じ検討として出てきます。ただし要求の性質が違います。自動化は「処理のどこを機械に渡すか」の設計です。保存の要件は、保存されているデータが受領時のままか、必要なときに探して出せるかという結果に対してかかります。
そのため、AIの読み取り精度をどれだけ上げても保存の要件は満たされません。逆に保存が要件どおりでも、探して出せない状態なら、税務調査や取引先からの問い合わせで手が止まります。噛み合わせるには、処理の段を分けて、どの段で保存の要件を担保するかを先に決めます。
この記事で扱うのは、受け取った請求書をどう保存し、どう探せる状態にするかまでです。受け取った請求書が適格請求書の要件を満たすかという内容の確認は、保存の要件とは別の制度の話になるため インボイス制度に対応した請求書チェックの自動化 に分けています。
なお、制度の要件は改正で変わります。以下は要件そのものの解説ではなく、要件を前提にしたときに自動化をどう組むかの整理です。自社が満たすべき内容は、国税庁が公表している取扱通達や一問一答、税務の専門家への確認で判断してください。
受領の形で最初に分岐する
請求書がどう届いたかによって、保存の区分が変わります。1つの経路だけを見て設計すると、他の経路が要件から外れます。
| 受け取り方 | 保存の区分 | 仕組みで押さえること |
|---|---|---|
| メールに添付されたPDF | 電子取引 | 受け取ったデータのまま保存する。紙に出力して保存で済ませる形は原則として認められない |
| 取引先のポータルからダウンロード | 電子取引 | 取得しない限り保存対象が手元にない。取得を担当者の記憶に任せず経路として組む |
| 郵送された紙 | 紙のまま保存、またはスキャナ保存（任意） | スキャナ保存を選ぶなら、解像度・入力期間・訂正削除の履歴の要件が加わる |
| 請求書受領サービスやEDI経由 | 電子取引 | サービス側の保存を正本とするか自社で持つかを決める。両方に散らさない |
| 同じ請求書が紙と電子の両方で届く | 受け取ったそれぞれ | どちらを処理の正本として扱うかを決め、その決め方を手順書に残す |
電子取引のデータ保存では、内容が改ざんされていないことの担保（真実性）と、画面や書面に出せて条件で探せることの担保（可視性）が求められます。前者は複数の満たし方から選ぶ形になっており、どれを選ぶかで自動化のときに作り込む場所が変わります。次の節で分けて見ます。
スキャナ保存は任意ですが、選ぶと要件が増えます。自動化の設計に直接効くのは入力期間です。受領から速やかに、または業務処理サイクル後に速やかに入力する必要があり、施行規則では前者がおおむね7営業日以内、後者が最長2か月とおおむね7営業日以内という形で定められています。解像度と階調にも基準があり、200dpi以上・赤緑青それぞれ256階調以上が原則です。つまりスキャナ保存を含めるなら、受領日とスキャン日を記録し、期限に近いものを通知する仕組みが必要になります。人が思い出して処理する運用では、月末に期限切れが出ます。
真実性をどの手段で満たすか
電子取引のデータ保存で選択肢が分かれるのは真実性の側です。制度上は、タイムスタンプを付す、訂正や削除の履歴が残るシステムで授受と保存を行う、訂正や削除ができないシステムで授受と保存を行う、訂正削除の防止に関する事務処理規程を定めて運用する、のいずれかを満たす形になっています。同じ「対応済み」でも、選んだ手段によって自分たちで組む部分が変わります。
| 満たし方 | 向いている状況 | 自動化で組む部分 |
|---|---|---|
| タイムスタンプを付す | 受領の経路が少なく、付与のタイミングを1か所に寄せられる | 受領から付与までを取りこぼさない経路。付与済みかを件数で照合する |
| 訂正・削除の履歴が残るシステムで保存する | 保存先を1つに集約でき、履歴の出力まで製品側で賄える | 各経路からその保存先へ入れる取込。履歴は自作せず製品側の機能に寄せる |
| 訂正・削除ができないシステムで保存する | 受領したデータを後から触る運用がなく、差し替えは新規登録で足りる | 訂正版を新しい受領として登録する分岐と、新旧の紐づけ |
| 訂正削除の防止に関する事務処理規程を定めて運用する | 保存先が既存のストレージで、当面は仕組みを増やせない | 規程で決めた手順から外れた操作に気付ける記録。人の遵守だけに頼らない |
規程で満たす方法は、着手時の負担がいちばん小さく見えます。ただし件数が増えるほど、規程どおりに操作されたことを後から示す手段が要ります。ここを担当者の記憶と目視に置いたまま取込だけを速くすると、保存されるデータは増える一方で、説明の材料は増えません。取込を自動化するなら、真実性をどの手段で満たすかを先に決め、それに合わせて取込の出口を作ります。
経路ごとに違う手段で満たす形もありえますが、どの経路をどれで満たしているかを一覧にしておかないと、経路が増えたときに抜けます。取引先の変更や新しい受領サービスの追加は、担当者の判断で増えることがあります。
検索できる状態を作る段が、AIといちばん接する
検索の要件は、取引年月日その他の日付、取引金額、取引先で探せること、日付や金額を範囲で指定できること、2つ以上の項目を組み合わせられることという形で定められています。税務職員のダウンロードの求めに応じられる場合や売上規模によって一部が不要になる緩和もありますが、自社が該当するかは別途確認が必要です。
ここで重要なのは、検索キーになる3項目が、まさにAIが請求書から抽出する値だという点です。抽出を誤ると、その請求書は「保存されているのに探しても出てこない」状態になります。金額の桁を1つ落としても、原本の見た目は何も変わりません。だから検索キーの3項目は、他の項目より検証を厚くします。
| 検索キー | ゆれの出方 | 仕組みで担保すること |
|---|---|---|
| 取引年月日その他の日付 | 請求日・発行日・締め日・支払期日が混在する。和暦や「3月末日」のような書き方もある | 保存項目に使う日付を1つ定義し、抽出時にその定義へ寄せる。原文の表記も残す |
| 取引金額 | 税抜と税込の両方が載る。小計・合計・今回請求額が並ぶ。外貨建てがある | どの金額を保存項目にするかを決め、明細合計と税額の検算を通してから確定する |
| 取引先 | 屋号と法人名、旧社名、支店名、全角と半角、株式会社の前後 | 取引先マスタのIDへ寄せ、マスタに無い場合は候補を示して人が選ぶ |
満たし方は3通りに分かれます。ファイル名に日付・取引先・金額を入れる方式、索引簿を別に持つ方式、保存先のシステムの検索機能を使う方式です。AIによる抽出を入れる場合、実際に自動化するのはこのファイル名や索引の生成です。人が命名を守り続ける前提を外せる代わりに、抽出誤りがそのまま検索性の欠落になります。命名規則を決めるときは、抽出できなかった項目をどう埋めるかまで決めておきます。空欄で通す設定にすると、後から探せない件が静かに溜まります。
AIの抽出値を、どこまで保存内容として扱うか
設計の分かれ目は、保存の正本を何にするかです。正本は受領したデータそのもの、つまりPDFや画像です。AIが抽出した日付・金額・取引先は、それを探すための索引と、会計処理へ渡す入力です。この2つを別に持ちます。
混ぜると何が起きるかというと、抽出値を直すたびに保存データを触ることになります。索引を直しただけなのに、保存されている内容を訂正した扱いになり、履歴の説明が複雑になります。原本は受領時に確定させて以後変更せず、抽出値は何度でも直せる別の層に置く。この分け方だけで、訂正の履歴が説明しやすくなります。
抽出値を確定させる前に機械で通す検証は、明細合計と請求合計の一致、税率ごとの対象額から計算した税額との一致、請求書番号と取引先の組み合わせによる重複の検出、取引先マスタとの照合です。合わなかったものだけを人に回します。この検証の組み方は 請求書処理の自動化をAIで進める で詳しく扱っています。読み取りをAI-OCRで組むか生成AIで組むかは AI-OCRと生成AIの違い の判断軸で決められます。
適格請求書の登録番号は、形式（Tと13桁の数字）の確認と、国税庁の公表サイトで照会した結果の記録までを機械に任せられます。ただし適格請求書として扱うかの判定と税区分の割り当ては、自社の会計処理の方針に依存するため人が持ちます。抽出できたことと、制度上そう扱えることは別だという線を引いておきます。記載要件の確認や経過措置の扱いをどこまで機械に任せるかは、保存の設計とは分けて インボイス制度に対応した請求書チェックの自動化 で扱っています。
訂正と削除の履歴をどう残すか
履歴は「消せないようにする」だけでは足りません。何が変わったのかを後から説明できる形にします。変更の種類ごとに扱いを決めておくと、記録の粒度が揃います。
| 何の変更か | 保存の扱い | 残す記録 |
|---|---|---|
| 抽出した検索項目を人が直した | 原本は変わらない | 直す前の値、直した人、時刻、直した理由の区分 |
| 別の書類として誤って登録した | 消さずに取り消しとして残す | 取り消しの操作者と承認者、対象のID |
| 取引先から訂正版が届いた | 新しい受領として保存し、旧版も残す | 新旧の紐づけと差し替えの理由 |
| 抽出の仕組みを更新した | 保存済みのデータは変えない | 更新した日時と内容、過去分を再抽出した場合はその範囲 |
| 保存期間を過ぎたデータを消した | 削除 | 対象範囲と承認、削除を実行した記録 |
記録は追記だけができる形に置きます。担当者が編集できる表計算で持つと、履歴そのものが書き換えられるため、担保として説明しにくくなります。
AIを使う場合に増える論点が1つあります。抽出は同じ入力で毎回同じ結果になるとは限らないため、抽出値には「いつ、どの仕組みで取った値か」を添えます。モデルやプロンプトを更新したあとで過去の請求書を再抽出すると、以前の値と変わる場合があります。そのときに、抽出の更新による変化なのか人が直したのかを区別できないと、経緯の説明が止まります。
訂正版を受け取ったときは、旧版を消さないことが要点です。差し戻して再発行を依頼した請求書も、受け取った時点で保存の対象になっています。「間違っていたから消す」を運用に入れないでください。
監査や税務調査で説明できる状態にしておく
求められるのは、条件を指定して該当の請求書を探して出せること、保存されているデータが受領時から変わっていないと言えること、訂正があった場合に経緯を出せることです。加えて、画面や書面に出せる環境と、システムの概要を説明する資料、訂正削除の防止に関する事務処理規程が必要になります。
AIを挟むと、この概要資料の書き方に気を使う必要があります。「AIが読み取っています」で終わらせず、どの段を機械が処理し、どこで人が確認し、誤った値をどう検出しているかを書ける粒度で設計しておきます。設計を後から文章にするのではなく、説明できる形の設計にしておくという順番です。運用ルールを禁止事項の列挙で終わらせない考え方は 生成AIの社内利用ルールをどう作るか と共通します。
説明できるかどうかは、自分たちで一度通してみると分かります。任意の1件を選び、日付と金額の範囲、取引先の組み合わせで検索し、原本を画面に出し、抽出値が原本と一致していることを確認し、訂正があればその履歴を出す。この一連が詰まる箇所が、そのまま調査で詰まる箇所です。担当者以外が実行できるかも一緒に見ておきます。特定の1人しか手順を知らない状態は、要件を満たしていても運用として弱いです。
どの順で手を付けるか
保存の要件と自動化を同時に作ろうとすると、要件の解釈で議論が止まって着手できません。順番を分けます。
- 経路の棚卸し … どの取引先からどう届いているかを数える。ここで区分ごとの件数が出る
- 電子取引の保存を先に要件どおりにする … AIを入れる前に、受け取ったデータをそのまま残し、探せる状態にする。ここは仕組みが単純なほど説明しやすい
- 検索キーの3項目の抽出を自動化する … 最初は全件を人が確認し、直しがどの項目に集中するかを記録する
- 自動で通す条件を記録から決める … 直しがほとんど出なかった項目と金額帯から人の確認を外す
- スキャナ保存はあとに回す … 要件が多く、入力期間の管理も加わるため、電子取引の経路が安定してから手を付ける
進める前に決めておくものは、保存項目に使う日付と金額の定義、取引先マスタの持ち方、事務処理規程の承認者、そして運用を直し続ける担当です。工程の切り方と見積の考え方は AIエージェント開発の進め方 にまとめています。制度の改正に合わせて手を入れ続ける前提を置くなら、外部への都度依頼ではなく社内で回せる体制のほうが向いており、その進め方は AI内製化の進め方 を参照してください。
まとめ：保存要件と自動化を噛み合わせる要点
- 保存の要件は処理の精度ではなく、保存されたデータと探せるかどうかにかかる。どの段で担保するかを先に決める
- 受領の形で区分が変わる。電子取引とスキャナ保存、紙のままを経路ごとに分け、1つの経路だけを見て設計しない
- 真実性は複数の満たし方から選ぶ。どれを選ぶかで自分たちが組む部分が変わるため、取込の自動化より先に決める
- 検索キーの日付・金額・取引先はAIが抽出する項目そのもの。誤ると「探しても出てこない」形で表れるため、他の項目より検証を厚くする
- 保存の正本は受領したデータ、抽出値は索引と会計処理の入力として別に持つ。混ぜると訂正の履歴が説明しにくくなる
- 履歴は追記のみの形で残す。抽出の仕組みを更新した記録も残し、人の訂正と区別できるようにする
- 訂正版を受けても旧版を消さない。差し戻した請求書も受領した時点で保存の対象になっている
- 電子取引の保存を要件どおりにしてから抽出を自動化し、スキャナ保存はあとに回す
- 請求書の内容が適格請求書の要件を満たすかの確認は、保存の要件とは別の制度。設計も記事も分けて考える
Augueでは、請求書のような書類の取込から抽出・検算・既存システムへの連携までを含めたAIエージェントの開発に対応しており、保存の要件をどの段で担保し、どこに人の承認を残すかの設計から一緒に検討できます。自社の請求書処理を制度対応と両立させながら自動化したい方は、是非ご相談ください。
関連する記事
書式の違う請求書を取り込んで会計へ渡すまでの設計は 請求書処理の自動化をAIで進める、受け取った請求書が適格請求書の要件を満たすかの確認は インボイス制度に対応した請求書チェックの自動化、読み取りの方式選びは AI-OCRと生成AIの違い、開発の進め方と見積の考え方は AIエージェント開発の進め方、社内ルールの作り方は 生成AIの社内利用ルールをどう作るか を参照してください。
よくある質問
市販の対応ソフトを入れる場合と、自社でAIを組む場合とで何が違いますか？
市販のソフトには法的要件への適合を第三者が確認するJIIMA認証があり、要件を満たしている根拠を製品側の資料で示せます。自社で組んだ部分は、どの要件をどう満たしているかを自分たちで説明できる形にしておく必要があります。保存自体は認証を受けた製品やサービスに任せ、抽出と検算だけを自社で組む構成も取れます。
紙で受け取った請求書は、スキャンしたあとに廃棄できますか？
要件を満たすスキャナ保存を行えば紙の廃棄は可能とされていますが、実務では読み取り結果の確認をどこで済ませるか、いつ廃棄するかを社内の手順として決めておかないと運用が揃いません。廃棄の可否と時期は自社の状況で変わるため、国税庁の公表資料と税務の専門家への確認をあわせて判断してください。
対応にはどれくらいの期間と費用がかかりますか？
一律の値は出せません。金額を左右するのは請求書が届く経路の数、既存の保存先やワークフローが検索と履歴をどこまで持っているか、会計側の受け取り形式です。見積の前に測っておくと判断できるのは、月あたりの件数、経路ごとの内訳、人の確認が必要になった件数の割合です。
インボイス制度への対応とは何が違いますか？
電子帳簿保存法は保存の要件、インボイス制度は仕入税額控除を受けるための請求書の記載や確認の要件で、別の制度です。自動化の設計では、登録番号と税率ごとの内訳という同じ抽出項目が両方に関わります。抽出は機械に任せられますが、適格請求書として扱うかの判定は人が持つ範囲です。
クラウドストレージにPDFを置くだけでは足りませんか？
置き場所の話と、要件として求められる検索の仕方や訂正・削除の扱いは別です。ファイル名の規則と事務処理規程で満たす方法もありますが、件数が増えるほど命名を人が守り続ける前提が崩れます。命名や索引の生成を自動化するか、検索と履歴を備えた保存先に移すかを先に決めてください。
小規模な事業者向けの緩和や猶予措置は使えますか？
売上規模による検索要件の緩和と、相当の理由がある場合の猶予措置が制度上あります。自社が該当するかは判定期間の売上高や状況で変わるため、国税庁の公表資料で確認してください。ただし緩和が使えても、探して出せない保存は締めや問い合わせの対応で困るため、検索性は実務の要件として別に考えます。