LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・保守を受託

サブスク・定期課金管理システムを新規に開発したい、あるいは表計算や既存の請求ツールで回してきた仕組みを刷新したい——SaaSやサブスク型サービスを手がける事業者の多くが、事業拡大の途中でこの検討に行き着きます。契約数が増えるほど、プラン変更や解約、失敗した課金の再試行といった処理は手作業では回らなくなり、売上の取りこぼしや解約の増加に直結しかねません。

本稿では、SaaS・サブスク事業者の事業/経理/IT部門と、経営層に近いビジネスレイヤーの方に向けて、定期課金管理システムの守備範囲と、請求書システムや会計・契約管理(CLM)との違い、サブスク特有の論点、そして外注先の選び方と進め方を、公式情報をもとに整理します。都度請求の一般論ではなく、継続課金・契約更新・チャーン管理に軸足を置いて解説していきましょう。

サブスク・定期課金管理システムとは——契約ライフサイクルと定期請求を回す仕組み

サブスク・定期課金管理システムとは、契約プランに応じた金額を周期的に請求し続け、契約の申込から更新・解約までを一貫して管理する仕組みを指します。都度きりの請求と最も違うのは、いちど契約が成立したあとも、更新や課金が自動で繰り返し発生する点です。おもな守備範囲は、プランと料金体系の管理、契約ライフサイクル(申込・更新・解約・一時停止)の管理、定期請求サイクルの実行、決済のリトライと督促、そしてMRR(月次経常収益)やチャーンといったサブスク指標の可視化になります。

この仕組みの本質は、一度きりの取引を処理することではなく、契約という「状態」を持ち続け、それを時間軸に沿って回し続けることにあります。こうした処理をコード化し、取りこぼしなく回すことが、定期課金管理システムに課された役割になります。

裏を返せば、単発の請求書を作って送るだけの仕組みとは、設計思想からして別物だと言えるでしょう。継続を前提とする以上、契約の途中変更や失敗課金への対処が避けられません。次章では、隣接するシステムとの違いをもう少し具体的に切り分けていきましょう。

請求書システム・会計・販売管理・CLMとの違いと連携

サブスク管理は、いくつかの隣接システムと役割が重なって見えやすい領域です。混同したまま開発に入ると、機能の重複や連携の抜けを招きます。まずは守備範囲を切り分けておきましょう。

最も混同されやすいのが、請求書発行・管理システムとの違いです。請求書システムは、取引ごとに発生した請求を書面やデータとして発行し、入金消込や売掛管理を担う仕組みで、いわば「都度請求」を得意とします。これに対しサブスク管理システムは、契約が続くかぎり請求が繰り返し生まれる「継続課金」を前提に、契約状態と請求サイクルを結びつけて管理する点に軸足があります。両者の主な違いを整理すると次の通りです。

会計システムとの関係も押さえておきましょう。会計システムは、発生した取引を仕訳として記録し、決算や税務申告につなげる仕組みです。サブスク管理システムが確定させた請求や入金の情報は、売掛金・売上として会計へ連携されます。とくに継続課金では、いつ・いくらを売上として計上するかという収益認識の扱いが論点になりやすく、この点は第3章で改めて取り上げます。

販売管理システムは受注・出荷・在庫といった商流を扱う仕組みで、物販を伴う事業では取引データの供給元になります。また、契約書そのものの作成・締結・更新・保管を電子的に管理するCLM(Contract Lifecycle Management。契約ライフサイクル管理)とも連携の余地があります。CLMが「契約書という文書」を管理するのに対し、サブスク管理システムは「契約に基づく課金と請求」を回す役割で、両者は補完関係にあると捉えると整理しやすいでしょう。開発では、これらとのデータ連携の設計こそが成否を分ける鍵になります。

サブスク特有の要件——料金体系・日割り・MRR/チャーン・収益認識

サブスク管理システムの難所は、料金と契約の「変化」を正確に扱うところにあります。ここでは開発規模を左右しやすい論点を順に見ていきます。

料金体系——複数プラン・従量・段階課金への追随

料金体系は、サービスの成長とともに複雑さを増していく領域です。定額の月額プランだけで始めたサービスも、やがて年額プラン、ユーザー数に応じた従量課金、利用量が増えるほど単価が下がる段階(ボリューム)課金、初期費用やオプションの加算といった要素が積み重なっていきます。システム側は、こうした料金設計の変更に柔軟に追随できる構造であることが前提です。料金ロジックがハードコードされていると、プランを一つ足すたびに改修が発生し、機会損失を生む要因になります。

日割り・プロレーション——契約の途中変更を精算する

継続課金では、契約期間の途中でのプランのアップグレードやダウングレードがつきものです。このとき、残り期間に応じて差額を日割りで精算する処理をプロレーション(比例配分)と呼びます。月の半ばでの上位プランへの変更、途中解約時の返金や日割り、一時停止と再開に伴う請求の調整——こうした端数計算を正確に扱えるかどうかが、経理の信頼と顧客満足の双方に影響します。境界条件の設計とテストに手間がかかる部分です。

MRR/ARR・チャーン——サブスク指標の可視化

サブスク事業では、単月の売上だけでなく、経常的に見込める収益の推移を追うことが欠かせません。代表的な指標が、月次経常収益を示すMRR(Monthly Recurring Revenue)と、その年換算であるARR(Annual Recurring Revenue)です。加えて、一定期間にどれだけの顧客や収益が離脱したかを示すチャーン(解約率)も、事業の健全性を測る中心的な指標になります。システムには、これらを契約データから正しく積み上げて可視化する設計が要ります。指標の定義がぶれると経営判断を誤らせるため、集計ロジックの厳密さが要点です。

収益認識——一定期間にわたる売上計上

継続課金でとくに慎重な設計を要するのが、収益認識です。企業会計基準委員会(ASBJ)の企業会計基準第29号「収益認識に関する会計基準」では、収益を認識するまでの5つのステップが示されており、履行義務を充足した時点で収益を認識するのが原則とされています^*1。サブスクのように、契約期間を通じてサービスを継続的に提供する取引は、一定の期間にわたり履行義務が充足される類型に当たり得ます^*1。この場合、たとえば年額を前受けしても、一括で売上に計上するのではなく、期間の経過に応じて按分して認識する処理が必要になります。前受金(契約負債)の管理と、期間按分による売上計上を支える設計は、会計連携の要と言えるでしょう。実際の適用は自社の会計方針や監査法人の判断にもよるため、要件定義の段階で経理部門を巻き込むことが大切です。

失敗課金と解約抑止——dunning・カード有効期限更新・与信

継続課金には、都度請求にはない固有のリスクが潜みます。その代表が、意図せぬ課金失敗による解約、いわゆる「不本意チャーン」です。ここを取りこぼすと、顧客が離れる意思がないのに収益が失われます。

クレジットカードでの定期課金は、残高不足やカードの有効期限切れ、利用限度超過などによって一定の割合で失敗するものです。この失敗した課金に対し、日を置いて自動で再試行し、顧客へメールなどで支払いを促す一連の督促プロセスをdunning(ダニング)と呼びます。いつ・何回リトライするか、どのタイミングで通知を送るか、猶予期間をどう設けるか——この設計の巧拙が、回収率とチャーン率を大きく左右します。単に失敗を記録するだけの実装では不十分でしょう。

あわせて重要になるのが、カード有効期限の更新への対応です。カードが更新されて番号や有効期限が変わると、登録済みの情報のままでは課金が通らなくなります。これを自動で追随させる仕組みとして、カードブランドや決済代行が提供するアカウントアップデーター(カード情報の自動更新サービス)の活用が挙げられます。こうした機能を決済代行と連携して取り込めるかどうかも、外注時に確認しておきたい観点です。

さらに、BtoBのサブスクでは与信管理も論点になります。請求書払い(掛売り)を認める取引先には与信枠を設け、超過をアラートする、支払い遅延には段階的に督促する、といった運用が求められます。どこまでを自動化し、どこから人が介在するかの線引きが、開発規模を左右する要素です。継続課金では、こうした「失敗への備え」を最初から設計へ織り込んでおくことが、事業の安定に直結します。

決済と法対応の確認点——カードセキュリティ・適格請求書・定期購入の表示義務

サブスク管理システムは、決済とお金の記録を扱う以上、法令やセキュリティ基準への対応が避けられません。一般的な業務機能と違い、要件が制度で定められている点に注意が必要です。ここでは3つの柱を公式情報にもとづいて整理します。

クレジットカードのセキュリティ——非保持化またはPCI DSS

カード決済を扱う事業者には、割賦販売法に基づくセキュリティ対策が求められます。EC加盟店は、カード情報を自社で保持しない「非保持化」を行うか、カード情報を保持する場合はPCI DSS(カード業界の国際的なセキュリティ基準)に準拠する必要があるとされています^*3。加えて、決済時のEMV 3-Dセキュア(本人認証)の導入や、自社システムの脆弱性対策も指針で位置づけられています^*3。経済産業省が所管する「クレジットカード・セキュリティガイドライン」は、こうした対策の実務指針として継続的に改訂されており、最新版の確認が欠かせません（出典：経済産業省「クレジットカード・セキュリティガイドライン」）。実務では、これらの要件を自社で背負い込まず、PCI DSSに準拠した決済代行サービスを介してカード情報を非保持化する構成が一般的です。設計段階で、どの決済代行と、どの方式で連携するかを固めておきましょう。

適格請求書——インボイス制度への対応

サブスクであっても、事業者間取引では適格請求書(インボイス)の交付が論点になります。適格請求書には、発行者の氏名または名称および登録番号、取引年月日、取引内容、税率ごとに区分した対価の額および適用税率、税率ごとの消費税額等、交付を受ける事業者の氏名または名称といった記載事項が国税庁により定められています^*2。定期課金では請求が毎周期発生するため、これらの要件を満たす請求書を自動で生成・交付し、保存できる設計が求められます。

定期購入の表示義務——特定商取引法

消費者向け(BtoC)のサブスクでは、特定商取引法の定期購入に関する規制にも留意が要ります。令和4年(2022年)6月1日施行の改正により、通信販売では、契約を2回以上継続して締結する必要がある場合、その旨や販売条件を最終確認画面に表示することが義務づけられました^*4。解約の条件・方法や、申込期間なども省略できない表示事項として扱われています^*4。申込みや解約の導線をシステムで実装する際は、こうした表示要件を満たすことが前提になります。BtoCを含むサービスでは、法務部門と表示内容をすり合わせておくとよいでしょう。

パッケージ(課金基盤)とスクラッチの判断軸と外注先の選び方

要件が見えてきたら、次は実現手段の選択です。市販のサブスク管理SaaSや課金基盤を使うのか、スクラッチで開発するのか、あるいは両者を組み合わせるのか。判断軸を整理しておきましょう。

サブスク管理SaaS・課金基盤の強みは、複数プランや従量課金、dunning、収益認識の按分といった、継続課金に固有の機能があらかじめ用意されている点にあります。法対応や決済連携もサービス側で更新されることが多く、立ち上げの速さが魅力です。一方で、自社固有の複雑な料金体系や、基幹システムとの深い連携には、仕様上の制約が出ることもあるでしょう。スクラッチ開発は自由度が高く、自社の課金ロジックを作り込める半面、料金設計の変化への追随やセキュリティ対応を自前で担い続ける負担が生じます。標準的な課金モデルであればSaaSや課金基盤で足りることが多く、独自性の高い料金設計や密な連携が必要ならスクラッチや個別開発、あるいはSaaSを核に不足分を補うハイブリッド型が現実的な選択肢になります。

外注する場合は、委託先の見極めが品質を左右します。第一に、複雑な料金設計への追随力です。プラン追加や課金モデルの変更を、改修コストを抑えて反映できる設計思想を持っているかを確認します。第二に、決済代行・会計システムとの連携実績です。利用する決済代行や会計製品に精通した委託先であれば、非保持化の構成や収益認識の按分ロジックの設計を任せやすくなります。第三に、収益認識基準への対応と、dunning・解約抑止といったサブスク固有の論点への理解です。これらを踏まえた提案ができるかどうかが、選定の分かれ目になります。開発を一社で完結できる元請（プライムベンダー）に委ねるのか、複数ベンダーを組み合わせるのかも、責任範囲を明確にするうえで検討しておきたい点でしょう。

これらの確認を進めるうえでは、まず自社の現状——料金体系、想定契約数、既存の決済・会計システム、求める自動化の範囲——を棚卸ししておくと、委託先との対話がかみ合い、後工程での手戻りも抑えやすくなります。

まとめ：サブスク・定期課金管理システムの外注で押さえる3つの判断軸

本稿では、サブスク・定期課金管理システムの守備範囲と外注の進め方を、公式情報をもとに整理しました。要点は3つに集約できます。第一に、この仕組みは契約ライフサイクルと定期請求を継続的に回すものであり、都度請求の請求書システムとは設計思想から異なる点です。会計・販売管理・CLMとの連携設計が開発の要になります。第二に、複数プランや従量・段階課金への追随、日割り(プロレーション)、MRR/チャーンの可視化、そして収益認識基準に沿った期間按分の売上計上^*1という、継続課金ならではの要件を満たす必要があります。第三に、失敗課金へのdunningやカード有効期限更新、割賦販売法に基づくカードセキュリティ^*3、適格請求書^*2やBtoCでの定期購入の表示義務^*4への対応を前提に、外注先は料金設計への追随・決済/会計連携・解約抑止の理解を確認軸にすることです。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

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

1. *1　出典：企業会計基準委員会（ASBJ）「企業会計基準第29号 収益認識に関する会計基準」（https://www.asb-j.jp/jp/accounting_standards_system/details.html?topics_id=13）
2. *2　出典：国税庁「No.6625 適格請求書等の記載事項」（https://www.nta.go.jp/taxes/shiraberu/taxanswer/shohi/6625.htm）
3. *3　出典：一般社団法人日本クレジット協会「加盟店（クレジットカードを取り扱うお店）の皆様へ」（https://www.j-credit.or.jp/security/understanding/member-store.html）
4. *4　出典：消費者庁「通信販売」（特定商取引法ガイド）（https://www.no-trouble.caa.go.jp/what/mailorder/）
5. *5　出典：経済産業省「クレジットカード・セキュリティガイドライン」（クレジット取引セキュリティ対策協議会）

Tweet