BtoB EC帳票の一括ダウンロード｜要件と設計手順

◆監修・編集責任者　小園 将隆　2026年8月26日

B2B EC-COLUMN

BtoB EC帳票の一括ダウンロードとは、複数取引分をまとめて取り出す仕組みである

BtoB EC帳票の一括ダウンロードとは、すでに交付が決まっている請求書・納品書などの帳票を、取引先が期間や取引単位でまとめて取得できる仕組みです。国税庁の一問一答【電子取引関係】（令和8年7月）は、この機能の要否を提供期間の設計から判断すべきことを示しています^*1。

この機能の設計範囲は、取引先が電子取引データの保存義務を果たせる形で受け取れるかどうかまで含みます。単に「まとめて落とせる」というUIの話ではなく、渡す側の設計責任が問われる領域です。

対象は「帳票種類・期間・取引先・粒度」の4軸で決まる

一括ダウンロードの設計は、まず対象の絞り込みから始まります。対象となる帳票種類（請求書・納品書・領収書など）、指定できる期間の範囲、対象にする取引先の単位、まとめる粒度という4つの軸を先に決めておきます。この4軸を固定すると、後続の機能要件が具体化しやすくなります。

単票ダウンロードとの違いは件数と検索性の担保にある

1件ずつの単票ダウンロードは、既存の帳票発行機能の延長で対応できる場合が多いです。一方で一括ダウンロードは、複数取引を横断して1回のリクエストで取り出す処理です。件数のスケールと、後から特定の取引を検索できる状態を維持する仕組みの両方が必要になります^*1。

本記事は「交付後に取引先が取り出す設計」に論点を絞る

帳票を電子データで交付してよいかという同意の論点、および帳票そのものの記載項目や検索要件の一般的な設計は、本記事では扱いません。ここでは、すでに交付が決まっている帳票を、複数取引・複数期間ぶんまとめて取引先が取り出す仕組みの設計に限定します。

一括ダウンロードの要否は帳票の提供期間で決まる

一括ダウンロードを作るべきかどうかは、機能の便利さではなく、帳票をサイト上に何年置いておくかという提供期間の設計で決まります。この判断軸を最初に固定しておくと、以降の要件がすべて筋道立って決まっていきます。

サイト上で随時確認できれば、取引先はダウンロード不要になる（問45）

国税庁の一問一答は、ECサイト上で領収書等データの確認が随時可能な状態であれば、購入者は必ずしもダウンロードして保存しなくても差し支えないとしています^*1。インターネット上でデータを確認できるようになった時点が、取引情報の授受があったタイミングと考えられるためです^*1。

随時確認可の条件は「真実性の確保」と「検索機能の確保」の充足である（問45・問18）

この取扱いには前提があります。ECサイト提供事業者が、保存義務者（購入者）において満たすべき真実性の確保および検索機能の確保の要件を満たしている場合に受けられる取扱いです^*1*2。したがって自社サイトがこれらの要件を満たしていなければ、取引先はサイト上の表示だけで保存義務を果たしたとは扱われません。

ただし検索機能の確保については例外があります。税務職員によるダウンロードの求めに応じられるようにしている事業者のうち、判定期間に係る基準期間の売上高が5,000万円以下の場合、または電磁的記録を出力した書面を取引年月日その他の日付および取引先ごとに整理して提示・提出できるようにしている場合は、すべての検索機能の確保の要件が不要とされます^*1。この場合、自社サイト側で検索機能を確保している必要はありません^*1。取引先の規模や運用によって求められる水準が変わるため、提供期間ポリシーは最も要件の厳しい取引先を基準に設計しておくと、後からの手戻りを防げます。

保存期間の満了前に見られなくなる設計なら、渡す手段が必須になる（問45）

各税法に定められた保存期間が満了する前に、ECサイト上でデータの確認ができなくなる場合があります。その場合は、確認できなくなる前にダウンロードして保存する必要があると明記されています^*1。つまり提供期間が保存期間より短い設計であれば、一括ダウンロード機能は任意ではなく必須の機能になります。

判断は「提供期間と保存期間の比較」から始める

整理すると、提供期間が保存期間以上であれば一括ダウンロードは任意の便利機能として位置づけられます。提供期間が保存期間より短い場合は、満了前に渡し切るための必須機能として要件定義しなければなりません。

この一点を決めずに機能から議論を始めると、後工程で仕様が二転三転しやすくなります。この判断を自社の運用でどう線引きするかを無料相談で整理することも、要件定義の手戻りを減らす近道です。

渡すデータの形が取引先の保存要件を左右する

一括ダウンロードを作る場合、渡すデータの形が取引先側の保存要件を満たせるかを決めます。ZIPにまとめて渡す設計は便利に見えますが、中身の作り方を誤ると取引先の検索要件を満たせなくなる恐れがあります。

複数の請求書を1つのPDFに詰めず、取引ごとに分割する（問54）

国税庁の一問一答は、複数の請求書等が含まれるPDFについて一つの対応方法を示しています^*1。取引ごとにデータの同一性を保持したまま分割し、ファイル名に規則性を持った形で記録項目を入力して一覧性を持って管理する方法です。

この方法は、検索要件を満たす一例とされています。1ファイルに複数取引を詰め込む設計は、この一覧性を損ないやすいです。

ファイル名は「取引年月日・金額・取引先」を統一した順序で入れる（問50）

検索機能を確保するシステムがない場合の方法もあります。ファイル名に「取引年月日その他の日付」「取引金額」「取引先」を統一した順序で入力しておく方法です^*1。

例えば「20260731_株式会社○○_1234500.pdf」のような命名です。日付・取引先・金額の順序を固定するファイル名規則を、ZIP生成時のロジックへ組み込みます。

月次まとめの帳票は、発行日と合計額を記録項目にしてもよい（問55）

1ヶ月分の取引がまとめて記録された納品書データもあります。この場合は、個々の取引ごとの日付・金額のほか、データを授受した時点の発行日と取引金額の合計額を検索項目として用いる方法も認められています^*1。ただし各課税期間で一貫した規則性を保つ必要があり、途中で運用ルールを変えないことが条件です^*1。

索引となる一覧表（CSV）をZIPに同梱する設計にする

表計算ソフトで取引年月日・取引金額・取引先を入力した一覧表を作成すれば、範囲指定や複数項目の組み合わせ検索ができる状態になります。これにより、検索機能の確保の要件を満たすと考えられています^*1。ZIPの中に個別PDFと一緒にこの一覧表（index.csv相当）を同梱しておくと、取引先側の管理負担を大きく減らせます。

大量件数を前提に非機能要件を先に決める

一括ダウンロードは、1回の操作で複数取引ぶんの帳票を生成する処理です。件数が増えると同期処理では応答時間の限界に達するため、機能要件よりも先に非機能要件を固めておく必要があります。

同期生成の限界を見極め、非同期ジョブ化を検討する

対象件数が数十件を超えると、リクエストを受けた画面でその場にPDFを生成してZIP化する同期方式は、応答時間の観点で成立しにくくなります。生成予約を受け付け、完了後に通知し、別途取得してもらう非同期ジョブの構成が現実的な選択肢になります。

件数・期間・容量の上限を決めずに実装すると負荷が跳ねる

「何件まで」「何ヶ月分まで」「何MBまで」という上限を決めずに実装すると、想定外の大量リクエストでサーバー負荷が跳ね上がる恐れがあります。上限を超える依頼は、期間を分けて複数回に分割してもらう案内をあらかじめ用意しておくと運用が安定します。

生成物の保管期間とURLの有効期限を設計する

生成したZIPファイルを自社サーバーにいつまで置いておくか、ダウンロード用URLをいつ無効化するかも決めておく項目です。生成物を無期限に残す設計は、ストレージ費用の増加だけでなく、退会後や与信停止後のアクセスという次節の論点にも関わってきます。

再ダウンロードの回数と監査ログを残す

同じ帳票の再ダウンロードを何回まで認めるか、誰がいつ何を取得したかを記録するログの設計も必要です。ログが無ければ、後から「渡した」「渡していない」という水掛け論を解消する手段がなくなります。

一括ダウンロードは認可制御の事故が起きやすい画面である

一括ダウンロードは、1回のリクエストで複数取引を横断して取り出す性質があります。この横断処理を実装する際に権限確認を誤ると、他社の帳票が混入する事故につながりやすい画面です。

外部から渡されるIDをキーにしない（IPA）

情報処理推進機構（IPA、独立行政法人として情報セキュリティ対策等を担う機関）は「安全なウェブサイトの作り方」で注意点を示しています。利用者IDをURLやPOSTパラメータに埋め込み、それをそのままキーにしてデータベースを操作する実装があるという指摘です。この実装では、ログイン中の利用者が他の利用者になりすまして操作できる脆弱性になります^*5。

対策は2つ挙げられています^*5。データベースを検索する利用者IDが、ログイン中の利用者IDと一致しているかを常に確認する方法です。もう一つは、利用者IDを外部パラメータからではなくセッション変数から取得する方法です。

一括ダウンロードは複数取引を一括で扱うぶん、この確認漏れが起きたときの影響範囲も広がります。

権限単位を細かくするほど事故リスクは下がり保守負担は増える

取引先企業単位で全帳票を見せるか、部署単位・担当者単位まで絞り込むかによって、実装コストと事故リスクは変わってきます。単位を細かくするほど利便性は保たれますが、権限テーブルの設計と保守の負担は増えます。

担当者交代・退会・与信停止時の権限停止条件を先に決める

取引先の担当者が交代した場合、旧担当者のアカウントから帳票が見え続ける状態を放置すると、権限設計そのものの意味が薄れます。同様に、取引先が退会した後や与信停止となった後に、一括ダウンロードの権限をいつ・どの条件で止めるかも、要件として先に決めておく必要があります。

自社が保存すべきものは配布したZIPそのものではない

取引先へ渡すZIPの設計を固めた後は、自社側の保存義務を別に整理します。配布用に生成したZIPファイルをそのまま保存する必要はなく、法令が求めているのは交付した帳票の内容が確認できる形の保存です。

交付した適格請求書の写しは、一覧表や明細表の保存でも足りる（インボイスQ&A 問78）

適格請求書発行事業者には、交付した適格請求書の写しの保存義務があります^*3。国税庁のインボイスQ&Aによれば、「交付した適格請求書の写し」は書類そのものの複写に限りません。

複数の適格請求書の記載事項に係る一覧表や明細表の保存があれば足りるとしています^*3。配布用ZIPをそのまま保管する運用は、法令が求める範囲を超えた過剰保存になっている可能性があります。

保存期間は「課税期間の末日の翌日から2月を経過した日から7年間」である（同 問79）

この適格請求書の写しや電磁的記録は、交付日または提供日の属する課税期間の末日の翌日から2月を経過した日から7年間、保存しなければなりません^*3。この年限は消費税法の関連政令に基づく期間であり^*3、取引先への提供期間を設計する際の一つの目安になります。

自社発行データは、編集された状態のデータベース保存でもよい（一問一答 問47）

自社が発行した請求書データについては、その内容が事後的にわかるものであれば差し支えありません^*1。変更されるおそれがなく、合理的な方法により編集された状態で保存されているデータベースでの保存も認められています。帳票発行システムのデータベースをそのまま根拠として使える場合が多く、別途のアーカイブ基盤を新設しなくても要件を満たせる余地があります。

2026年施行の取適法で、発注に関する記録の作成・保存が罰則付き義務になった

製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律（取適法）という法律があります。この法律は委託事業者に対し、給付・受領・代金の支払等について記載・記録した書類または電磁的記録の作成・保存を義務づけています^*4。

この規定に違反して記録を作成せず、または保存せず、あるいは虚偽の記録を作成した場合は、50万円以下の罰金が定められています^*4。この規定は2026年1月1日に施行されており、帳票の保存基盤を見直す事業者にとって無視できない前提条件です。

なお、書類の具体的な保存年数は公正取引委員会規則で定められる項目です。規則の記載を確認できない場合は、年数を断定せず「公正取引委員会規則で定める期間」と扱うのが確実です。個別の税務判断は、所轄税務署または税理士に確認したうえで進める必要があります。

要件定義・RFPに落とし込む4つのチェックリスト

ここまでの論点を、要件定義書やRFP（提案依頼書、ベンダーに提案を求める際の要件文書）に落とし込むための4種のチェックリストに整理します。抽象的な議論のままでは、ベンダーとの認識合わせがぶれやすくなります。

機能要件チェックリスト

対象帳票の種類、指定できる期間の範囲、まとめる粒度、出力形式（PDF・ZIP）、ファイルの命名規則、索引ファイルの有無を、要件定義書の項目として明文化します。

非機能要件チェックリスト

1回あたりの件数上限、同期・非同期の切り分け、生成物の保管期間、URLの有効期限、再ダウンロード回数、取得ログの記録項目が対象です。

法対応チェックリスト

提供期間と保存期間の比較結果、真実性の確保・検索機能の確保をどちらが担保するのか、自社発行データの保存方法、取適法に基づく発注記録の保存要否が対象になります。

ベンダーへの確認質問リスト

確認しておきたい質問は4点あります。「取引先の保存要件をどちらが担保する前提の機能か」「ファイル名規則は変更できるか」の2点。「非同期生成の件数上限は何件か」「権限単位は企業・部署・担当者のどこまで対応できるか」の2点です。

これらは契約前に確定させておく事項です。この確認作業を自社だけで進めることに不安があれば、無料相談で要件を整理する選択肢もあります。

まとめ：一括ダウンロード設計で押さえる3つの判断軸

本稿では、BtoB EC帳票の一括ダウンロードを「取引先の保存義務を成立させるための機能」という前提から設計する手順を整理しました。要点を3つに集約すると次の通りです。第一に、要否そのものが帳票の提供期間ポリシーで決まります^*1。第二に、渡すデータの形（分割規則・命名規則・索引ファイル）が取引先の保存要件を左右します^*1。第三に、大量件数への対応と認可制御という非機能要件を、機能要件より先に固める必要があります^*5。この3つの判断軸を先に決めてから機能の詳細に進むことで、要件定義の手戻りを減らせます。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

帳票をサイト上に置き続ければ、取引先はダウンロードしなくてよいのですか。

サイト上で領収書等データの確認が随時可能な状態であれば、必ずしもダウンロードして保存しなくても差し支えありません^*1。ただしこの取扱いは、ECサイト提供事業者が真実性の確保と検索機能の確保の要件を満たしている場合に限られます^*1。保存期間の満了前に確認できなくなる設計であれば、その前にダウンロードして保存する必要があります^*1。

複数の請求書を1つのPDFにまとめて渡してもよいのですか。

結論は次の通りです^*1。取引ごとにデータの同一性を保持したまま分割し、ファイル名に規則性を持たせて一覧性を持って管理する方法です。この方法は検索要件を満たす一例として示されています。1つのPDFに複数取引を詰め込んだままでは、検索要件を満たしにくくなります。

ZIPのファイル名はどう付ければよいのですか。

取引年月日その他の日付、取引金額、取引先を統一した順序でファイル名に入力する方法が、検索機能の確保の要件を満たす一例として示されています^*1。この順序をZIP生成のロジックにあらかじめ組み込んでおくと、取引先側の検索負担を減らせます。

取引先が年内にダウンロードしなかった場合はどうなりますか。

一問一答は、まとめてダウンロードする場合であっても、当該年分中にダウンロードし、要件に従って保存する必要があると明記しています^*1。年をまたいでからのダウンロードでは保存要件を満たせなくなる可能性があるため、督促の仕組みをUI側に用意しておくことが望ましいです。

自社は配布したZIPをそのまま保存しておく必要がありますか。

配布用のZIPファイルそのものを保存する義務はありません。国税庁のインボイスQ&Aは、交付した適格請求書の写しについて、一覧表や明細表の保存でも足りるとしています^*3。保存期間は、交付日の属する課税期間の末日の翌日から2月を経過した日から7年間です^*3。

1. *1　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】」（令和8年7月）問18・問44・問45・問47・問48・問50・問51・問54・問55
2. *2　出典：e-Gov法令検索「電子計算機を使用して作成する国税関係帳簿書類の保存方法等の特例に関する法律施行規則」第4条第1項
3. *3　出典：国税庁「消費税の仕入税額控除制度における適格請求書等保存方式に関するQ&A」問78・問79・問80
4. *4　出典：e-Gov法令検索「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律」第7条・第14条第3号
5. *5　出典：情報処理推進機構（IPA）「安全なウェブサイトの作り方 1.11 アクセス制御や認可制御の欠落」
6. *6　出典：経済産業省「令和6年度電子商取引に関する市場調査」（令和7年8月公表）