紙や画像で終わらせず、業務データとして扱う
領収書は紙ではなく取引データである
領収書は、支払いがあったことを示す証憑です。紙やPDF、レシート画像として保存されることが多いですが、実務ではそれだけでは足りません。
経費精算、会計入力、消費税処理、インボイス確認、電子帳簿保存、後日の検索に使うなら、領収書は「画像」ではなく「取引データ」として扱う必要があります。
つまり、領収書をただ保管するのではなく、日付、支払先、金額、税率、支払方法、用途、証憑ファイルを分けて管理する必要があります。
領収書は一枚の紙に見えます。しかし業務データとして見ると、そこには取引、税区分、支払、証憑ファイル、会計判断が含まれています。この層を分けられるかどうかで、後の経費精算や会計処理のしやすさが変わります。
領収書に必要な基本要素
一般的な領収書でまず確認すべき要素は、発行日、宛名、発行者、金額、取引内容、支払方法です。
発行日は、領収書を発行した日、または取引が行われた日です。宛名は、支払った人や会社名です。発行者は、店舗名、会社名、所在地などを指します。金額は支払総額で、但し書きや取引内容は何に対する支払いかを示します。
支払方法も実務では重要です。現金、カード、振込、電子決済では、後の確認方法や会計処理が変わります。領収書番号やレシート番号がある場合は、後から照合できるように残しておくと便利です。
また、印紙が必要な取引では印紙情報も確認対象になります。ただし、印紙税や領収書の扱いは取引内容によって変わるため、実務では税理士などの専門家確認が必要になる場合があります。
インボイスとして扱う場合の要素
インボイス制度では、領収書やレシートも、必要な事項が記載されていればインボイスとして扱われることがあります。
国税庁の説明では、適格請求書等の記載事項として、書類作成者の氏名または名称および登録番号、取引年月日、取引内容、税率ごとに区分した金額、適用税率、消費税額等、書類の交付を受ける事業者名などが示されています。
つまり、インボイスとして扱う場合は、単に「いくら払ったか」だけでは足りません。発行者、登録番号、取引日、取引内容、税率ごとの金額、消費税額まで確認できることが重要になります。
カラム分解の基本方針
領収書をデータベース化する場合、1枚の領収書を1テーブルに全部詰め込むと後で扱いにくくなります。
領収書は、ヘッダー、明細、税率別集計、支払情報、証憑ファイル、支払先、会計処理に分けて考える方が安定します。
たとえば、領収書そのものの基本情報は receipts に持つ。商品やサービスの明細は receipt_lines に持つ。税率ごとの金額や消費税額は receipt_tax_summaries に持つ。現金、カード、振込などの支払情報は receipt_payments に分ける。PDFや画像は receipt_files として管理する。
支払先は vendors としてマスタ化し、会計上の勘定科目や部門、案件、承認状態は accounting_entries のような会計処理側に分けると整理しやすくなります。
receipts：領収書ヘッダー
receipts は、領収書1枚ごとの基本情報を持つテーブルです。
ここには、領収書ID、領収書番号、発行日、取引日、受領日、支払先ID、領収書上の支払先名、インボイス登録番号、宛名、総額、通貨、税込・税抜区分、適格請求書フラグ、簡易インボイスフラグ、状態、備考などを持たせます。
ポイントは、支払先マスタの名前とは別に、領収書上の表示名をsnapshotとして残すことです。
会社名や店舗名は後から変わることがあります。支払先マスタを更新しても、当時の領収書に何と書かれていたかは変えてはいけません。証憑に書かれていた事実と、現在のマスタ情報は分けて扱う必要があります。
receipt_lines：明細行
receipt_lines は、商品やサービスの明細を管理するテーブルです。
ここには、明細ID、領収書ID、行番号、品目名、内容補足、数量、単価、税抜金額、税込金額、税率、軽減税率対象フラグ、勘定科目候補、案件ID、部門IDなどを持たせます。
レシートでは明細が多くなることがあります。会計上は「消耗品ほか」のようにまとめられる場合もありますが、データとしては明細を持てる構造にしておくと、後で検索や分析がしやすくなります。
ただし、すべての明細を必ず細かく会計処理するという意味ではありません。証憑データとして残す粒度と、会計仕訳としてまとめる粒度は分けて考えます。
receipt_tax_summaries：税率別集計
インボイス制度では、税率ごとの金額と消費税額が重要になります。そのため、明細とは別に receipt_tax_summaries を持つと扱いやすくなります。
ここには、税集計ID、領収書ID、税率、課税対象額、消費税額、税込合計、端数処理方法、標準税率、軽減税率、非課税、不課税などの税区分を持たせます。
明細の合計から税額を再計算するだけでは、領収書上の端数処理とズレることがあります。実務では、領収書に記載された税率別金額や消費税額を保持することが重要です。
税率別集計を分けておくと、インボイス確認、仕入税額控除、会計ソフト連携のときに扱いやすくなります。
receipt_payments：支払情報
領収書は「何を買ったか」だけでなく、「どう支払ったか」も重要です。
receipt_payments には、支払ID、領収書ID、支払方法、支払金額、支払日時、カード下4桁などの必要最小限の識別情報、振込元口座ID、立替者ID、精算状態などを持たせます。
カード決済、現金立替、会社口座振込、電子マネーでは処理が変わります。経費精算とつなげるなら、支払情報は領収書本体とは分けて持つ方が安全です。
特に立替精算では、領収書の発行者、支払者、申請者、実際に負担する会社が分かれることがあります。ここを曖昧にすると、後で確認が増えます。
receipt_files：証憑ファイル
receipt_files は、紙、PDF、画像、電子領収書を管理するテーブルです。
ここには、ファイルID、領収書ID、保存パス、ファイルハッシュ、ファイル形式、元ファイル名、スキャン日、撮影日時、取得元、OCR結果、OCR信頼度、保存状態などを持たせます。
電子帳簿保存法対応を考える場合、単にファイルを置くだけでなく、検索性、真実性、可視性、修正履歴などの運用も関係します。ここはシステム要件や税務判断が絡むため、実装時は専門家確認が必要です。
データベース上では、ファイルそのものと、ファイルにひもづく取引情報を分けておくと扱いやすくなります。画像は証憑、カラムは検索と処理のための情報です。
vendors：支払先マスタ
vendors は、支払先を管理するマスタです。
ここには、支払先ID、正式名称、カナ、インボイス登録番号、所在地、電話番号、標準勘定科目、有効・無効フラグなどを持たせます。
支払先をマスタ化しておくと、表記揺れを整理できます。同じ店や会社でも、領収書ごとに表記が違うことがあります。マスタを持つことで、検索や集計がしやすくなります。
ただし、領収書上の支払先名はヘッダーにもsnapshotとして残します。マスタは現在の管理情報、領収書は当時の証憑情報です。この二つを混ぜないことが重要です。
accounting_entries：会計・経費分類
会計処理に使う情報は、領収書そのものとは分けて持つ方がよいです。
accounting_entries には、会計処理ID、領収書ID、勘定科目、補助科目、税区分、部門、案件、利用者、申請者、承認状態、会計計上日などを持たせます。
同じ領収書でも、会計上の処理は会社のルールで変わります。証憑に書かれている事実と、社内で判断した会計分類は別物です。
ここを分けておけば、後から勘定科目や部門を修正しても、領収書そのものの情報を壊さずに済みます。
原本情報と社内判断を分ける
領収書をDB化するときに重要なのは、証憑に書かれている事実と、社内で判断した分類を分けることです。
領収書に書かれている事実は、発行者、日付、金額、税率、取引内容です。これは原本に基づく情報です。
一方で、勘定科目、部門、案件、経費区分、承認状態は社内判断です。後から変わることがあります。
この二つを同じカラム群に混ぜると、どれが原本情報で、どれが社内処理なのか分からなくなります。
領収書DBでは、証憑情報と会計判断を分けることが重要です。これができていると、検索、確認、会計連携、監査対応、修正履歴の管理がしやすくなります。
まとめ
領収書に必要な要素は、発行日、発行者、宛名、金額、取引内容、支払方法などの基本情報だけではありません。インボイスとして扱う場合は、登録番号、取引年月日、税率ごとの金額、適用税率、消費税額なども重要になります。
領収書を業務で使いやすくするには、1枚の画像として保存するだけでは不十分です。ヘッダー、明細、税率別集計、支払情報、証憑ファイル、支払先マスタ、会計処理に分けて管理する必要があります。
特に大切なのは、原本に書かれている事実と、社内で判断した会計分類を分けることです。領収書は証憑であり、会計処理はその証憑をもとにした社内判断です。
領収書をカラム分解する目的は、単にデータベースへ入れることではありません。検索できる、確認できる、会計処理できる、税率ごとに集計できる、後から証憑に戻れる状態を作ることです。