概要

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の絞り込み条件（201補足）

Bill Runは「対象バッチ」と「対象Bill Cycle Day」の二重フィルタで請求対象を決めます。複数バッチが存在する環境で特定バッチのみを対象にBill Runを実行しても、そのバッチに属する顧客全員が対象になるわけではありません。指定したBill Cycle Dayに該当する顧客だけが、選んだバッチの中からさらに絞り込まれます。「バッチに属している＝対象になる」と早合点しないことが重要です。

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に紐づかない単独の請求書を手動で発行できます。

Invoiceの出力形式 — 最終出力は常にPDF

顧客に届くInvoiceファイルの形式は、テンプレートの種類に関わらず常にPDFです。テンプレート自体の作り方には2種類あります。

Billing Document Template Configuration — 請求書のレイアウトを設計する

Billing Document Templateは、Invoice・Credit Memo・Debit Memoの見た目（レイアウト・自社ブランド・記載項目）を設計する機能です。テンプレートはHTMLまたはWordで作成し、Merge Field（差し込みフィールド）で実データを埋め込みます。テンプレートは商品単位ではなくAccount（顧客）単位で適用され、顧客ごとに異なるレイアウトを使い分けることもできます。

Merge Field ― データをテンプレートに差し込む仕組み

Merge Fieldは、{{Invoice.InvoiceNumber}} のように「オブジェクト.フィールド名」をドット区切りでつなぎ、二重中括弧で囲んだ記法です。テンプレートの種類ごとにルートオブジェクトが決まっています。

Merge Fieldは以下の3種類に分類されます。

Default TemplateとCustom Templateの関係

Zuoraにはあらかじめ用意されたSystem Default Templateと、自社ブランドに合わせて作成するCustom Templateがあります。

Custom Templateを作成しただけでは自動的には使われません。**Accountの「Default Template」として明示的に設定する（Zuora UIまたはAPI経由）**ことで、そのAccountに発行されるInvoice・Credit Memo・Debit Memoに適用されます。

HTMLテンプレートとWord Mail Mergeテンプレートの比較

HTMLテンプレートでは、行・列・データテーブル・フォント・ページ設定・ヘッダーとフッター・バーコード・画像・JavaScriptなど、細かい要素を個別に構成できます。特に「Group By機能」を使うと、複数のInvoice Itemを商品カテゴリなどでグルーピングして表示するといった高度なレイアウトも組めます。

多言語対応（Multilingual Billing Document）

グローバル展開している企業向けに、1つのテンプレートから顧客ごとの言語でPDFを自動生成する機能があります。英語・ドイツ語・フランス語・スペイン語・中国語・アラビア語など、マルチバイト文字や右書き言語を含む幅広い言語に対応しています。

請求書生成のタイミング

Invoice・Credit Memo・Debit Memoの生成は、Bill Runに伴う自動生成のほか、個別アカウント単位でのオンデマンド生成にも対応しています。

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モードがあります。試験ではどちらが「日単位」かを問われることがあります。

日割り計算の設定（101補足）

月次請求で月の途中に開始・変更・解約したチャージを実日数で日割りしたい場合は、Billing Settingsで「Bill recurring charges for partial month」をYesにし、「When prorating a month, assume 30 days or use actual days」を「Use actual number of days」に設定します。「Bill usage charges for partial month/week」はUsage chargeの設定であり、Recurringの日割りとは別の項目です。日割り（Proration）はRecurring chargeのみが対象で、Usage chargeは対象外です。

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

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

Usageチャージとは

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

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

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

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

Usageデータの必須項目

必須項目はAccount(Number)・UOM(単位)・Quantity(数量)・Start Date(開始日)の4つです。

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設定

101補足 — Payment TermとBilling Period拡張

Payment Termの計算例

Net Nという支払条件は「請求書日付＋N日」が支払期日になります。月末固定や請求書日付そのものと混同しないでください。たとえば請求書日付が1月1日でPayment TermがNet 21の場合、支払期日は1月1日＋21日＝1月22日です。「月末（1/31）に固定する」「請求書日付そのものを期日とする」はいずれも典型的な誤答パターンです。

Billing Periodの拡張（Week単位を有効化する）

週次のBilling Periodが選択肢に出てこない場合は、Billing Settings > Define Billing Periodsの「Customize Billing Periods」セクションでWeekを有効化します。日割り自体の設定（Define Billing Rules）や価格の基準単位（Customize List Price Base）とは別画面である点に注意してください。