概要

ZuoraはBill Runを起点に、BCDとCharge Trigger Dayのルールに従って請求書を自動生成します。InvoiceのLifecycleを理解し、Prorationの日割り計算、Usage請求、調整（Credit / Debit Memo）まで把握することで、企業の請求業務全体を設計できるようになります。

業務フロー — Bill RunからInvoiceが生まれるまで

Bill Runが実行されると、BCDに一致するアカウントの請求書が自動生成されます。請求の流れを「実行 → 生成 → 確定 → 回収」という4ステップで把握しておきましょう。

Zuoraの請求業務は以下の流れで進みます。

Bill Run設計 — BCDとCharge Trigger Day

「誰をいつ請求するか」はSubscriptionのBCD（Bill Cycle Day）とRate Plan ChargeのCharge Trigger Dayで決まります。この2つのオブジェクトの役割を正確に理解することが、Bill Run設計の出発点です。

オブジェクト階層とBCDの位置

Zuoraの請求に関わるオブジェクトは以下の階層で管理されています。

Charge Trigger Dayの3種類

Bill Runの実行方式

Bill Runのキャンセル条件

Bill Runの日次バッチのしくみ

Bill Runは毎日自動実行されますが、すべてのアカウントのInvoiceが毎日作成されるわけではありません。Target Date（通常は当日）を基準に、BCDが一致するアカウントだけを対象にInvoiceを生成します。

Invoice Lifecycle — Draft・Posted・Cancelled

InvoiceはDraftとして生成され、Postすることで会計上の確定書類になります。PostされたInvoiceは直接編集できないため、修正はCredit MemoまたはDebit Memoで行います。この設計は会計監査証跡を守るための業界標準です。

Invoiceのステータス遷移

PostingするとPayment Runの対象になる

なぜPostしたら変更できないのか

Zuoraでは「PostされたInvoiceは変更しない」というビジネス原則に従っています。これは企業会計の監査証跡（Audit Trail）の要件に起因します。一度確定した請求書を後から修正すると、会計記録の信頼性が損なわれるためです。

自動PostとManual Post

Bill Runの後、InvoiceをDraftのままにするか自動でPostするかはBilling Settingsで制御できます。

Invoice Itemの構成

InvoiceはSubscriptionの課金明細をInvoice Itemとして一覧で持ちます。1つのInvoiceに複数のInvoice Itemが含まれることが一般的です。

Standalone Invoice

通常のInvoiceはSubscriptionのBill Runから生成されますが、Standalone Invoiceを使うと、Subscriptionに紐づかない単独の請求書を手動で発行できます。

Proration — 月途中の変更と日割り計算

SubscriptionをBCDの途中で変更すると、Zuoraは変更前後の差分を日割りで計算してInvoiceに反映します。Prorationは「公平な課金」を自動化するZuoraの中核機能の一つです。

Prorationとは

Prorationとは、請求期間の途中で料金が変わった場合に、残り日数に応じて料金を按分する仕組みです。たとえば月額3,000円のプランに月の途中から加入した場合、加入日から月末までの日数分だけを請求します。

月額 3,000円 ／ 31日 × 残り20日 ＝ 1,935円（Prorated金額）

Prorationが発生する主なタイミング

ProrationのOn/Off

Rate Plan ChargeにはProrationを有効にするかどうかの設定があります。

Prorationモードの2種類

Zuoraには2つのProrationモードがあります。試験ではどちらが「日単位」かを問われることがあります。

Usageの請求 — ロード・On Demand・後払い

UsageチャージはZuoraへデータをロードしてから請求される、後払い専用のチャージです。「実際に使った分だけ請求する」というシンプルな原則を、Zuoraはそのまま実装しています。

Usageチャージとは

Zuoraには3つのチャージタイプがあります。

UsageチャージはRecurringやOne-timeと異なり、使用量の実績データがZuoraに存在してはじめて請求額が確定します。そのため、必ず**後払い（arrears）**になります。

使用量データのロード方法

ZuoraにUsageデータを登録する方法は2つだけです。

データをロードする際は、accountNumber・subscriptionNumber・chargeNumber・startDateTime・endDateTime・quantity を正確に指定する必要があります。

On Demand請求 — ロード直後に請求したい場合

通常のBill Runは毎日夜間バッチで実行されますが、使用量データをロードした翌日のBill Runまで待てないケースもあります。たとえば、解約後すぐに最後の使用量を請求したい場合などです。

Zuoraでは、使用量データをロードした後にOn Demand Bill Runを実行することで、通常のBCDサイクルを待たずに請求書を発行できます。

RecurringのIn Arrearsとの違い

Credit / Debit Memo — 調整の業務パターン

Invoiceを発行した後に金額を修正したいとき、Zuoraは元のInvoiceを直接書き換えません。Credit MemoとDebit Memoという専用オブジェクトで差分を記録し、会計上の正確な証跡を残します。

なぜInvoiceを修正しないのか

PostedになったInvoiceは直接編集できません。理由は監査証跡（Audit Trail）の保全です。企業会計では「一度確定した請求書は変更してはならない」という原則があり、Zuoraはこれを設計に反映しています。

Credit Memo と Debit Memo

スタンドアローンMemo

Credit Memoの用途と使えるケース

Credit Memoの残高を使う — Unapplied Balance

Credit Memoは発行しただけでは現金の動きになりません。以下の2つの使い道があります。

充当していない残高は「Unapplied Credit Memo Balance」として顧客のAccountに残り続けます。

Credit Memo → Refundの処理フロー

Auto-Apply設定