概要

ZuoraのProduct Catalogは「Product → Rate Plan → Charge」の3層構造で、複雑なサブスクリプションの課金ロジックを設定として表現します。

従来の商品マスタとは根本的に設計思想が異なる
ChargeのタイプとModelの組み合わせで、あらゆる課金パターンを表現できる
課金開始タイミング・日割り計算・会計連携まで、Chargeレベルで細かく制御できる

なぜProduct Catalogが「普通の商品マスタ」と違うのか

SaaSの「売り物」は価格モデルそのもの。従来の商品マスタの考え方では、サブスクリプション特有の複雑さを表現できません。

ERPやCRMにも「商品マスタ」と呼ばれるものはあります。しかしZuoraのProduct Catalogは、それらとは根本的に異なる思想で設計されています。

従来の商品マスタは「モノを売る」ために作られています。商品コード・商品名・単価の3点セットがあれば十分で、「このモノを1個いくらで売る」という情報を管理するためのものです。

ZuoraのProduct Catalogが解決しようとしている問題はまったく違います。SaaSのようなサブスクリプションビジネスでは、同じ「商品」を売っていても、顧客ごとに以下のような複雑さが発生します。

初月だけ初期費用がかかる
月額料金と、使った分だけ課金される従量料金が混在する
同じ商品でも「月払いプラン」と「年払いプラン」がある
途中でプランをアップグレードすると料金が変わる

これを「商品コード＋単価」の1行で表現しようとすると、プランの数だけ商品コードが増殖し、管理が破綻します。実際、既存のシステムで無理やりサブスクを管理しようとした企業が「コードが数千行になって誰も把握できない」という状況に陥るのはよくあるケースです。

ZuoraのProduct Catalogは、この問題を「商品と価格を分離する」という設計思想で解決します。「何を売るか（Product）」「どういう料金体系で売るか（Rate Plan）」「個々の料金はどう計算するか（Charge）」の3層に分けることで、複雑な課金ロジックを整理された構造で表現できるようにしています。

従来の商品マスタ：プランの数だけ商品コードが増える

ZuoraのProduct Catalog：1つのProductに料金体系がぶら下がる

3層構造：Product / Rate Plan / Charge

3層のそれぞれが「何を売るか」「どう売るか」「いくら請求するか」を分担することで、複雑な課金体系を整理された構造で管理できます。

Product（プロダクト）

会社が販売するサービスそのものを表します。「クラウドストレージ」「分析ツール」のような単位で、カタログ上の「商品のくくり」です。顧客が選ぶのはProductではなく、その下のRate Planです。Productは複数のRate Planをグループ化するコンテナの役割を担います。

Rate Plan（レートプラン）

「どういう料金体系で買うか」を表します。顧客が実際に選ぶのはこの層です。たとえば「月払いプラン」「年払いプラン」「エンタープライズプラン」がそれぞれ1つのRate Planになります。1つのProductに複数のRate Planを持てるため、同じサービスを異なる料金体系で販売できます。

Charge（チャージ）

「実際にいくら請求するか」の計算ルールを表します。1つのRate Planに複数のChargeを持てるため、「初期費用＋月額料金＋従量料金」のように異なる性質の料金を組み合わせられます。

3層の責任分界を整理するとこうなります。

Chargeの3タイプ：いつ課金するかを決める

ChargeのタイプはOne-time・Recurring・Usageの3種類。「いつ課金が発生するか」によって使い分けます。

タイプ	課金タイミング	典型的な用途
One-time	1回だけ	初期費用・セットアップ費用・解約違約金
Recurring	一定周期で繰り返し	月額・年額の基本料金
Usage	使った量に応じて後払い	API呼び出し回数・ストレージ使用量・通話時間

重要なのは、これらを1つのRate Planに組み合わせられる点です。「契約時に初期費用（One-time）、毎月の基本料金（Recurring）、使った分だけの従量料金（Usage）」を1つのRate Planとして束ねられます。

Charge Modelの選び方：どう計算するかを決める

ChargeのタイプとModelの組み合わせで1つのChargeが完成します。タイプが「いつ課金するか」、Modelが「どう金額を計算するか」を決めます。

Charge Model	計算方法	向いているケース
Flat Fee	数量に関係なく固定金額	月額固定のSaaSプラン
Per Unit	数量 × 単価	シート数・ライセンス数で課金
Volume	総数量に応じて単価が変わる（全数量に同一単価を適用）	大口顧客に割引を提供したい
Tiered	数量の段階ごとに異なる単価を適用	使えば使うほど段階的に単価が下がる従量課金
Overage	基本料金に含まれる上限を超えた分だけ追加課金	「月100GBまで定額、超過分は¥10/GB」
Discount	他のChargeに対して割引を適用	キャンペーン割引・長期契約割引

VolumeとTieredは似ていますが、計算方法が異なります。

タイプとModelの組み合わせ例

タイプが「課金の発生タイミング」、Modelが「金額の計算方法」で、この2軸の組み合わせで1つのChargeが決まります。

Charge名	タイプ	Model	意味
初期費用	One-time	Flat Fee	契約時に¥5,000を1回だけ請求
月額基本料	Recurring	Flat Fee	毎月¥1,000を固定で請求
シート料金	Recurring	Per Unit	毎月「シート数 × ¥500」を請求
ストレージ	Usage	Tiered	使った量を段階単価で翌月請求
超過通信費	Usage	Overage	上限を超えた分だけ翌月請求

1つのRate Planにこれらを複数組み合わせることで、「初期費用＋月額固定＋シート数＋使った分」という複合的な料金体系を1つのプランとして表現できます。

Trigger Condition：課金を「いつ始めるか」を制御する

課金開始のトリガーは「契約・開通・承認」の3つのビジネスイベントから選べます。ChargeごとにTrigger Conditionを設定できるので、同じプランの中でも料金の種類によって課金開始タイミングを変えられます。

Rate PlanとChargeで「何をいくらで売るか」が決まりました。次の問いは「いつから課金を始めるか」です。

SaaSの契約では、「契約書にサインした日」「実際にシステムが使えるようになった日」「顧客が正式に受け入れた日」がバラバラになることがよくあります。Trigger Conditionは、この3つのビジネスイベントのどれを課金開始のトリガーにするかを設定するものです。

Trigger Condition	課金開始タイミング	典型的なケース
Upon Contract Effective	契約が成立した日	契約と同時に課金開始でよいシンプルなケース
Upon Service Activation	サービスが開通した日	開通工事や環境構築が必要なケース
Upon Customer Acceptance	顧客が受け入れた日	検収期間がある受託型・エンタープライズ契約
Upon Specific Date	指定した日付	キャンペーン開始日など任意の日付

重要なのは、同じRate Plan内のChargeごとに異なるTrigger Conditionを設定できる点です。たとえば「初期費用は契約日から、月額料金はサービス開通日から」という設定が可能です。

Proration：月の途中の変更を日割りで計算する

Prorationは「請求サイクルの途中でChargeの内容が変わったとき」に自動で日割り計算する仕組みです。ChargeレベルでオンオフできるのでChargeの性質に合わせて制御します。

Proration（按分計算）とは、月の途中でプランが変わったときに、使った日数分だけ料金を計算する仕組みです。「按分」という会計用語が出てきますが、要は「日割り計算」のことです。

たとえば月額¥3,000のプランに月の途中（15日）から加入した場合、その月は半分しか使っていないので¥1,500だけ請求するのが自然です。これをZuoraが自動で計算してくれるのがProrationです。

Prorationが発生するのは主に以下のケースです。

ケース	何が起きるか
月の途中で新規契約	契約日〜月末までの日割り料金を請求
月の途中でプランをアップグレード	旧プランの残り日数分をクレジット、新プランの残り日数分を請求
月の途中でプランをダウングレード	同上（差額を次回請求に充当）
月の途中で解約	解約日までの日割り料金を請求（設定による）

請求日を毎月1日に固定しているサービスでは、月の途中に起きる契約・変更・解約の都度、次の1日時点で日割り計算が発生します。請求日を固定しているサービスほどProrationが頻繁に発生するため、設計時に意識しておく必要があります。

設定前に準備すること

Product Catalogの設定を始める前に、経理チームと「会計コード」と「収益認識ルール」を決めておく必要があります。後から変更すると過去の請求データへの影響が生じます。

Product Catalogを設定する前に、Zuora外で決めておくべきことが2つあります。どちらも「Chargeを作るときに必ず入力を求められる項目」なので、後回しにすると設定が止まります。

会計コード（Accounting Code）

会計コードとは、売上をどの勘定科目に分類するかを示すコードです。たとえば「月額サブスクの売上」と「初期費用の売上」を別々の勘定科目で管理したい場合、それぞれ異なる会計コードをChargeに紐付けます。

Zuoraは請求書を発行するたびに、このコードをもとに会計システムへの仕訳データを自動生成します。コードが設定されていないと、経理側で手動で仕分け直す作業が発生します。

収益認識ルール（Revenue Recognition Rule）

収益認識とは「売上をいつ計上するか」のルールです。たとえば年間契約で¥120,000を一括で受け取っても、会計上は毎月¥10,000ずつ売上として計上するのが原則です（サービスを提供した月に売上を立てる）。

ZuoraはChargeに収益認識ルールを紐付けることで、入金タイミングと売上計上タイミングを自動的に分けて管理します。