著者 Matt Connor
セルフホスト請求書ソフト5製品を比較
1台のVPSで使えるInvoice Ninja、InvoiceShelf、InvoicePlane、Kimai、ERPNextを比較します。定期請求、税、顧客ポータル、決済、ライセンスの違いを確認できます。
どのセルフホスト型請求書ソフトウェアを選ぶべきか
1 台の VPS で現実的に選べるセルフホスト型請求書ソフトウェアは5つありますが、これらは同等の代替製品ではありません。Invoice Ninja は最も完成度が高い製品です。定期請求書、顧客ポータル、決済ゲートウェイ、電子請求書フォーマットが、インストールした時点で利用できます。InvoiceShelf は、より軽量な完全オープンソースの選択肢です。InvoicePlane は、オーケストレーションが不要な単純な PHP アプリケーションです。Kimai は明細項目ではなく、記録した作業時間を請求します。ERPNext は、請求書の発行機能も備えたフル機能の会計システムです。
セルフホスト型の請求書環境で、機能不足よりはるかに頻繁に問題になるのは2つです。1つ目はメールです。スパムフォルダーに入った請求書は未払いの請求書であり、その状態を知らせるものはありません。2つ目はバックアップです。このセルフホスト型データベースを失うと、単なる不便ではなく税務上の問題になります。
機能一覧を読む前に、ライセンスを確認してください。この5つのうち3つはコピーレフト、1つはパーミッシブライセンス、1つは利用方法に実質的な制限があるソースアベイラブルです。
5 つの選択肢と、それぞれに適した用途
Invoice Ninja
現在 v5 系で提供されている Laravel アプリケーションです。セルフホストは無料で、機能制限もありません。定期請求書、見積書、プロジェクト、タイムトラッキング、経費、顧客ポータル、Stripe や PayPal などの決済ゲートウェイを利用できます。プロジェクト自身は「Laravel で構築された、ソースコードを利用可能な請求書、見積書、プロジェクト、タイムトラッキングのアプリケーション」と説明しています。有料なのはブランディングだけです。プロジェクトの説明では、「クライアント向けのアプリケーション部分から Invoice Ninja のブランディングを削除するホワイトラベルライセンスを、年間 $40 で提供しています」とされています。この価格は August 2026 時点のものです。
最も機能が充実した製品を求めており、最大規模のスタックを運用できる場合に適しています。
InvoiceShelf
GNU Affero General Public License version 3 (AGPL-3.0) で提供される Crater のフォークです。請求書、見積書、定期請求、経費、税、複数通貨、顧客ポータル、複数企業に対応しています。決済機能とホワイトラベル機能は、別々の公式モジュールリポジトリで提供されています。どちらも AGPL-3.0 で、無料で利用できます。カード決済には Stripe checkout を使用します。
小規模で完全にオープンソースのアプリケーションを求めており、多数のゲートウェイを必要としない場合に適しています。
InvoicePlane
MIT licence で提供される CodeIgniter ベースの PHP アプリケーションです。この中で唯一、ファイルを Web root に解凍するだけでインストールできます。Docker も Node のビルド手順も必要ありません。PDF の生成には mPDF を使用するため、テンプレートは HTML と CSS で作成します。顧客には、請求書を表示して支払うためのゲストリンクを提供できます。
注意点は決済機能です。ドキュメントには、InvoicePlane 1.6 がデフォルトで対応する決済プロバイダーは Stripe のみであり、このバージョンでは他のプロバイダーが削除されたと明記されています。1.6 系の公開要件は、PHP 8.0 から 8.1 と、MySQL 5.5 または対応する MariaDB です。1.7 系は現在も開発が進んでいるため、ダウンロードするリリースの注意事項を確認してください。
共有ホスティングまたは 512 MB の VPS を使用している場合に適しています。
Kimai
タイムシートから請求書を生成できる AGPL-3.0 のタイムトラッカーです。作業時間に基づいて請求する場合に適しています。請求書テンプレートは DOCX、ODS、XLSX ファイルとしてアップロードします。ドキュメントで確認されている受け付け可能な形式はこの 3 つだけで、PDF または HTML にレンダリングされます。CSS を記述する代わりに、ワードプロセッサーで請求書のレイアウトを作成できます。多くの利用者にとって、この方法のほうが簡単です。
Kimai には顧客ポータルも決済ゲートウェイもないため、PDF をメールで送信します。構造化電子請求には、E-Invoice Plus という有料のストアプラグインがあります。セルフホスト環境では、August 2026 時点で VAT を除き年間 99 EUR と記載されています。EN16931、XRechnung、ZUGFeRD、Factur-X、Peppol のプロファイルに対応します。
請求書がタイムトラッキングの結果として生成される場合に適しています。
ERPNext
GPL-3.0 で提供されますが、ソフトウェアのカテゴリが異なります。販売請求書は、勘定科目表、仕訳、在庫、給与計算を備えた完全な会計システム内の 1 種類のドキュメントです。請求業務だけでは足りなくなった場合に適しています。顧客が 8 社いる 1 人のフリーランサーには、機能が多すぎます。導入自体が 1 つのプロジェクトになり、その手順は VPS で ERPNext を運用する で説明しています。
定期請求書は、見えないスケジューラーに依存します
Invoice Ninja、InvoiceShelf、InvoicePlane、ERPNext は、いずれも定期請求書を生成します。Kimai のコアには定期請求書機能がありません。Kimai では、期間内のタイムシートエントリから請求書を作成するためです。
Laravel ベースのアプリでは、どれも同じ静かな失敗が起きます。定期請求書はスケジュールタスク php artisan schedule:run によって作成されます。このタスクは、アプリケーションの外部にある何らかの仕組みが毎分呼び出す必要があります。何も呼び出さなければ、定期請求書の一覧には次回送信日が表示されたまま、その日付だけが過ぎていきます。請求書は作成されません。コードが実行されていないため、エラーも記録されません。
そのため、最初の定期請求書を作成したら、次回送信日を数分後に設定して待ちます。何も届かなければ、スケジューラーが実行されていません。Docker インストールでは通常、compose file 内の cron または scheduler service が起動していないか、終了しています。
docker compose ps
docker compose logs --tail 50ファイル内のすべての service は running を報告する必要があります。exited 状態のままの service があれば、そのログを確認します。
複数通貨と税務: 導入を決定する前に確認すること
機能一覧にある「複数通貨」は、製品によって意味が大きく異なります。デモ環境で次の4項目を確認してください。自社の実際の数値を使うことが重要です。ここでの誤りは、自分ではなく税理士に発見されるためです。
- 請求書には、発行日に適用された為替レートが保存されますか。保存されている必要があります。アプリケーションが現在の為替レートから合計額を再計算すると、前四半期のレポートを開くたびに内容が変わります。すでに申告した帳簿とも一致しなくなります。
- 税は明細行ごと、請求書ごと、またはその両方に適用されますか。請求書単位の税率だけでも、ある明細が非課税になるまでは問題ありません。
- 税込み価格と税抜き価格の両方を入力できますか。後から変換すると、明細ごとに1セントの丸め差が生じることがあります。その差は1年分で積み上がります。
- VATの支払い義務がない別の国の顧客について、書類には何が表示されますか。税額欄の0だけでなく、免税理由の注記を請求書に印刷する必要があります。
Invoice NinjaとERPNextは、4項目すべてに対応しています。InvoiceShelfの機能一覧には、税と複数通貨が含まれています。InvoicePlaneとKimaiはより単純なため、最も簡単な請求書ではなく、最も処理が難しい請求書でテストしてください。
クライアントポータルと決済ゲートウェイ
クライアントポータルは、クライアントが請求書を確認し、PDF をダウンロードして支払うページです。請求書の作成よりも、メールで支払いを催促するほうが時間がかかるため、見た目以上に重要です。
この用途では Invoice Ninja が最も充実しています。完全なポータル、多数のゲートウェイ、保存済みの決済方法、定期請求書の自動請求に対応しています。InvoiceShelf には顧客ポータルがあり、決済モジュールを通じて Stripe checkout も利用できます。InvoicePlane は各請求書にゲストリンクを付けられ、Stripe に対応しています。Kimai にはどちらもないため、PDF を添付ファイルとして送信します。
常に混同される点があります。請求アプリケーションをセルフホストしても、カード番号を保持することにはなりません。Stripe checkout ではクライアントが Stripe にリダイレクトされ、そこでカード番号を入力します。VPS がカード番号を受け取ることはありません。決済フォームを自作しないため、PCI（Payment Card Industry）対応の対象範囲も小さく抑えられます。後から複数の決済処理事業者が必要になった場合や、国別に決済先を振り分けたい場合は、Hyperswitch を使ったセルフホスト型の決済オーケストレーション のような別のレイヤーで対応します。
PDF の品質と、最終的に編集するテンプレート
テンプレートを編集します。ここにあるデフォルト設定をそのまま使うと、どの設定でも住所が居住国に合わない位置に配置されます。
Invoice Ninja は、イメージに同梱されたヘッドレス Chromium を使用して HTML と CSS のテンプレートを PDF に変換します。そのため、コンテナのサイズが大きくなります。メモリに余裕を持たせてください。ヘッドレスブラウザーはこの構成で最も負荷の大きいプロセスなので、1 GB の VPS では厳しい構成です。InvoicePlane は mPDF を使用します。純粋な PHP 実装で軽量ですが、一部の最新 CSS は無視されます。Kimai は逆の方式を採用しており、DOCX または ODS ファイルをアップロードします。そのため、レイアウトはスタイルシートを書いたことのない担当者が LibreOffice または Word で作成することになります。
デザイン済みの請求書を重視し、CSS を重視しない場合は、Kimai の方式が適しています。テンプレートをバージョン管理し、差分を確認できる状態にしたい場合は、HTML が適しています。
商用利用はライセンスで認められていますか？
5つすべてで、自分の顧客に請求できます。違いが生じるのは、それ以外のことを行う場合です。
Invoice Ninja は Elastic License 2.0 の下で提供されています。重要なのは2つの条項です。
ソフトウェアの機能または性能の大部分にユーザーがアクセスできるサービスを提供する、ホスト型またはマネージドサービスとして、ソフトウェアを第三者に提供してはなりません。
ソフトウェアのライセンスキー機能を移動、変更、無効化、または回避してはなりません。
そのため、自社の業務で運用することは問題ありません。一方、顧客向けの製品としてインスタンスを運用することは認められません。ブランディングの削除に、ソースコードへのパッチではなく $40 のライセンスが必要なのは、2つ目の条項が理由です。
InvoiceShelf、Kimai、Crater は AGPL-3.0 です。商用利用は無料で、上位の料金プランもありません。義務は section 13 に定められています。コードを変更し、ネットワーク経由で他者に変更版を使わせる場合、変更内容のソースコードを提供する必要があります。変更していないインスタンスは、upstream の公開ソースですでに対象となるため、多くの self-hosting ユーザーがこの対応を行うことはありません。
InvoicePlane は MIT で、このグループでは最も制約が少ないライセンスです。ただし、README には名前とロゴはプロジェクトに帰属すると記載されています。
ERPNext は GPL-3.0 です。配布する変更版は共有する必要がありますが、非公開で運用する場合に義務はありません。
これはライセンス本文の説明であり、法的助言ではありません。
プロジェクトは現在も保守されていますか？コミット履歴を確認する
Crater は数年間にわたって広く利用されたオープンソースの請求書発行アプリケーションで、現在も多くのガイドで推奨されています。ただし、デフォルトブランチには 741 日間コミットがありません。
The data behind this chart
[
{
"label": "ERPNext",
"commit_gap": 0
},
{
"label": "Invoice Ninja",
"commit_gap": 1
},
{
"label": "Kimai",
"commit_gap": 1
},
{
"label": "InvoicePlane",
"commit_gap": 3
},
{
"label": "InvoiceShelf",
"commit_gap": 4
},
{
"label": "Crater",
"commit_gap": 741
}
]そのブロックに含まれる 6 件のプロジェクトのうち、過去 1 週間以内にコミットがあったのは 5 件でした。InvoiceShelf は Crater の開発を引き継いだフォークです。同じ AGPL-3.0 ライセンスと同じデータモデルを使用しているため、移行は書き直しではなくデータ移行で済みます。Crater ではなく InvoiceShelf をインストールしてください。
VPS にそれぞれをインストールする
InvoicePlane 以外は、Docker Compose で実行するのが最も簡単です。Docker Compose が初めての場合は、まず VPS で最初の Docker Compose スタックを構築する を読んでから、ここに戻ってください。
Invoice Ninja には専用の compose リポジトリがあります。
git clone https://github.com/invoiceninja/dockerfiles.git
cd dockerfiles
docker run --rm -it invoiceninja/invoiceninja php artisan key:generate --showこのキーをリポジトリ内の env ファイルに、実際の APP_URL とともにコピーします。次に、イメージが想定する所有者を設定して起動します。
chmod 755 docker/app/public
sudo chown -R 1500:1500 docker/app
docker compose up -d1500:1500 の所有者設定は、イメージ内のユーザーと一致します。この設定を省略すると、アプリケーションはキャッシュや生成した PDF を書き込めません。セットアップウィザードでは、データベースホストに db を指定します。これは compose ネットワーク上のサービス名です。localhost は、アプリケーションコンテナ自体を指します。
InvoiceShelf は、データベースエンジンごとに用意された compose ファイルを公開しています。
curl -fLO https://raw.githubusercontent.com/InvoiceShelf/docker/master/docker-compose.mysql.yml
mv docker-compose.mysql.yml docker-compose.yml起動する前に、そのファイルを開いて確認します。ファイル内のパスワードはすべてプレースホルダーであり、そのことがコメントにも記載されています。APP_URL、SESSION_DOMAIN、SANCTUM_STATEFUL_DOMAINS はすべてデフォルトで localhost になっています。初回ログインの前に、3 つすべてへ実際のホスト名を設定する必要があります。その後、起動します。
docker compose up -dホストのポート 8090 を公開し、コンテナ内では 8080 で待ち受けます。クライアントからの接続を 1 件でも受け付ける前に、TLS（transport layer security）対応のリバースプロキシを前段に置いてください。
プロジェクトのドキュメントにある Kimai の本番用 compose ファイル
services:
sqldb:
image: mysql:8.3
volumes:
- mysql:/var/lib/mysql
environment:
- MYSQL_DATABASE=kimai
- MYSQL_USER=kimaiuser
- MYSQL_PASSWORD=kimaipassword
- MYSQL_ROOT_PASSWORD=changemeplease
command: --default-storage-engine innodb
restart: unless-stopped
healthcheck:
test: mysqladmin -uroot -p$$MYSQL_ROOT_PASSWORD ping -h 127.0.0.1 --silent
interval: 10s
timeout: 5s
retries: 12
start_period: 30s
kimai:
image: kimai/kimai2:stable
depends_on:
sqldb:
condition: service_healthy
restart: true
volumes:
- data:/opt/kimai/var/data
- plugins:/opt/kimai/var/plugins
ports:
- 8001:8001
environment:
- APP_SECRET=your-fantastic-long-random-and-ultra-secure-secret
- TRUSTED_HOSTS=kimai.example.com
- ADMINMAIL=admin@example.com
- ADMINPASS=changemeplease
- DATABASE_URL=mysql://kimaiuser:kimaipassword@sqldb/kimai?charset=utf8mb4&serverVersion=8.3.0
restart: unless-stopped
volumes:
data:
mysql:
plugins:APP_SECRET には自分で生成した長いランダム文字列を、TRUSTED_HOSTS には実際に使用するドメインを設定します。ADMINMAIL と ADMINPASS は、初回起動時に最初の管理者アカウントを作成します。そのため、起動後にインターフェースでパスワードを変更し、ファイルからその設定を削除してください。
InvoicePlane にはコンテナがありません。まず空のデータベースを作成します。
sudo mysql -e "CREATE DATABASE invoiceplane CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"プロジェクトのリリースページからアーカイブをダウンロードし、Web ルートに展開します。ipconfig.php.example を ipconfig.php にコピーし、そのファイルのコメントに従って URL を設定します。次に https://your-domain.example/index.php/setup を開き、インストーラーの手順に従います。
請求書が迷惑メールフォルダーに入る理由
これは金銭的な損失につながる失敗ですが、アプリケーションは請求書を送信済みとして処理します。
VPS 自身の IP アドレスから請求書メールを送信しないでください。新しい VPS の IP アドレスには送信履歴がありません。大手メール受信サービスは、ホスティング事業者の IP レンジに属する未知のアドレスから初めて届いたメッセージを、既定で不審なものとして扱います。認証済みのドメイン上にある SMTP（simple mail transfer protocol）リレーを経由して送信してください。これを最初から最後まで構築する方法は独立したガイドであり、自己ホスト型アプリからメールを確実に送信する方法でリレー、DNS レコード、テストについて説明しています。
請求書を送る構成で最も問題になりやすいのは From アドレスです。From アドレスは、自分が管理するドメイン上に置く必要があります。また、リレーが DKIM（domainkeys identified mail）で署名するドメインでなければなりません。From にクライアント自身のアドレスを設定すると親切に見えますが、配送に失敗します。受信サーバーは、From のドメインとメッセージの認証に使用されたドメインが一致するかを確認するためです。Gmail はこの不一致を明確に拒否します。
550 5.7.1 Unauthenticated email from example.com is not accepted due to domain's DMARC policyFrom には自分のアドレスを設定し、クライアントのアドレスは Reply-To に設定してください。実際のメールを送信する前に、公開済みのレコードを確認します。
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector1._domainkey.example.com1 つ目のコマンドは、リレーを指定する SPF（sender policy framework）レコードを返す必要があります。2 つ目のコマンドは、DMARC（domain-based message authentication, reporting and conformance）ポリシーを返す必要があります。3 つ目の結果は、リレーから指定された selector に依存します。空の結果になる場合は、DKIM レコードが存在しないか、誤った名前で公開されています。そのため、送信するすべてのメッセージが署名検証に失敗します。
次に、大手プロバイダーの自分のアカウントへ実際の請求書を送信し、raw headers を確認します。Authentication-Results ヘッダー内の dkim=pass と spf=pass だけが、確認材料になります。アプリケーション側の「送信済み」フラグは、メッセージをリレーへ渡したことだけを示します。
失うことができない唯一のデータベース：バックアップ
メディアサーバーを失っても、ファイルを再ダウンロードすれば済みます。請求データベースを失うと、請求した金額、入金済みの金額、未払いの金額を確認できなくなります。それに応じて扱ってください。
4 つをバックアップします。データベース。ロゴ、生成した PDF、経費の領収書を保持するストレージボリューム。アプリケーションの環境ファイル。そして、通常のファイルとして保存している生成済み PDF です。PDF は、それを生成したアプリケーションがなくても 10 年後に開けるためです。
環境ファイルは、予想以上に重要です。Laravel は、このファイルにある APP_KEY を使用して、支払いゲートウェイの認証情報など、保存された機密情報を暗号化します。データベースを復元する際に新しく生成した key を使うと、それらの値を復号できません。請求書はすべて存在していても、ゲートウェイの設定は読み取れなくなります。
InvoiceShelf stack からの dump は次のようになります。データベースサービスは mariadb:10 で実行されるため、コンテナ内のツールは mariadb-dump です。
docker compose exec -T database mariadb-dump \
--user=root --password=YOUR_ROOT_PASSWORD \
--single-transaction --databases invoiceshelf > invoiceshelf.sql--single-transaction は InnoDB テーブルをロックせずに一貫性のある snapshot を取得するため、dump の実行中もアプリケーションはサービスを提供できます。-T は Docker に端末を割り当てないようにします。端末を割り当てると、リダイレクトした出力が壊れ、import できない dump file が生成される可能性があります。
暗号化した restic によるオフサイトストレージへのバックアップを使用し、スケジュールに従ってサーバー外へ送信します。保持期間は、会計担当者が指定する期間を十分にカバーできる長さに設定してください。
その後、復元します。使い捨てのコンテナで dump を起動し、ログインして先月の請求書を開きます。これを一度実行するまでは、バックアップが機能するかどうかは分かりません。
税理士から求められるもの
チュートリアルを根拠に税務上の判断をしないでください。以下は、このソフトウェアで生成できるものです。リストを担当者に見せて確認してもらってください。
エクスポート可能なデータ。 データベースクライアントを使ったり、サポートチケットを起票したりせず、インターフェースから請求書と支払いを CSV にエクスポートできる必要があります。SQL ダンプはバックアップであり、エクスポートではありません。税理士が開けないためです。
変更できない採番。 請求書番号は連番にし、欠番なしで再利用しないようにします。請求書を削除すると欠番が生じ、その理由を説明しなければなりません。削除する代わりに、キャンセルまたはクレジット処理を行ってください。ここで扱うすべてのアプリケーションが対応しています。欠番のない採番が必要かどうかは、登録地域によって異なります。早めに確認しておくとよいでしょう。
保存期間。 データベースダンプと生成済み PDF は、規則で定められた期間だけ保存してください。PDF は実際に送付した書類であり、請求書が争われた場合に重要になる証跡です。
変更履歴。 誰がいつ請求書を編集したかを示せる機能は有用です。この点は、これらのアプリケーション間で最も差が出ます。Invoice Ninja は、レコードごとのアクティビティログを保持します。
構造化された電子請求書は、EU の一部地域で、あると便利な追加機能ではなく実際の要件になっています。Invoice Ninja は一般的な形式を生成でき、ZUGFeRD、XRechnung、Facturae、FatturaPA、汎用の EN16931 に対応しています。自己ホスト型インスタンスから Peppol ネットワーク経由で配信する場合は、Invoice Ninja 独自のアクセスポイントを経由します。Invoice Ninja に組織を登録し、送信ごとにクレジットを購入する必要があるため、2026 年 8 月時点では有料サービスです。Kimai も有料プラグインによって同じ形式に対応します。他の 3 つは現在、構造化された電子請求書をまったく生成できません。そのため、EU 内で請求書を発行する場合は Invoice Ninja を選ぶ最大の理由になります。
FAQ
Crater と InvoiceShelf のどちらをインストールすべきですか？
InvoiceShelf です。2026 年 8 月 21 日時点で、Crater のデフォルトブランチには 741 日間コミットがなく、公式の issue tracker でも fork の利用を案内しています。InvoiceShelf は同じ AGPL-3.0 ライセンスと同じデータモデルを使用しているため、両者の移行は書き直しではなくデータベース移行で済みます。現在も Crater を推奨しているガイドは、プロジェクトの更新が止まる前に書かれたものです。
Invoice Ninja を自分の事業で無償利用できますか？
はい。Self-hosted Invoice Ninja は Elastic License 2.0 の下で、定期請求、クライアントポータル、決済ゲートウェイを含め、無償で完全に利用できます。有料になる点は2つあります。クライアント向けページから Invoice Ninja のブランド表示を削除するには white-label ライセンスが必要で、2026 年 8 月時点のプロジェクトの説明では「"$40 per year"」です。Peppol ネットワーク経由の電子請求書送信は別途従量課金です。ライセンスで禁止されているのは、他者向けのホスティングサービスとしてソフトウェアを運用することです。
請求書メールが迷惑メールフォルダーに入るのはなぜですか？
ほとんどの場合、From に指定したドメインに対してメールが認証されていないことが原因です。VPS 自体から送信せず、SMTP relay 経由で送信してください。そのうえで、ドメインの SPF と DMARC レコードを公開し、relay から指定された selector 配下に DKIM レコードを追加します。From には自分のアドレスを使用し、クライアントのアドレスは Reply-To に指定してください。クライアントのアドレスを送信者にすると、Gmail は 550 5.7.1 Unauthenticated email from example.com is not accepted due to domain's DMARC policy でメッセージを拒否します。テストメッセージの Authentication-Results ヘッダーで dkim=pass と spf=pass を確認し、修正できたことを確認してください。
時間単位で請求する場合はどれを選ぶべきですか？
Kimai です。Kimai はまず time tracker であり、承認済みの timesheet エントリから請求書を生成します。明細には記録した作業が反映されます。テンプレートは DOCX、ODS、XLSX ファイルで、word processor で作成できます。CSS を編集するより簡単です。ただし、Kimai にはクライアントポータルと決済ゲートウェイがありません。そのため、PDF をメールで送信し、銀行振込などで支払いを受けます。Invoice Ninja も時間を記録でき、ポータルも備えています。timesheet の詳細よりオンラインのカード決済を重視するなら、Invoice Ninja を選んでください。
具体的に何をバックアップする必要がありますか？
データベース、ロゴと生成済み PDF を格納するストレージボリューム、環境ファイル、プレーンファイルとして保存しているレンダリング済み PDF をバックアップしてください。環境ファイルは見落とされやすい項目です。Invoice Ninja や InvoiceShelf などの Laravel アプリケーションは、保存された認証情報を APP_KEY で暗号化します。そのため、新しく生成したキーと一緒にデータベースを復元すると、決済ゲートウェイの設定を読み取れなくなります。復元したデータ一式を使い捨てのインスタンスに一度展開し、古い請求書を開いてください。バックアップが機能することを確認する唯一の方法です。