業務システム

電子帳簿保存法の検索要件：ファイル名・索引簿・DB検索の3方式で実装する手順と不要になる条件

電子帳簿保存法の検索要件：ファイル名・索引簿・DB検索の3方式で実装する手順と不要になる条件

電子帳簿保存法の検索要件は、施行規則第2条第6項第5号にある「取引年月日その他の日付・取引金額・取引先で検索できる」「日付と金額は範囲指定できる」「2項目以上を組み合わせられる」の3条件です。電子取引データには第4条第1項がこの号を準用し、ダウンロードの求めへの対応と基準期間の売上高5,000万円で必要な範囲が変わる仕組みです。この記事では、3条件をファイル名・索引簿・データベース検索の3方式で満たす手順を、命名チェックのPythonと検索SQLを添えて整理します。制度の全体像は電子帳簿保存法の3区分と対象書類の解説に任せます。

まとめ：検索要件はダウンロード対応と売上高で範囲が決まり、件数で実装方式を選ぶ

最初に決めるのは実装方式ではなく、自社に必要な要件の範囲です。税務職員のダウンロードの求めに応じられるようにしておけば、範囲指定と組合せの2条件は外れ、残るのは3項目で検索できることだけになります。さらに基準期間の売上高が5,000万円以下なら、3項目の検索機能そのものも不要です。

範囲が決まったら、月の証憑件数で方式を選びます。月数十件までなら「20260131_株式会社霞商店_110000」型のファイル名、百件前後なら国税庁サンプルに沿った索引簿、数百件を超えて入力者が複数ならデータベース検索が目安です。どの方式でも、記録項目の値の決め方は課税期間の途中で変えないでください。

検索要件の3条件を施行規則第2条第6項第5号から実装仕様へ書き下す

検索要件は条文を読むと短く、実装に落とすと判断箇所がいくつも出てきます。根拠は電子帳簿保存法施行規則（e-Gov法令検索）の第2条第6項第5号イ・ロ・ハで、電子取引データには第4条第1項が同号を準用しています。

取引年月日・取引金額・取引先の3項目を検索条件に設定する要件の中身

イの要件は「取引年月日その他の日付、取引金額及び取引先」を検索の条件として設定できることです。令和4年1月1日より前の電子取引では勘定科目などの主要な記録項目も対象でしたが、現行の3項目に絞られています。実装上は、1件の証憑について日付・金額・取引先名の3つの値を、ファイル名・一覧表・データベースの列のどこかに持たせれば足ります。

見落としやすいのは「検索結果として該当の記録事項だけを出力できる」ことまで求められている点です。国税庁の電子帳簿保存法一問一答【電子取引関係】（令和8年7月版）の問54は、取扱通達4－9を引いてこの点を説明しています。複数の請求書が1つのPDFに入っていると、検索しても1取引に絞り込めません。

範囲指定と2項目以上の組合せ検索で「かつ」だけ実装すれば足りる理由

ロの範囲指定は日付と金額だけが対象で、取引先は完全一致や部分一致で探せれば十分です。ハの組合せについて、一問一答の問49は「A又はB」の組合せは不要とし、「AかつB」に加えて、1項目で検索した結果を別の項目で絞り込む段階的な検索も認めています。

したがって検索画面に OR 条件を作り込む必要はありません。「2026年4月から6月」「10万円以上」「株式会社霞商店」を同時に指定して AND で絞れれば、ハの要件を満たします。Excel のオートフィルタを列ごとに順にかける操作が要件を満たすのも、この段階的検索の扱いによるものです。

ダウンロードの求めへの対応と売上高5,000万円以下で外れる要件の範囲

第4条第1項の柱書は、要件が外れる条件を2段階で定めています。どの要件が残るかを表にまとめます。

自社の状態 3項目の検索 範囲指定・組合せ
ダウンロードに応じない 必要 必要
ダウンロードに応じる 必要 不要
応じる＋売上高5,000万円以下 不要 不要
応じる＋出力書面を整理済み 不要 不要

売上高は一問一答の問51のとおり、法人なら前々事業年度、個人事業者なら前々年の売上高を税抜で判定します。消費税の課税売上高とは違い非課税売上を含み、営業外収益や特別利益は含みません。新設法人の1期目と2期目は基準期間が無いため、検索機能の確保は不要です。令和5年12月31日までに行った電子取引は旧基準の1,000万円以下で判定する点にも注意してください。

ファイル名方式で検索要件を満たす命名規則の設計と自動チェックの実装

ファイル名方式は、追加費用ゼロで始められる代わりに、命名の揺れがそのまま要件違反になります。一問一答の問50は、ダウンロードの求めに応じられることを前提に、3項目を「統一した順序で」ファイル名に入れれば検索要件を満たすとしています。

「日付_取引先_金額」型の命名規則を西暦8桁先頭で固める理由

問50が示す例は、2021年1月31日付の株式会社霞商店からの110,000円の請求書を「20210131_㈱霞商店_110000」とする形です。和暦と西暦はどちらでもよいものの、混在は抽出の妨げになるため統一が必要とされています。社内規程にするなら、次の4点まで決めておくと揺れが止まります。

  • 日付は西暦8桁で先頭に置き、ファイル一覧の名前順がそのまま日付順になるようにする
  • 取引先は登記上の商号で書き、「㈱」と「株式会社」のどちらかに統一する
  • 金額は円単位の数字だけにし、カンマ・円記号・税込表記を入れない
  • 区切りはアンダースコアに固定し、取引先名の中の空白は詰める

取引先ごとにフォルダを分けて保存している場合は、ファイル名を日付と金額だけにしても、フォルダ名と合わせて3項目で検索できれば要件を満たすと問50は述べています。

Pythonでファイル名を検証して命名違反を月次で洗い出すスクリプト

命名規則は人が守り続けられないので、月次の締めで機械的に検査します。次のスクリプトは保存フォルダ以下のPDFを走査し、規則違反を表示しつつ、合ったものから索引用のCSVを作る仕組みです。Python 3.9系以降の標準ライブラリだけで動きます。

import csv
import re
import sys
from datetime import date
from pathlib import Path

# 例: 20260131_株式会社霞商店_110000.pdf
PATTERN = re.compile(r"^(\d{8})_(.+?)_(\d+)\.pdf$")


def parse(name):
    m = PATTERN.match(name)
    if not m:
        return None
    ymd, partner, amount = m.groups()
    try:
        d = date(int(ymd[:4]), int(ymd[4:6]), int(ymd[6:]))
    except ValueError:  # 20260231 のような存在しない日付
        return None
    return d, partner, int(amount)


def main(root):
    rows, bad = [], []
    for p in sorted(Path(root).rglob("*.pdf")):
        r = parse(p.name)
        if r is None:
            bad.append(str(p))
            continue
        rows.append([r[0].isoformat(), r[1], r[2], str(p)])
    with open("index.csv", "w", newline="", encoding="utf-8-sig") as f:
        w = csv.writer(f)
        w.writerow(["取引年月日", "取引先", "取引金額", "ファイル"])
        w.writerows(rows)
    for b in bad:
        print("命名違反:", b)
    return 1 if bad else 0


if __name__ == "__main__":
    sys.exit(main(sys.argv[1]))

終了コードが1なら命名違反が残っています。index.csv は Excel のオートフィルタで範囲指定と組合せ検索ができるため、索引簿方式へ移るときの足場にもなります。

複数の請求書が入ったPDFを1取引単位に分割して検索単位を揃える

取引先から1か月分の請求書が1つのPDFで届くと、ファイル名に1組の3項目しか入れられません。問54は、データの同一性を保ったまま取引ごとに分割し、分割後のファイル名に規則性のある形で記録項目を入れる方法を示しています。ページの切り出しは取扱通達7－1(4)の「合理的な方法による編集」の範囲で、記録事項を書き換えるわけではありません。

分割と命名を毎月手で行う件数になったら、ファイル名方式の限界です。請求書の日付・金額・取引先を読み取る工程はAI-OCRの仕組みと精度の実測で扱った技術で自動化でき、その時点で次の索引簿方式かシステム方式へ移る判断になります。

索引簿方式で国税庁サンプルを元にExcel一覧と通し番号を対応させる手順

索引簿方式は、ファイル名には通し番号だけを付け、日付・金額・取引先は別の一覧表で管理するやり方です。問50は、Excel などで入力した一覧表の機能により範囲指定と2項目以上の組合せ抽出ができれば、システムが無くても検索要件を満たすとしています。

索引簿サンプルの列構成と連番ファイル名を突き合わせる運用ルール

国税庁は参考資料（各種規程等のサンプル）のページで「索引簿の作成例」をExcel形式（約11KB）で配布しています。連番・日付・金額・取引先・備考の一覧に、同じ連番を付けたファイルを対応させる構成です。

運用で崩れやすいのは連番の欠番と重複です。ファイルを削除した場合も索引簿の行は消さずに備考へ理由を残し、連番は年度ごとに振り直さず通しで管理します。訂正削除の防止規程と併用するなら、事務処理規程の作成方法と国税庁サンプルで扱った条文と備考欄の書き方を揃えておくと、調査時の説明が一本化できます。

索引簿から範囲指定と組合せ抽出を実演できる状態に整える確認手順

索引簿は「作ってある」だけでは足りず、税務調査の場で抽出を実演できる状態にしておきます。課税期間ごとに次の順で確認します。

  1. 日付列を文字列でなく日付型、金額列を数値型にそろえ、オートフィルタの範囲指定が効くか確かめる
  2. 取引先の表記揺れ（㈱と株式会社、全角と半角の英字）を置換で統一する
  3. 連番の最大値とフォルダ内のファイル数が一致するかを数える
  4. 「日付範囲かつ取引先」で抽出し、出てきた連番のファイルが開けるか数件試す

3番目の件数照合は毎月の締めに入れます。期末にまとめると、保存漏れに気づいても取引先への再発行依頼が間に合わないことがあるためです。

システム検索方式でDBのテーブル設計と検索クエリを要件どおりに作る

月の証憑が数百件を超えるか、入力者が複数の部署にまたがると、ファイル名と索引簿の手作業は破綻します。その段階では、証憑ファイルをストレージに置き、3項目をデータベースの列で持つ構成に移ります。以下は PostgreSQL 16系を想定した例です。

証憑メタデータのテーブルに日付・金額・取引先を持たせる列設計の実例

検索要件に直接関わるのは txn_date・amount・partner_name の3列で、残りは保存と真実性のための列です。amount を NULL 許容にしているのは、後述する金額のない契約書を「空欄」で登録できるようにするためです。

CREATE TABLE evidence (
    id            bigserial   PRIMARY KEY,
    doc_type      text        NOT NULL,
    txn_date      date        NOT NULL,
    amount        bigint,
    partner_name  text        NOT NULL,
    file_key      text        NOT NULL UNIQUE,
    sha256        char(64)    NOT NULL,
    fiscal_period text        NOT NULL,
    received_at   timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX evidence_date_idx    ON evidence (txn_date);
CREATE INDEX evidence_partner_idx ON evidence (partner_name, txn_date);
CREATE INDEX evidence_amount_idx  ON evidence (amount);

fiscal_period は課税期間の識別子で、後で述べる「一課税期間を通じた検索」と、記録項目のルールを期ごとに説明するときの単位になります。sha256 はファイルの改変検知用で、検索要件そのものではありません。このハッシュ値にタイムスタンプを付けてトークンを保管する列設計は、電子帳簿保存法のタイムスタンプ実装で扱っています。

日付範囲・金額範囲・取引先の組合せ検索を1本のSQLで満たす実装

検索画面の入力欄が空なら条件を外す形にしておくと、1本のクエリでイ・ロ・ハを同時に満たせます。$1〜$6 はアプリケーションから渡すパラメータです。

SELECT id, txn_date, partner_name, amount, file_key
FROM evidence
WHERE ($1::date   IS NULL OR txn_date >= $1)
  AND ($2::date   IS NULL OR txn_date <= $2)
  AND ($3::bigint IS NULL OR amount   >= $3)
  AND ($4::bigint IS NULL OR amount   <= $4)
  AND ($5::text   IS NULL OR partner_name LIKE '%' || $5 || '%')
  AND (NOT $6::boolean OR amount IS NULL)
ORDER BY txn_date, partner_name;

6番目のパラメータは「金額が空欄の証憑だけを探す」ためのもので、一問一答の問58が求める「取引金額が空欄であることを対象として検索できる」状態をここで満たします。ダウンロードの求めに応じる形式について問59は並び順を問わないとしつつ、通常出力できる形式で出すことを求めているので、同じ条件を psql の \copy で CSV に書き出せるようにしておけば足ります。

一課税期間を通じて検索できる状態をシステム更改後も保つ移行の注意

一問一答の問25は、取扱通達4－10を引いて、原則として一課税期間を通じて範囲を指定して検索できる必要があるとしています。期の途中で保存先を新システムへ切り替えると、旧システム分と新システム分を別々にしか検索できず、この原則から外れます。

問24は、変更前のシステムで検索機能が確保されていれば現行システムで検索できなくても差し支えないとしています。とはいえ旧システムを解約すれば検索手段ごと失われるので、移行は期首に合わせるか、旧データを3項目付きで取り込んでから解約する順序が安全です。帳票の出力・配信を含む切替順は帳票電子化の進め方（出力・配信・保存の順序）で整理しています。

記録項目の値の決め方で詰まる月まとめ請求・複数見積・金額なし契約

実装でいちばん手が止まるのは、3項目に「どの値を入れるか」が証憑から一意に決まらない場面です。一問一答は問55〜問58でこの扱いを示しており、共通の条件は「課税期間の中で自社のルールを一貫させること」です。

1か月分をまとめた納品書データは発行日と合計額で揃える一貫ルール

問55によれば、1か月分の取引がまとめて記録された納品書データでは、個々の取引ごとの日付と金額を使う方法のほか、データの発行日または受領日と合計額を使う方法も認められます。条件は、日付と金額の取り方を対応させることです。

日付を個々の取引日にしたなら金額も個々の取引額、発行日にしたなら合計額で検索できるようにします。システム方式なら、明細行ごとに evidence の行を作るか合計で1行にするかを、doc_type ごとに設計書へ書いておきます。

税抜か税込か・見積金額が複数・金額なし契約の記録項目の決め方

残る3つの迷いどころを、一問一答の回答と実装上の決め方で並べます。

場面 一問一答の扱い 実装での決め方
税抜か税込か（問57） 帳簿の経理方式が基本 証憑記載額でも可
複数の見積金額（問56） いずれの金額でも可 発注額など1つに固定
金額なしの契約（問58） 空欄か0円で可 空欄なら空欄検索を用意

問56は、課税期間の途中でルールを変えると検索が適切に行えなくなるおそれがあるとして、期中の変更を避けるよう求めています。ルールは経理規程か事務処理規程に書き、税務調査で説明できる状態にしておきます。

3方式の選び分けと自社開発に進むべき条件・見送るべき場面の判断

方式の優劣ではなく、件数と入力体制で決めます。ここでは採用と見送りの線を条件付きで言い切ります。

月間の証憑件数と入力担当の人数で決めるファイル名・索引簿・DBの境界

方式 向く規模 前提条件
ファイル名 月数十件・担当1人 ダウンロードに応じる
索引簿 月百件前後・担当1〜2人 連番と件数の月次照合
DB検索 月数百件超・複数部署 3項目の入力を自動化

件数の数字は国税庁の基準ではなく、手作業の命名と照合が月次締めの中で回るかどうかから置いた目安です。迷ったら索引簿で始め、照合で毎月ずれが出るようになった時点でシステム方式へ移ります。会計システムに証憑保存機能があるなら、3項目で検索できるかを先に確かめてください。

出力書面の整理や猶予措置に頼ると後で詰まる典型パターンと見送り条件

出力書面を日付と取引先ごとに整理して提示できるようにすれば検索機能は不要になりますが、問52のとおり日頃から書面に出力して整理しておく必要があります。調査の連絡を受けてから印刷を始める運用では、要件を満たしていたと認められないおそれがあり、証憑が増えるほど印刷と整理の手間も膨らむ一方です。

猶予措置も同じです。問93は、システムや社内ワークフローの整備が間に合わない事情を「相当の理由」の例に挙げ、事前申請は不要としています。一方で、整備できる状態にあるのに資金繰りや人手不足などの事情もなく要件に従わない場合は適用されません。猶予措置は準備期間の受け皿であって、恒久的な運用方式にはなりません。

逆に、自社開発に進まないほうがよい場面もはっきりしています。月数十件で担当が1人、ダウンロードの求めに応じられるなら、ファイル名方式と上の検査スクリプトで十分で、システム投資は過剰です。基準期間の売上高が5,000万円以下なら、検索機能自体が不要なので、保存の仕組みづくりは真実性の確保と保存漏れの防止に絞れます。複数部署から証憑が集まり、3項目の入力を OCR やワークフローと連携させたい段階に入ったら、既製品の選定は電帳法に対応する文書管理システムの選び方、業務に合わせた作り込みは文書管理システム開発として検討する段階です。

電子帳簿保存法の検索要件をファイル名やシステムで満たす際のよくある質問

ファイル名・索引簿・システム検索の実装で問い合わせが多い論点を、国税庁の一問一答の回答に沿って5つにまとめました。

ファイル名だけで検索要件を満たせるのはどんな場合ですか？

税務職員のダウンロードの求めに応じられるようにしていることが前提です。この場合は範囲指定と組合せの要件が外れるため、取引年月日・取引金額・取引先の3項目を統一した順序でファイル名に入れておけば、3項目で検索できる要件を満たします（一問一答の問50）。ダウンロードに応じない場合は範囲指定と組合せが必要になるので、ファイル名から索引用の一覧を作る、または索引簿を併用する形にしてください。

売上高5,000万円以下なら検索要件は何もしなくてよいですか？

判定期間に係る基準期間の売上高が5,000万円以下で、ダウンロードの求めに応じられるようにしていれば、検索機能の確保は全部不要です。ただし電子データの保存義務と、改ざん防止などの真実性の要件は残ります。法人の判定対象は前々事業年度の売上高です（問51）。

スキャナ保存した書類にも同じ検索要件がかかりますか？

かかります。検索要件の条文である施行規則第2条第6項第5号はもともとスキャナ保存の要件として置かれており、電子取引データは第4条第1項でこれを準用しています。記録項目は同じ取引年月日その他の日付・取引金額・取引先です。スキャナ保存に固有の入力期間や解像度の要件はスキャナ保存制度の要件と始め方で確認してください。

取引先名の表記が「㈱」と「株式会社」で混在していると違反になりますか？

表記揺れそのものを違反とする規定はありません。ただ、取引先で検索して一部が漏れる状態では、該当する記録事項を探し出せると説明しにくくなります。命名規則や索引簿の入力ルールで商号の書き方を1つに決め、月次の検査で直しておくのが安全です。

メールで受け取った請求書は本文ごと保存しないと検索要件を満たせませんか？

メール本文に取引情報がある場合でも、取引情報が失われないならPDF等にエクスポート・変換して保存し、そのファイルに検索機能を備える方法が認められています（問53）。請求書が添付ファイルなら、その添付ファイルを命名規則に沿って保存すれば足ります。電子取引データ保存の要件全体は電子取引データ保存の要件と対応方法にまとめています。

関連記事

お気に入りに入れた記事の一覧

この記事は以下の記事からリンクされています

この記事に関連するサービス

資料請求

RELATED POSTS 関連記事

一覧へ戻る

目次