SaaSの課金実装でつまずく原因の多くは、決済サービスの使い方ではなく「契約の状態」と「お金の流れ」を同じものとして扱ってしまうことにあります。カードによる月額課金だけなら決済サービスの機能でかなりの部分をまかなえますが、法人顧客が増えて請求書払いが混ざった瞬間に、プラン変更、日割り、締め日、入金消込、未払い時の機能制限といった論点が一気に表に出てきます。
結論から言うと、課金システムは「契約（どのプランを、いつから、何アカウント分使えるか）」「請求（いつ、いくらを、どの手段で請求するか）」「入金（実際に支払われたか）」の3層に分けて設計し、カード決済と請求書払いは「請求」の手段の違いとして扱うのが、後から破綻しにくい作り方です。
この記事は、自社SaaSを立ち上げる事業責任者やプロダクトマネージャー、開発会社に課金機能を発注する担当者に向けて、カードの継続課金と請求書払いを併用する際の設計の考え方、プラン変更や日割りの決め方、実装の手順とよくある失敗をまとめたものです。SaaS全体の開発の流れは自社SaaSを開発する手順もあわせてご覧ください。
SaaSの課金実装で最初に決めるべきこと
課金機能の開発に着手する前に、料金体系を「実装できる言葉」に落とし込んでおく必要があります。営業資料に載っている料金表は、そのままでは仕様になりません。たとえば「スタンダードプラン 月額〇円、5ユーザーまで、追加1ユーザーごとに〇円」と書かれていても、月の途中で6人目を追加したらいつから課金するのか、月の途中で4人に減らしたら返金するのか、といった判断が含まれていないからです。
最初に決めておくべき項目は次のとおりです。
- 課金の単位：組織（テナント）単位か、ユーザー単位か、利用量単位か、その組み合わせか
- 請求サイクル：月額のみか、年額も用意するか。年額の場合は前払いか
- 支払い手段：クレジットカードのみか、請求書払い（銀行振込）も受けるか、口座振替を使うか
- 無料期間：トライアルの有無、期間終了時に自動で有料化するか、カード登録を必須にするか
- プラン変更のルール：アップグレードとダウングレードの反映タイミング、日割りの有無
- 解約のルール：即時解約か期間末解約か、データの保持期間
- 未払い時の扱い：督促の回数、機能制限をかけるまでの猶予、強制停止の条件
これらは技術的な判断というより事業上の判断です。開発会社に丸投げすると、開発側が「実装しやすい仕様」で決めてしまい、営業現場や経理の運用と合わないことがあります。料金体系そのものの考え方については継続課金（サブスクリプション決済）の用語解説も参考になります。
カード決済と請求書払いの違いを整理する
カード決済と請求書払いは、同じ「月額料金を受け取る」行為でも、システムとして持つべき情報や処理がかなり違います。違いを表にまとめます。
| 観点 | カードの継続課金 | 請求書払い（銀行振込） |
|---|---|---|
| 主な顧客 | 個人・小規模法人 | 中堅以上の法人、稟議が必要な組織 |
| 課金の実行 | 決済サービスが自動で引き落とし | 自社が請求書を発行し、顧客が振り込む |
| 入金確認 | 決済結果がシステムに通知される | 入金明細と請求を突き合わせる消込作業が必要 |
| 失敗時 | カード期限切れ・残高不足で決済失敗 | 支払い遅延・金額相違・振込名義の不一致 |
| 請求のタイミング | 契約日を起点に自動 | 月末締め翌月末払いなど顧客の支払いサイトに合わせる |
| 必要な書類 | 領収書・利用明細 | 請求書・見積書・場合によって注文書や発注書 |
| 運用負荷 | 低い（失敗時の対応が中心） | 高い（発行・送付・消込・督促） |
カード決済は、決済サービスの継続課金機能を使えば、請求日に自動で引き落とされ、結果がシステムに通知されます。一方の請求書払いは、請求書を作って送り、入金を確認して、支払われていなければ連絡するという人手の作業が発生します。最近は決済サービス側にも請求書発行や銀行振込の受付機能を持つものがあり、Stripeのように請求書払いや振込用の口座番号を発行できるサービスもあります。ただし、国内の商習慣（月末締め・翌月末払い、請求書の書式、適格請求書の記載事項など）にどこまで合わせられるかは、サービスや設定によって異なるため、導入前に必ず確認が必要です。
契約・請求・入金の3層で設計する
併用を前提にするなら、データの持ち方を最初に分けておくことが重要です。おすすめは次の3層です。
契約（サブスクリプション）
「どの組織が、どのプランを、いつから、どの数量で使っているか」を表すデータです。プラン、数量（ユーザー数など）、開始日、次回更新日、状態（トライアル中・有効・支払い遅延・停止・解約予定・解約済み）を持ちます。アプリケーションの機能制限は、原則としてこの契約の状態だけを見て判断します。
請求（インボイス）
「いつの期間分を、いくら、どの手段で請求したか」を表すデータです。請求期間、明細（プラン料金、追加ユーザー、日割り調整など）、税額、合計、支払い手段、請求書番号、発行日、支払期日を持ちます。カード決済でも請求書払いでも、請求データは同じ形で作るのがポイントです。
入金（ペイメント）
「実際にいくら受け取ったか」を表すデータです。カード決済なら決済サービスからの通知で自動的に作られ、請求書払いなら消込作業によって作られます。一部入金や過入金もあり得るので、請求と入金は1対1ではなく、1つの請求に複数の入金が紐づく構造にしておくと安全です。
この3層に分けておくと、「カード決済は決済サービスが請求も入金も担当する」「請求書払いは自社システムが請求を作り、入金は手動または銀行データの取り込みで記録する」という違いを、請求と入金の作り方の違いだけに閉じ込められます。契約の状態判断や機能制限のロジックは共通にできます。
プラン変更と日割りの扱いを決める
SaaSの課金で最も議論が長引くのがプラン変更です。決めるべきことは「いつ反映するか」と「差額をどう精算するか」の2つです。
| 変更の種類 | よくある方針 | 理由 |
|---|---|---|
| アップグレード（上位プランへ） | 即時反映、差額を日割りで請求 | 顧客はすぐ使いたい。売上機会を逃さない |
| ダウングレード（下位プランへ） | 次回更新日に反映、返金なし | 返金処理と期中の機能削減を避ける |
| ユーザー数の追加 | 即時反映、日割り請求または次回請求に加算 | 追加のたびに少額決済が走るのを避けたい場合は加算方式 |
| ユーザー数の削減 | 次回更新日に反映 | 期中の返金を避ける |
| 月額から年額へ | 次回更新日に切り替え、または即時切り替えで残期間を充当 | 会計処理の複雑さで選ぶ |
日割り計算には、日数で割る方法と、秒単位で按分する方法があります。決済サービスの多くは独自の按分ロジックを持っているため、自社の請求書払いでも同じ計算を再現しようとすると、端数処理の違いで金額が合わないことがあります。対策としては、次のいずれかを選びます。
- 請求書払いの顧客は日割りをせず、変更は次回請求から反映するルールにする
- 日割りの計算ロジックを自社側に一本化し、カード決済の請求額も自社で計算して決済サービスに渡す
- 決済サービスの計算結果を正として、請求書払いも決済サービスの請求機能で発行する
規模が小さいうちは1が最も運用しやすく、顧客への説明も簡単です。法人向けSaaSでは「期中にユーザーを追加した分は翌月の請求にまとめて加算」という方式が受け入れられやすい傾向があります。
課金機能の実装手順
カード決済と請求書払いを併用するSaaSの課金機能は、次の順序で進めると手戻りが少なくなります。
- 料金体系の仕様化：前述の項目（課金単位、サイクル、変更・解約・未払いのルール）を1枚の表にまとめ、営業・経理・開発で合意する
- 状態遷移の設計：契約の状態（トライアル・有効・支払い遅延・停止・解約予定・解約済み）と、どのイベントでどの状態に移るかを図にする
- 決済サービスの選定と検証：継続課金、請求書発行、銀行振込の受付、通知（Webhook）の仕様を確認し、テスト環境で一連の流れを試す
- データモデルの設計：契約・請求・入金の3層と、決済サービス側のIDとの対応関係を決める
- カード決済の実装：プラン選択、カード登録、初回決済、継続課金、決済失敗時の通知受け取りと状態更新
- 請求書払いの実装：請求データの作成、請求書PDFの発行、送付、入金の記録（手動入力または銀行データの取り込み）
- 機能制限の実装：契約の状態に応じて、利用できる機能やユーザー数の上限をアプリケーション側で制御する
- 管理画面の実装：契約の手動変更、請求書の再発行、入金の手動消込、返金、特例対応ができる画面
- 通知・督促の実装：決済失敗、支払期日の接近、期日超過のメールと、社内向けのアラート
- テストと移行：日割り、月末日、うるう年、タイムゾーン、二重通知などの境界条件を確認する
決済サービスからの通知は、Webhookで受け取るのが一般的です。通知は遅れて届いたり、同じ内容が二重に届いたり、順序が入れ替わったりすることがあるため、同じ通知を何度処理しても結果が変わらない作り（冪等性）にしておくことが欠かせません。
請求書払いの運用を楽にする工夫
請求書払いは、システムを作っても運用負荷がゼロにはなりません。負荷を減らすための工夫をいくつか挙げます。
- 締め日と発行日を固定する：契約日ごとにばらばらに請求すると、毎日請求書が発生します。全顧客を月末締めにそろえ、月初にまとめて発行すると作業がまとまります
- 振込先を顧客ごとに分ける：顧客ごとに異なる振込用口座番号（バーチャル口座）を割り当てられるサービスを使うと、振込名義が違っても誰の入金か判別しやすくなります
- 消込の候補を自動で出す：銀行の入金明細を取り込み、金額と名義から該当しそうな請求を候補として表示するだけでも、手作業はかなり減ります
- 一部入金・過入金のルールを決める：振込手数料を差し引いて振り込まれるケースなど、差額をどう扱うか（許容するか、次回請求で調整するか）を事前に決めておきます
- 督促の文面と段階を決める：期日翌日、1週間後、2週間後など、段階ごとの文面と担当者を決め、システムから自動送信できるものは自動化します
税制やインボイス制度に関わる請求書の記載事項は、制度の改正もあるため、最新の要件は国税庁などの公的情報や税理士に確認したうえで、請求書の書式を決めてください。
具体的な場面で考える：小規模から法人契約が増えたSaaS
架空の例で考えてみます。ある業務管理SaaSは、当初は小規模事業者向けにカード決済の月額プランだけで提供していました。決済サービスの継続課金機能をそのまま使い、契約の状態も決済サービス側の情報を参照して判断していました。
ところが、従業員数の多い法人から「請求書払いでないと契約できない」「年額で前払いしたい」「部署ごとに請求書を分けてほしい」という要望が届くようになります。最初は経理担当者が表計算ソフトで請求書を作り、入金を確認したら手作業でアカウントを有効化していましたが、契約数が増えると、入金確認の漏れで有効なはずの顧客のアカウントが止まる、逆に未払いの顧客が使い続けている、といった事故が起き始めました。
このケースで行うべき改修は、次のような順序になります。まず、契約の状態を自社のデータベースで持つように変え、決済サービスの情報は「カード決済の顧客の入金情報」として取り込む形にします。次に、請求書払いの顧客にも同じ契約・請求・入金のデータを作り、入金の記録によって契約の状態が更新されるようにします。最後に、部署ごとの請求書分割は「1つの組織に複数の請求先を持てる」構造にして対応します。
最初から3層の設計にしていれば、このような改修は請求書払いの追加だけで済んだはずです。カード決済だけで始める場合でも、契約の状態を自社側に持っておくことは、後の拡張のためにやっておく価値があります。
よくある失敗と避け方、リリース前の確認
決済サービスの状態をそのまま正としてしまう
決済サービスの継続課金の状態を、アプリケーションの利用可否の判断にそのまま使うと、請求書払いや特例対応（無償延長、キャンペーン）を入れたときに対応できません。利用可否は自社の契約データで判断し、決済サービスの状態は入力の1つとして扱います。
通知の二重処理で二重に付与・停止される
Webhookの再送で、同じ決済成功通知を2回処理し、ポイントや利用枠を二重に付与してしまう事故はよくあります。通知のIDを記録し、処理済みのものは無視する仕組みを最初から入れておきます。
日割りの端数で請求額が合わない
決済サービスの計算と自社の計算で1円単位のずれが出ると、経理からの問い合わせ対応に追われます。どちらの計算を正とするかを決め、計算は一か所だけで行います。
解約後のデータの扱いを決めていない
解約した顧客のデータをいつまで保持するか、再契約時に復元できるか、エクスポートを提供するかが決まっていないと、解約時の問い合わせに個別対応することになります。利用規約とあわせて決めておきます。
管理画面を後回しにする
課金の例外対応（返金、無償期間の付与、請求書の再発行）は必ず発生します。管理画面がないと、開発者がデータベースを直接書き換えることになり、ミスや監査上の問題につながります。最小限でも、契約と請求を変更できる画面は用意しておきます。
リリース前のチェックリスト
課金機能は公開後に不具合が見つかると、顧客への説明と返金・再請求の手間が重なります。公開前に次の項目を一つずつ確認してください。
- 料金体系の仕様（課金単位・サイクル・変更・解約・未払い）が文書化され、営業・経理と合意している
- 契約の状態と遷移条件が図になっており、各状態での機能制限が決まっている
- カード決済の初回決済、継続課金、決済失敗、カード更新の流れをテスト環境で確認した
- Webhookの再送・順序入れ替え・二重通知を想定したテストをした
- アップグレード・ダウングレード・ユーザー数増減の請求額を、具体的な日付で計算して確認した
- 月末日・年額更新・トライアル終了日の境界条件を確認した
- 請求書の記載事項を経理・税理士と確認した
- 入金消込の手順と、一部入金・過入金の扱いが決まっている
- 督促メールの文面と送信タイミングが決まっている
- 管理画面で契約変更・請求書再発行・返金ができる
- 解約時のデータ保持とエクスポートの方針が利用規約に反映されている
よくある質問
Q. 最初はカード決済だけで始めても問題ありませんか？
検証段階であれば、カード決済だけで始めるのは合理的です。ただし、契約の状態を自社のデータベースで持つ設計にしておくと、後から請求書払いを追加するときの改修が小さく済みます。法人顧客が主な対象なら、初期から請求書払いの手動運用を想定しておきましょう。
Q. 請求書払いはシステム化せず、手作業で十分ではないですか？
顧客数が少ないうちは手作業でも回ります。目安になるのは、入金確認とアカウント有効化の漏れが起き始めたときや、経理担当者の作業が毎月まとまった時間を占めるようになったときです。まずは請求データと契約状態だけをシステムで持ち、請求書発行と消込は手作業で行う段階を挟むのも有効です。
Q. 年額プランを用意するとき、何に注意すればよいですか？
年額の前払いは、途中解約時の返金ルール、期中のユーザー追加の請求方法、更新案内のタイミングを決めておく必要があります。会計上の売上の計上時期にも関わるため、経理や税理士と相談のうえで決めてください。
Q. 決済サービスはどのように選べばよいですか？
継続課金、請求書発行、銀行振込の受付、日本円での入金、Webhookの仕様、管理画面の使い勝手、手数料体系を比較します。仕様や料金は変わることがあるため、各社の最新の公式情報で確認し、テスト環境で実際の流れを試してから決めるのが確実です。
Otsumuに相談できること
カード決済の月額課金だけで、プランも少なく、決済サービスの標準機能で要件を満たせるのであれば、社内のエンジニアが決済サービスのドキュメントに沿って実装すれば十分に進められます。料金体系がシンプルな初期段階では、外部に頼まずに始めるのも合理的な選択です。
一方で、請求書払いと併用したい、プラン変更や日割りのルールが複雑、決済サービスの状態と自社の契約データがずれて事故が起きている、といった状況では、事業側のルール整理と設計の両方に経験のある外部の力を借りた方が早く安定します。課金は売上と顧客の信頼に直結するため、後から直すコストが大きい領域です。
Otsumuは、自らも事業を手がける立場から、料金体系の整理と課金機能の設計・実装をあわせて支援しています。目的から逆算して必要な機能に絞り、AIを活用した開発で少人数・短期間で形にします。既存SaaSへの請求書払いの追加や課金まわりの作り直しも含め、SaaS開発のページで支援内容を紹介しています。
「今の料金体系でどこまで自動化すべきか」「決済サービスの標準機能で足りるか」といった段階の相談でも構いません。まずは30分の無料相談で状況をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01