SaaSのインボイス・帳票機能を実装する際の設計ポイント

SaaSプロダクトを開発していると、必ず直面するのが帳票機能の実装です。見積書・請求書・納品書といった書類のPDF出力は、BtoBのSaaSでは事実上必須の機能です。さらに2023年10月に導入されたインボイス制度への対応が加わり、実装の複雑度は増しています。

FUNBREWでは造園業向けSaaS「niwakura」の開発を通じて、帳票機能の設計と実装を経験しました。また、PDF生成に特化したSaaS「FUNBREW PDF」も自社開発しています。この記事では、その経験をもとに帳票機能を実装する際の設計判断のポイントを解説します。

バーティカルSaaS開発全体の流れについては業界特化SaaS開発の完全ガイドもあわせてご覧ください。

インボイス制度とSaaSの帳票機能の関係

適格請求書等保存方式（インボイス制度）の導入により、消費税の仕入税額控除を受けるためには「適格請求書（インボイス）」の保存が必要になりました。これはSaaS開発において、請求書機能に具体的な要件追加を意味します。

インボイス制度への対応が必要なのは、主に以下のケースです。

• SaaSが発行する請求書を、顧客が仕入税額控除に使う場合（SaaS提供者が適格請求書発行事業者の場合）
• SaaSの利用者が自社の顧客に対して帳票を発行する機能を提供する場合（帳票機能自体がSaaSのコア機能）

niwakuraは後者のパターンです。造園会社が顧客へ見積書・請求書を発行する機能を提供しているため、発行する書類がインボイス要件を満たしている必要があります。

帳票機能の設計で決めるべきこと

実装に入る前に、設計として決めておくべき事項があります。後から変更するとデータ構造の大幅な見直しが必要になるため、初期設計の段階で方針を固めることが重要です。

1. テンプレート管理の方針

帳票のレイアウトをどのように管理するかは大きな設計判断です。主な選択肢は3つです。

niwakuraでは固定テンプレート方式を採用しました。造園業界の帳票フォーマットは大きく変わらず、カスタマイズ需要も限定的だったためです。将来的に企業ロゴや社名のカスタマイズは追加予定ですが、レイアウト全体の変更はスコープ外としています。

2. PDF生成のタイミング

PDFをいつ生成するかも設計に影響します。

• オンデマンド生成: ダウンロードボタン押下時にリアルタイム生成。実装が単純で、常に最新の内容が反映される。ただしPDFが大きいと応答が遅くなる
• 非同期生成（ジョブキュー）: 生成をバックグラウンドジョブで行い、完成したらURLを通知。大量の帳票や重い処理に向いている
• キャッシュ保存: 一度生成したPDFをストレージに保存し、変更があれば再生成。ダウンロード頻度が高い場合に有効

niwakuraでは当初オンデマンド生成を採用し、シンプルさを優先しました。パフォーマンス問題が顕在化した場合に非同期化する計画です。

3. 番号採番の設計

見積書番号・請求書番号の採番は、一見シンプルに見えて実は落とし穴が多い部分です。

採番で注意すべき点は以下の通りです。

• 連番の重複防止: 同時リクエストによる採番重複を防ぐために、データベースレベルのロックまたはシーケンスを使用する
• プレフィックス設計: 「INV-2024-0001」のように年度・種別を含めるフォーマットは柔軟性が高い
• テナント分離: マルチテナントSaaSでは企業ごとに連番を管理する（企業Aと企業Bで「001」が被っても問題ない設計）
• 欠番の扱い: 削除・キャンセルによる欠番をどう扱うか（会計的には欠番が残るのが正しい）

PDF生成の技術選択

PDF生成ライブラリ・サービスの選択は、品質・パフォーマンス・コストに大きく影響します。主な選択肢を比較します。

DomPDF（PHP）

PHPアプリケーションで最も手軽に使えるライブラリです。HTMLをPHPで生成してそのままPDF変換できるため、LaravelやSymfonyとの親和性が高いです。

メリットはサーバーサイドのみで完結し、外部依存がない点です。デメリットはCSSの対応が限定的で、複雑なレイアウトやWebフォントの埋め込みが難しい場合があることです。シンプルなレイアウトの帳票であれば十分実用的です。

Puppeteer / Chromium（Node.js / Gotenberg）

ChromeをヘッドレスブラウザとしてHTMLをPDFにレンダリングする方式です。実際のブラウザレンダリングを使うため、CSSの対応範囲が広くデザインの再現度が高いです。

GotenbergはDockerコンテナとして動作するPDF生成マイクロサービスで、PuppeteerをAPIで利用できます。ただしDomPDFに比べてインフラ要件が増え、レスポンスも若干遅くなります。

外部PDF生成API（FUNBREW PDFなど）

PDF生成を外部のAPIサービスに委託する方式です。自前でインフラを管理する必要がなく、テンプレート管理・番号採番・ストレージ保存まで一括して提供するサービスもあります。

FUNBREW PDFは、SaaSプロダクト向けのPDF生成APIです。テンプレートをAPIで登録し、データをPOSTするだけで帳票PDFを生成できます。インフラ管理を省きたいSaaSや、複数の帳票種別を扱うプロダクトに向いています。

niwakuraでの実装：DomPDF採用の判断

niwakuraではDomPDFを採用しました。選定理由は以下の通りです。

• Laravelとの統合が容易: `barryvdh/laravel-dompdf` パッケージで即座に利用でき、Bladeテンプレートをそのまま活用できる
• 帳票デザインがシンプル: 造園業の見積書・請求書は表形式のシンプルなレイアウトで、DomPDFの制約範囲内で十分対応できた
• サーバー構成を増やしたくない: MVPフェーズではインフラを最小限に保ちたかった

テンプレート設計のポイント

DomPDFでのBladeテンプレート作成時に注意したポイントを共有します。

• インラインスタイルを基本とする: DomPDFはCSSファイルの読み込みより、インラインまたは `<style>` タグ内のCSSの方が安定して動作する
• フォントの明示指定: 日本語フォントは明示的に埋め込む必要がある。IPAフォントやNoto Sansなど、ライセンスを確認した上で使用する
• ページ区切りの制御: `page-break-inside: avoid` を適切に設定し、テーブルの行が途中でページをまたがないよう制御する
• 印刷サイズの指定: A4サイズを `@page { size: A4; margin: 15mm; }` で明示する

インボイス制度の技術要件

適格請求書として認められるために、発行する書類に含める必要がある情報をまとめます。

適格請求書の必須記載事項

以下の6項目がすべて含まれている必要があります。

• 適格請求書発行事業者の氏名または名称
• 登録番号（T + 13桁の数字）
• 取引年月日
• 取引内容（軽減税率対象品目は「※」等の明記）
• 税率ごとの合計額および消費税額
• 書類の交付を受ける事業者の氏名または名称

税率区分の管理

現在の消費税率は10%（標準税率）と8%（軽減税率）の2種類です。帳票機能では、明細行ごとに税率を持てるデータ構造が必要です。合計表示では税率ごとに分けた集計を表示しなければなりません。

データベース設計では明細テーブルに `tax_rate` カラムを持たせ、消費税額の計算はアプリケーション層またはビュー生成時に行う方式が一般的です。税額計算の端数処理（切り捨て・四捨五入）も事前に方針を決めておく必要があります。

登録番号の保存と表示

マルチテナントSaaSで各企業が適格請求書を発行する場合、企業ごとの登録番号を設定画面で入力・保存する機能が必要です。登録番号は「T」+13桁の数字であることのバリデーションも実装しておくと安全です。

FUNBREW PDFとの連携可能性

自前でPDF生成機能を実装することに比べ、FUNBREW PDFをAPIとして利用する方式には以下のメリットがあります。

• PDF生成サーバーのインフラ管理が不要
• テンプレートの変更がAPIから行えるため、デプロイ不要で帳票デザインを更新できる
• 生成したPDFのストレージ管理・署名付きURLの発行も含めて提供
• 複数テナント・複数帳票種別を扱うSaaSで管理コストを削減できる

niwakura自体はDomPDFで実装済みですが、将来的に機能追加・デザイン変更の頻度が上がった場合にFUNBREW PDF APIへの移行を検討する予定です。

まとめ

帳票機能は一度リリースすると変更コストが高くなりやすいため、設計段階での判断が重要です。FUNBREWでは業界特化SaaSの帳票機能設計から実装まで対応しています。お気軽にご相談ください。