税務調査で請求データの提示を求められて詰まる会社の共通点｜電子帳簿保存法の検索要件を業務システムで満たす

調査官が求めるのは「書類」ではなく「検索できる状態」

税務調査で「令和6年10月分の、A社への請求データを見せてください」と言われる。紙のファイルなら綴りを開けば済みます。ところが電子取引になった途端、この一言で止まる会社が出てきます。

止まり方は決まっています。請求書PDFはメールの添付ファイルとして各担当者の受信箱に散っている。誰がどの取引先を担当しているかは頭の中。金額はExcel台帳に手入力されていて、PDF本体とは紐づいていない。結果、「探せば出てきます、明日まで待ってください」となる。

問題は書類がないことではなく、求められた条件で即座に絞り込めないことです。電子帳簿保存法が電子取引データに求めているのも、まさにそこです。

検索要件として何が求められているか

電子取引データの保存では、大きく「真実性の確保」と「可視性の確保」の2つが求められます。詰まるのはほぼ後者、なかでも検索機能の部分です。

要件	具体的に何が要るか	メール添付+Excel台帳での状態
取引年月日での検索	日付を条件に絞り込める	メールの受信日≠取引日。ズレる
取引金額での検索	金額を条件に絞り込める	Excelにはあるがデータ本体と別管理
取引先での検索	相手先名で絞り込める	表記ゆれ（(株)/株式会社/カナ）で漏れる
2項目以上の組み合わせ	日付×取引先などのAND検索	事実上不可。目視で突き合わせ
範囲指定	「〇月〇日〜〇月〇日」で指定できる	フォルダを1件ずつ開く
ディスプレイ・書面での速やかな出力	その場で画面表示・印刷ができる	ファイルを探す時間がかかる

一定規模以下の事業者には検索要件の一部が緩和される措置がありますが、その場合でも「日付・金額・取引先の順に整理して、求められたら速やかに出せる」状態は必要です。この緩和の対象範囲や判定に使う売上高の基準は改正で変わることがあるため、自社が該当するかは必ず最新の国税庁資料で確認してください。

なお、真実性の確保はタイムスタンプや訂正削除の記録が残る仕組み、あるいは事務処理規程の整備で満たす形になります。規程だけで運用している会社は、規程の内容と実際の運用がズレていないかが論点になります。

「ファイル名で頑張る」方式が3年で破綻する理由

検索要件への一番安い対応は、ファイル名を 20261031_株式会社〇〇_110000.pdf の形に統一して1つのフォルダに入れる方法です。国税庁の示す索引簿方式も含め、これ自体は認められた方法です。

ただ、実務で崩れます。崩れ方は3パターンあります。

1つ目は入力者による表記ゆれ。同じ取引先が「株式会社山田商店」と「(株)山田商店」で並び、取引先での絞り込みが片方しか拾わない。2つ目は月末の量。20日締めと月末締めが重なる日に50件のPDFを手動リネームすると、必ず桁を間違えたものが混ざります。3つ目は担当者の異動。ルールを知っている人が抜けた翌月から、ファイル名が元の invoice_final2.pdf に戻る。

これは業務システムを入れても現場がExcelに戻るのと同じ構造で、人の規律に依存した仕組みは、規律が切れた瞬間に元に戻ります。

あわせて読みたい業務システムが定着せず現場がExcelに戻る4つの理由｜導入前に見落とされること

最近は、請求書や領収書をAI-OCRに読ませて仕訳まで作る構成も増えました。ただし読み取った結果だけを保存して受け取った電子データそのものを残していないと、検索要件の前に保存要件から外れます。どこで分かれるかは請求書と領収書をAIに読ませて仕訳まで作ったら、電子帳簿保存法から外れていましたで整理しています。

業務システム側で満たすなら、どこを持つか

受発注・請求を業務システムで扱っているなら、検索要件は「機能」ではなくデータの持ち方の問題になります。押さえるのは次の4点です。

取引先をIDで持つ。名称は表示用で、検索キーは取引先マスタのIDにする。これで表記ゆれは検索に影響しなくなります。免税事業者かどうかの区分も同じマスタで持つと、区分が変わった時期の追跡もできます。

取引日と発行日を分けて持つ。メールの送信日でも登録日でもなく、取引年月日そのものを1カラムで持つ。ここが曖昧だと期ズレの説明ができません。

PDF実体と伝票レコードを1対1で紐づける。請求書を発行した瞬間にPDFを生成し、伝票IDで結びつけて保存する。人が後からファイルを置く工程を作らないことが要点です。

訂正・削除の履歴を残す。レコードを物理削除せず、誰がいつ何を変えたかを別テーブルに残します。

抽出用のクエリはこの程度の形になります。

SELECT i.invoice_no, i.trade_date, c.name, i.total_amount, i.pdf_path
FROM invoices i
JOIN customers c ON c.id = i.customer_id
WHERE i.trade_date BETWEEN '2026-10-01' AND '2026-10-31'
  AND i.customer_id = 1042
ORDER BY i.trade_date;

調査当日に求められるのは、これを画面から誰でも実行できて、結果をその場でCSVとPDFで出せることです。

あわせて読みたい免税事業者からの仕入税額控除が2026年10月に50%へ｜取引先区分を会計・購買データでどう持つか

既存システムに検索要件を足すときの現実的な順番

既に受発注システムを使っている場合、全部を作り直す必要はまずありません。多くは「データはあるがPDFと紐づいていない」状態なので、そこだけを埋めます。

一方、複数のクラウドサービスに取引データが分散している場合は先に整理が要ります。販売管理はA社、請求書発行はB社、受領した請求書はメール、という構成だと、検索要件を満たす場所が3つに割れます。どこを正本にするかを決めるところからです。

対応にかかる期間の目安は、既存システムの状態でかなり変わります。データが1か所にあり紐づけだけなら1〜2か月、正本の統合から入るなら4〜6か月を見ておくと現実的です。

あわせて読みたいバラバラに増えたクラウドサービスを1つにまとめるべきか｜中小企業の「システムが多すぎる」問題

自社で実装するときに手伝えること

えらびの道では、卸売の受発注・請求、出張販売の管理、介護のシフト管理、ECサイトなどの業務システムをオーダーメイドで開発しています。今回のテーマでいえば、取引先マスタのID化と表記ゆれの統合、請求書PDFの自動生成と伝票への紐づけ、訂正削除履歴のテーブル設計、調査時にその場で使える検索画面とCSV・PDF出力までが実装範囲です。データの可視化やレポートの自動化、機械学習による予測、リアルタイムなデータ収集基盤も扱っています。全部を一度に作らず、まず請求データの検索だけを動かして、受領側や仕入側へ広げていく進め方をとっています。

検索要件を満たす形に整えるところまで、えらびの道でお手伝いできること

合同会社えらびの道は、中小企業向けのシステム受託開発と、データ活用・DXのご支援をしています。卸売の受発注や請求、介護のシフト管理、出張販売の管理、EC・決済、業務データを集めて予測に使う基盤づくりまで、実際に現場で動くものを作ってきました。制度の解説にとどまらず、日々の業務が回る形に落とし込むところを引き受けています。

この記事で挙げた設計についても、御社の業務に合わせてお手伝いできます。取引先マスタのID化と表記ゆれの統合、請求書PDFと伝票データの紐づけ、取引日と発行日を分けて持つ構造、訂正削除の履歴が残る仕組み、調査の場でそのまま絞り込める検索画面とCSV・PDFの出力までが対象です。

進め方としては、全部を一度に置き換えることはしません。まず請求データの検索だけを動かし、受領側や仕入側は様子を見ながら移していきます。既に受発注システムをお使いなら、足りていない紐づけだけを埋める形になることもあります。

打ち合わせから開発まで同じ人間が担当しますので、要件が途中で伝わらなくなる心配もありません。えらびの道ではオンラインで30分ほどのご相談をお受けしています。費用はかかりません。

よくある質問

電子帳簿保存法の検索要件は、Excelの索引簿でも満たせますか？

日付・金額・取引先の3項目で検索でき、範囲指定と2項目以上の組み合わせができれば、索引簿方式も認められた方法です。ただし入力が手作業になるため、表記ゆれや月末の入力漏れでデータ本体とズレやすく、件数が増えるほど維持が難しくなります。

メールに添付された請求書PDFは、メールごと保存しておけばよいですか？

メールの保存だけでは検索要件を満たせません。受信日と取引年月日が一致せず、金額や取引先で絞り込めないためです。添付ファイルを取り出し、取引年月日・金額・取引先が検索できる形で別途保存する運用が必要になります。

小規模な会社でも検索要件への対応は必須ですか？

一定規模以下の事業者には検索要件の一部を緩和する措置がありますが、緩和されても求められたときに速やかに提示できる状態は必要です。対象となる売上高の基準や条件は改正で変わるため、自社が該当するかは最新の国税庁資料でご確認ください。