請求書の受領・承認・支払い・保存をつなぐ設計事例

本稿は特定事業者の導入実績や実測結果ではなく、請求書の受領・承認・支払い・保存を取引単位でつなぐための設計事例です。電子帳簿保存法、インボイス制度、消費税、所得税・法人税上の保存要件は、事業者と取引によって異なります。導入前に最新の国税庁情報と税理士等の確認が必要です。

目的

メール、クラウドサービス、郵送、手渡しなどで届く請求書を、受領から支払い、保存まで一つの取引記録として管理します。目的は紙をなくすことだけではなく、誰が受け取り、取引の事実と金額を確認し、誰が承認し、いつ支払い、どの原本を保存したかを追えるようにすることです。

現状と問題

請求書が担当者のメール、部門のクラウド、経理の紙ファイルに分かれていると、受領済みか、承認待ちか、支払い済みかが分かりにくくなります。同じ請求書を複数人が保存したり、支払期限直前に未承認に気づいたり、取引の根拠と請求内容を後から結び付けられないことがあります。

原因と確認するデータ

原因は、請求書の画像やPDFだけを保存し、仕入先、請求書番号、取引日、受領日、金額、税区分、支払期限、発注・検収の根拠、承認者、支払日、保存先が分かれていることです。導入前に、受領経路別の件数、承認の段階、支払期限、重複登録、差し戻し、原本の種別と保存場所を確認します。

変更した業務の流れ

請求書を受け取ったら、受領経路と原本の形式を記録する。
仕入先、請求書番号、請求日、金額で重複候補を確認する。
発注書、契約、納品、検収結果と照合し、取引担当者が内容を確認する。
経理担当者が必要項目、税区分、登録番号等の確認必要性を対象取引に応じて判断する。
金額や部門に応じた責任者が支払いを承認する。
支払予定日を登録し、期限が近い未承認・未手配を一覧にする。
振込み等の完了後に、支払日、支払額、結果、会計処理を取引記録に結び付ける。
電子取引データ、紙原本、スキャナ保存を区別し、該当する要件に従って保存する。

技術の役割

受領箱、取引台帳、承認ワークフロー、支払予定、証憑保存を取引番号でつなぎます。自動チェックは、重複候補、必須項目の空欄、発注額との差、支払期限超過候補を示す補助として使います。AIでPDFや画像から項目を抽出する場合も、金額、税率、支払先、支払期限を原本と照合し、抽出結果だけで支払いを実行しません。

人が判断すること・法令上の注意

取引の実在、納品・検収、請求金額、支払いの可否、税務上の取扱いは人が確認します。取引先マスターの振込先が変更されたときは、請求書に書かれた連絡先だけを使わず、登録済みの連絡先で事実確認します。

電子帳簿保存法では、電子メールの添付ファイルやクラウドサービス等で授受した取引情報を含むデータについて、保存義務者は一定の要件で電磁的記録を保存する必要があります。国税庁の電子取引関係の最新情報とQ&Aを確認してください。

また、仕入税額控除の適用には、一定の事項を記載した帳簿と適格請求書等の保存が要件となる場合があります。詳細は国税庁の適格請求書等保存方式（インボイス制度）を確認し、個別の適用は税理士や税務署等へ相談してください。

小さく試す方法

まずは一つの部門と一つの受領経路に限定し、取引先、請求書番号、金額、支払期限、承認状況、支払日、原本保存先を管理します。会計システムとの自動連携は後回しにし、重複登録と未承認を見つけられるか、税務上必要な保存が継続できるかを優先して確認します。

効果の測り方と限界

支払期限を過ぎた件数
請求書の受領から承認完了までの時間
請求書、承認履歴、支払結果の所在確認にかかる時間
重複登録、金額不一致、差し戻しの件数
経理担当者と取引担当者の確認回数

本稿は導入実績や税務判断を示すものではありません。データを一つにまとめても、検収、承認、支払い、保存の責任者が更新しなければ正しい状態は保てません。取引の種類、原本の形式、利用する会計・保存システムに応じて、手順を調整する必要があります。

目的