請求書の発行・受領を自動化する設計。インボイス制度と電子帳簿保存法に合わせて、業務システムの項目・保存・検索を組む

この記事の結論：請求書の発行と受領を業務システムで自動化するときは、インボイス制度と電子帳簿保存法の要件を「画面」ではなく「データの項目と保存のしかた」として先に決めます。発行側では、適格請求書の6つの記載事項を項目として持ち、消費税額の端数処理は1枚の請求書につき税率ごとに1回にします。発行した請求書は確定した後に書き換えられない形で残し、相手に渡した形式で7年間出力できるようにします。受領側では、電子で受け取った請求書をデータのまま保存し、改ざんを防ぐ措置（訂正削除の記録が残る仕組みか、事務処理規程）と、取引年月日・取引金額・取引先で探せる検索の仕組みを用意します。

この記事は、請求書の作成を表計算や手作業から業務システムに移したい会社の担当者と、そのシステムを作る開発者に向けて、設計の段階で決めておく項目を並べたものです。要件の説明は、国税庁が公開しているQ&Aやパンフレットに基づくもので（閲覧日は記事末に記載）、税務の判断を代わりにするものではありません。自社にどう当てはまるかは、顧問の税理士とすり合わせてください。取引先や利用企業の事例は載せていません。

請求書の自動化は「発行」と「受領」を分けて設計する

請求書の自動化は、自社が出す請求書（発行）と、取引先から届く請求書（受領）で、守る要件もデータの流れも違います。最初に2つを分けて、それぞれの流れを決めます。

発行と受領で同じ保存の仕組みを使うことはできますが、項目の持ち方や確定のタイミングは別に決めます。

発行側は、インボイスの記載事項をそのままデータの項目にする

発行する請求書を適格請求書（インボイス）にするには、国税庁が示す記載事項をすべて満たす必要があります。業務システムでは、これを請求書の項目として持たせ、どこから値を取るかを決めます。

ここで「写す」と書いたのは、発行した時点の値を請求書の側に固定するためです。取引先の名称や自社の住所が後で変わっても、過去の請求書の中身は変わってはいけません。マスタを参照するだけの作りにすると、マスタを直した瞬間に過去の請求書の表示まで変わってしまいます。

消費税額の端数処理は、1枚につき税率ごとに1回

国税庁のQ&Aでは、適格請求書に記載する消費税額等に1円未満の端数が出るときは、1つの適格請求書につき税率ごとに1回の端数処理を行う必要がある、とされています。商品ごとに消費税額を計算して端数を処理し、その合計を記載することは認められません。切上げ・切捨て・四捨五入のどれにするかは任意です。

実装では、明細ごとに税額を丸めないことが大事です。税込の金額で集計する場合の例を示します。

type Line = { amountInclTax: number; rate: 10 | 8 }; // 明細の税込金額（円）

// 1枚の請求書につき、税率ごとに1回だけ端数処理する
function taxByRate(lines: Line[]) {
  const totals = new Map<number, number>();
  for (const l of lines) totals.set(l.rate, (totals.get(l.rate) ?? 0) + l.amountInclTax);

  return [...totals].map(([rate, total]) => ({
    rate,
    total,
    // 端数処理の方法（ここでは切捨て）は会社で決めて固定する
    tax: Math.floor((total * rate) / (100 + rate)),
  }));
}

端数処理の方法は、会社として1つに決め、設定として持たせます。請求書ごとに方法が変わると、取引先の側で計算が合わない原因になります。

発行した請求書は、確定した後は書き換えられない形で7年残す

発行した請求書の写し（控え）は、交付した日の属する課税期間の末日の翌日から2か月を過ぎた日から7年間の保存が必要です。業務システムでは、発行を「確定」した時点で中身を固定し、それ以降は書き換えられない作りにします。

国税庁の電子帳簿保存法の一問一答では、発行した請求書データの内容が変更されるおそれがなく、合理的な方法で編集された状態で保存されたデータベースであれば、データベースでの保存も認められるとしています。インボイスのQ&Aでも、PDFの元になったデータを保存することで差し支えない場合が示されています。ただし、相手に渡した形式で整然と出力できるようにしておく必要があります。

設計としては、次の3つを守ると要件に沿わせやすくなります。

1. 請求書に「下書き」と「確定」の状態を持たせ、確定した請求書は更新も削除もできないようにする
2. 間違いを直すときは、元の請求書を残したまま、取り消しや訂正の請求書を新しく発行する
3. 確定した時点のPDFも合わせて保存し、データとPDFのどちらからでも同じ内容を出せるようにする

紙で印刷して渡す場合でも、自社のシステムで一貫して作った請求書であれば、その控えをデータで保存できます。このときは、システムの概要書や操作説明書の備え付けに加えて、日付の範囲を指定して探せる仕組みか、税務調査で求められたときに提示・提出できる状態のどちらかが求められます。

受領側は、電子で届いた請求書をデータのまま保存する

取引先からメールのPDFやサイトのダウンロードで受け取った請求書は、電子取引のデータとして、データのまま保存しなければなりません。令和6年1月からは、印刷して保存し、元のデータを消す運用はできなくなっています。

国税庁が示す電子取引データの保存の要件は、大きく分けて「真実性」と「可視性」の2つです。

「自社開発のプログラムを使う場合はシステムの概要書」という要件は、業務システムを作って請求書を受け取る仕組みに載せるときに見落としやすい所です。システムを作る側は、納品物にこの概要書を含めておきます。

受け取り口は1か所にまとめます。担当者ごとのメールの受信箱に請求書が散らばると、保存漏れも、二重の支払いも起きやすくなります。請求書を受け付ける専用のアドレスを作り、そこに届いたものを取り込む流れにすると、取り込みの自動化も1か所で済みます。

検索の要件は、3つの項目と範囲指定と組み合わせで作る

電子取引データの検索機能は、取引年月日（その他の日付）・取引金額・取引先の3つで探せること、日付と金額は範囲を指定して探せること、2つ以上の項目を組み合わせて探せること、の3点が要件です。

国税庁の一問一答には、実装に関わる細かい扱いも書かれています。

• 組み合わせは「AかつB」で探せればよく、「AまたはB」は求められていない。いったん1つの項目で探し、その結果をさらに別の項目で絞り込む方式でもよい
• 取引金額は、帳簿の経理処理（税抜・税込）に合わせるのが基本だが、受け取ったデータに書かれた金額を項目にしてもよい
• 税務職員からのダウンロードの求めに応じられるようにしていれば、範囲指定と組み合わせの要件は不要になる。さらに基準期間の売上高が5,000万円以下なら、検索の要件はすべて不要になる

業務システムで作るなら、受け取った請求書のファイルとは別に、検索用の項目を持つ表を用意します。

-- 受領した請求書の検索用の表（ファイル本体は別の保管場所に置き、場所だけを持つ）
CREATE TABLE received_invoices (
  id            BIGSERIAL PRIMARY KEY,
  transaction_date DATE        NOT NULL,  -- 取引年月日
  amount        INTEGER       NOT NULL,   -- 取引金額（税込か税抜かは会社で統一）
  counterparty  TEXT          NOT NULL,   -- 取引先
  file_key      TEXT          NOT NULL,   -- 保管場所でのファイルの場所
  received_at   TIMESTAMPTZ   NOT NULL DEFAULT now()
);
CREATE INDEX ON received_invoices (transaction_date, counterparty);

-- 日付の範囲と取引先を組み合わせて探す
SELECT * FROM received_invoices
WHERE transaction_date BETWEEN '2026-04-01' AND '2026-09-30'
  AND counterparty = '取引先名';

項目の読み取りを自動化する場合も、取引年月日・金額・取引先の3つは、保存する前に人が確かめる手順を入れておきます。読み取りの誤りがそのまま検索の誤りになるからです。

改ざんを防ぐ措置は、訂正削除の記録が残る作りにする

改ざんを防ぐ措置は、タイムスタンプが付いたデータを受け取る、受け取った後、決められた期限のうちにタイムスタンプを付ける、訂正や削除の記録が残る（または訂正削除ができない）システムで受け取って保存する、訂正削除を防ぐ事務処理規程を定めて守る、の4つのいずれかです。自社で業務システムを作るなら、訂正削除の記録が残る作りにするのが、運用の負担と相性のよい選び方です。

訂正削除の記録を残す作りでは、元の行を書き換えずに、変更の内容を別の表に追記していきます。

-- 変更の履歴は追記だけにし、更新と削除の権限はアプリの利用者に与えない
CREATE TABLE received_invoice_changes (
  id           BIGSERIAL PRIMARY KEY,
  invoice_id   BIGINT      NOT NULL REFERENCES received_invoices(id),
  changed_by   TEXT        NOT NULL,
  changed_at   TIMESTAMPTZ NOT NULL DEFAULT now(),
  field        TEXT        NOT NULL,   -- 変えた項目
  before_value TEXT,
  after_value  TEXT,
  reason       TEXT        NOT NULL    -- 訂正・削除の理由
);

削除の操作も、行を消すのではなく「取り消し」の印と理由を記録する形にします。保存したファイル本体は、上書きと削除ができない設定の保管場所に置くと、アプリの不具合で消えることも防げます。保存期間のあいだ確実に読み出せるかは、バックアップから戻せるかどうかで決まるので、保存したデータを実際に戻して確かめる練習もあわせて見ておくと安心です。

取引先とデータでやり取りするなら、Peppol（JP PINT）も候補にする

請求書をPDFではなく、決まった形式のデータで送り合えば、受け取った側で読み取る作業そのものがなくなります。日本では、デジタル庁が国際的な電子インボイスの仕組みであるPeppolをもとにした標準仕様「JP PINT」を管理しています。

すべての取引先が対応しているわけではないので、最初からPeppolだけに寄せる必要はありません。発行側のデータを記載事項ごとの項目で持っておけば、後からPeppolの形式で出力する機能を足すときも、項目を対応させるだけで済みます。

組む順番は、項目→確定→保存→検索→受け取り口

最後に、設計から運用までの順番をまとめます。

1. 発行する請求書の項目を、インボイスの記載事項に合わせて決める（端数処理の方法も）
2. 「下書き」と「確定」の状態を作り、確定後は書き換えられないようにする
3. 発行した請求書と受け取った請求書の保存先、保存期間、改ざんを防ぐ措置を決める
4. 受け取った請求書の検索用の項目（取引年月日・取引金額・取引先）を決める
5. 受け取り口を1か所にまとめ、取り込みと確認の手順を決める
6. システムの概要書と操作説明書を作り、保存した場所で画面表示と印刷ができることを確かめる

法令の要件が関わる処理は、あとから画面を直すより、最初の項目の決め方で手戻りの大きさが決まります。最初の整理から外に任せたい場合、株式会社bundlyzeでは業務システムの要件定義から開発、保守運用までを一続きで受け持っており、受注や売上のデータから請求書を起こす仕組みも、項目と保存のしかたから組み立てられます。進め方や相談の窓口は、業務システム開発にまとめています。

根拠にした国税庁とデジタル庁の公表物（2026年10月3日閲覧）

• 国税庁「適格請求書（インボイス）の記載事項について」：適格請求書の記載事項、交付した写しの保存
• 国税庁「消費税の仕入税額控除制度における適格請求書等保存方式に関するＱ＆Ａ」問57：消費税額等の端数処理は1つの適格請求書につき税率ごとに1回
• 同Ｑ＆Ａ 問79：交付した写しの保存期間（7年間）
• 同Ｑ＆Ａ 問80：自社のシステムで作った請求書の控えをデータで保存する場合の要件
• 同Ｑ＆Ａ 問83：提供したPDFの元になったデータでの保存
• 国税庁「電子帳簿保存法一問一答【電子取引関係】」（令和6年6月）：保存の要件の一覧、問16（ファイル名と索引簿）、問41（発行した請求書データのデータベースでの保存）、問42・43（検索機能）、問51（取引金額の税抜・税込）
• 国税庁「令和６年１月からの電子取引データの保存方法」：可視性と真実性、売上高5,000万円以下の扱い、電子取引データが原本であること
• デジタル庁「JP PINT」：Peppol をもとにした日本の標準仕様 JP PINT