@mickey最終更新 2026年7月28日投稿 2026年6月13日
[BI5] Billing, Invoicing, Credit and Debit Memos
概要
ZuoraはBill Runを起点に、BCDとCharge Trigger Dayのルールに従って請求書を自動生成します。InvoiceのLifecycleを理解し、Prorationの日割り計算、Usage請求、調整（Credit / Debit Memo）まで把握することで、企業の請求業務全体を設計できるようになります。
業務フロー — Bill RunからInvoiceが生まれるまで
Bill Runが実行されると、BCDに一致するアカウントの請求書が自動生成されます。請求の流れを「実行 → 生成 → 確定 → 回収」という4ステップで把握しておきましょう。
Zuoraの請求業務は以下の流れで進みます。
| ステップ | 内容 |
|---|---|
| Bill Run実行 | 毎日定期バッチ（または手動Ad Hoc）で実行される |
| Invoice生成 | BCDに該当するアカウントのInvoice（Draft）が作成される |
| Invoice確定 | 担当者またはシステムがInvoiceをPostする |
| Payment回収 | 自動決済またはPayment運用でアカウントから回収する |
レーティングとビリングの仕組み — Rating Engine と Billing Engine
Zuoraの請求処理は、バックエンドの「Rating and Billing Engine（RBE）」が担っています。RBEはSubscriptionやUsageのデータからCharge Eventを算出するRating Engineと、Charge EventをInvoiceにまとめるBilling Engineの2つで構成されます。
RatingとBillingの役割分担
| エンジン | 役割 |
|---|---|
| Rating Engine | Chargeを使用量データと突き合わせて金額を計算し、Charge Eventを生成する |
| Billing Engine | Charge Eventを集約し、税計算を行った上でInvoiceに変換する |
Bill Run実行時の処理ステップ（RBEの内部動作）
| # | ステップ | 内容 |
|---|---|---|
| 1 | 対象アカウントの読み込み | 処理対象アカウントのSubscriptionとOrderをすべて読み込む |
| 2 | Charge Segmentの読み込み | 「Draft」以外のステータスにあるChargeを読み込む |
| 3〜4 | Rating | Rating EngineがCharge Segmentごとに0件以上のCharge Eventを生成する（各Chargeは独立して処理される） |
| 5〜6 | Billing | Billing EngineがCharge Eventを集約してInvoiceを作成する。既存のDraft Invoiceがあれば明細を追記し、なければ新規作成する |
Bill Run設計 — BCDとCharge Trigger Day
「誰をいつ請求するか」はSubscriptionのBCD（Bill Cycle Day）とRate Plan ChargeのCharge Trigger Dayで決まります。この2つのオブジェクトの役割を正確に理解することが、Bill Run設計の出発点です。
オブジェクト階層とBCDの位置
Zuoraの請求に関わるオブジェクトは以下の階層で管理されています。
| オブジェクト | 設定する内容 | 例 |
|---|---|---|
| Account | 顧客情報・支払い方法 | 請求先会社名、クレジットカード |
| Subscription（BCD） | 毎月何日に請求するか | BCD=1 → 毎月1日に請求 |
| Rate Plan Charge（Trigger） | チャージをいつ開始するか | Contract Effective Date など |
Charge Trigger Dayの3種類
| Trigger | 開始タイミング | 使いどころ |
|---|---|---|
| Contract Effective Date | 契約締結日 | 契約と同時に課金を開始したい場合 |
| Service Activation Date | サービス開通日 | 実際にサービスが使える状態になった日から課金したい場合 |
| Customer Acceptance Date | 顧客検収日 | 顧客が受け入れを確認した日から課金したい場合 |
Bill Runの実行方式
| 方式 | 説明 | 使いどころ |
|---|---|---|
| Scheduled（定期バッチ） | 毎日夜間に自動実行 | 通常運用 |
| Ad Hoc | 担当者が手動で実行 | 解約時の最終請求、テスト実行など |
Bill Runの絞り込み条件（201補足）
Bill Runは「対象バッチ」と「対象Bill Cycle Day」の二重フィルタで請求対象を決めます。複数バッチが存在する環境で特定バッチのみを対象にBill Runを実行しても、そのバッチに属する顧客全員が対象になるわけではありません。指定したBill Cycle Dayに該当する顧客だけが、選んだバッチの中からさらに絞り込まれます。「バッチに属している＝対象になる」と早合点しないことが重要です。
Bill Runのステータス
Bill Runは作成から完了までの間、以下のステータスで管理されます。
| ステータス | 内容 |
|---|---|
| Pending | 処理待ちでキューに入っている状態 |
| Processing | 対象アカウントを処理している最中 |
| Completed | 処理が正常に完了した状態 |
| Error | 処理が失敗した状態。実行した担当者にエラー発生の通知メールが送られる |
| Canceled | Bill Runがキャンセルされた状態。PendingまたはCompletedのBill Runはキャンセルできるが、Processing中のBill Runはキャンセルできない |
| Posted | そのBill Runで生成された全InvoiceがまとめてPostされた状態。Posted Invoiceは編集できないが、エラーがあれば調整（Credit/Debit Memo）で対応する |
Bill Runのキャンセル条件
| キャンセル可能な状態 | 内容 |
|---|---|
| Pending（保留中） | まだ実行されていないBill Run |
| 完了済み・Posted Invoiceなし | 実行は完了したが、まだ一件もInvoiceがPostされていない |
Bill Runの日次バッチのしくみ
Bill Runは毎日自動実行されますが、すべてのアカウントのInvoiceが毎日作成されるわけではありません。Target Date（通常は当日）を基準に、BCDが一致するアカウントだけを対象にInvoiceを生成します。
Invoice Lifecycle — Draft・Posted・Cancelled・Error
InvoiceはDraftとして生成され、Postすることで会計上の確定書類になります。PostされたInvoiceは直接編集できないため、修正はCredit MemoまたはDebit Memoで行います。この設計は会計監査証跡を守るための業界標準です。
Invoiceのステータス遷移
| ステータス | 説明 |
|---|---|
| Draft | 作成直後。編集・再生成・Post・キャンセルが可能 |
| Posted | 確定済み。変更・削除不可。会計帳簿に計上される。「Cancel Post」でDraftへ戻せる |
| Cancelled | キャンセル済み。キャンセルされたInvoiceは削除可能で、削除後は復元できない |
| Error | Postされた請求書の削除は本来まれな操作であるべき。削除に頼る前に、なぜInvoiceにエラーが発生したのかを分析するプロセスを整えておき、やむを得ず削除する場合は、後続の会計データも合わせて更新する必要がある |
PostingするとPayment Runの対象になる
なぜPostしたら変更できないのか
Zuoraでは「PostされたInvoiceは変更しない」というビジネス原則に従っています。これは企業会計の監査証跡（Audit Trail）の要件に起因します。一度確定した請求書を後から修正すると、会計記録の信頼性が損なわれるためです。
自動PostとManual Post
Bill Runの後、InvoiceをDraftのままにするか自動でPostするかはBilling Settingsで制御できます。
| 設定 | 動作 | 適したケース |
|---|---|---|
| Automatic Post | Bill Run完了と同時にInvoiceをPostedにする | 確認フロー不要、大量請求を自動化したい場合 |
| Manual Post | InvoiceはDraftで生成され、担当者が個別にPostする | 請求内容を目視確認したい場合、例外処理が多い場合 |
Invoice Itemの構成
Invoiceはサブスクリプションの課金明細をInvoice Itemとして一覧で持ちます。1つのInvoiceに複数のInvoice Itemが含まれることが一般的です。
| Invoice Item | 内容 |
|---|---|
| Charge Item | Rate Plan Chargeごとの請求明細（月額費用・従量費用など） |
| Tax Item | 税額（Tax Integrationを使用している場合） |
| Discount Item | 割引チャージが適用された場合の明細 |
Standalone Invoice
通常のInvoiceはSubscriptionのBill Runから生成されますが、Standalone Invoiceを使うと、Subscriptionに紐づかない単独の請求書を手動で発行できます。
| 用途 | 例 |
|---|---|
| 単発の費用請求 | コンサルティング費、初期設定費 |
| Flat Fee型の一回請求 | ハードウェア販売、ライセンス一括払い |
Invoiceの出力形式 — 最終出力は常にPDF
顧客に届くInvoiceファイルの形式は、テンプレートの種類に関わらず常にPDFです。テンプレート自体の作り方には2種類あります。
| テンプレート形式 | 特徴 |
|---|---|
| HTMLテンプレート | 現在推奨されている方式。柔軟でカスタマイズ性が高い |
| Word Mail Merge テンプレート | 従来からある方式。Wordの差し込み印刷機能でレイアウトを作る |
Billing Document Template Configuration — 請求書のレイアウトを設計する
Billing Document Templateは、Invoice・Credit Memo・Debit Memoの見た目（レイアウト・自社ブランド・記載項目）を設計する機能です。テンプレートはHTMLまたはWordで作成し、Merge Field（差し込みフィールド）で実データを埋め込みます。テンプレートは商品単位ではなくAccount（顧客）単位で適用され、顧客ごとに異なるレイアウトを使い分けることもできます。
Merge Field ― データをテンプレートに差し込む仕組み
Merge Fieldは、{{Invoice.InvoiceNumber}} のように「オブジェクト.フィールド名」をドット区切りでつなぎ、二重中括弧で囲んだ記法です。テンプレートの種類ごとにルートオブジェクトが決まっています。
| テンプレートの種類 | ルートオブジェクト | 記述例 |
|---|---|---|
| Invoiceテンプレート | Invoice | {{Invoice.InvoiceNumber}} |
| Credit Memoテンプレート | CreditMemo | {{CreditMemo.CreditMemoNumber}} |
| Debit Memoテンプレート | DebitMemo | {{DebitMemo.DebitMemoNumber}} |
Merge Fieldは以下の3種類に分類されます。
| 種類 | 役割 |
|---|---|
| Variable（変数） | {{Invoice.Balance}} のように、値をそのまま置き換える最も基本的な差し込み |
| Section（セクション） | Invoice Item一覧のように、繰り返し表示される明細をループ処理する |
| Inverted Section | 条件が「該当しない」場合にだけ表示するブロック（IF文の否定条件） |
テンプレート設計前に検討すべき8つの要素
テンプレートを作り込む前に、businessは請求書に何をどこまで表示するかを以下の8つの観点で検討する必要があります。テンプレートは顧客が受け取る書類を標準化し、記載漏れによる請求ミスを防ぐ役割も持ちます。
| 要素 | 検討内容 |
|---|---|
| Branding（ブランディング） | どんな画像・ロゴ・文言・色・フォントを使うか |
| Subscription information（契約情報） | 使用サービスをサマリー表示にするか明細（itemized）表示にするか。合計金額のみか、One-time / Recurring / Usageで内訳を分けるか |
| Billing information（請求情報） | 請求日・支払期日・請求期間・延滞料発生日など、どこまで表示するか |
| Localization（ローカライズ） | 顧客が複数の地域にまたがる場合、日付形式・通貨・言語・数値形式ごとに異なるテンプレートを用意するか |
| Customer type information（顧客タイプ） | B2B/B2C、税免除/課税、一般顧客/エンタープライズ顧客など、顧客タイプごとにテンプレートを分けるか |
| Taxation information（税情報） | 製品に課税するか、顧客が免税対象か。課税する場合は明細ごとか合計のみか |
| Business units or subsidiaries（事業部・子会社） | 独自のブランディング・商品・チャージ・税要件を持つ子会社が複数あるか |
| Regulatory messages（規制対応メッセージ） | 政府等が定める規制文言を表示する必要があるか |
請求書デザインのベストプラクティス
| プラクティス | 内容 |
|---|---|
| 数値は右揃え | すべての数値項目を右揃えにすると読みやすくなる |
| 日付は国際標準フォーマットを使う | 「12/10/2018」のような表記は地域によって12月10日か10月12日か曖昧になる。「10-Dec-2018」のように月を文字表記にすると誤解を防げる |
| 通貨記号やISOコードを明記 | 顧客が現在1通貨のみ利用していても、通貨コード（例：USD）を記載しておくと、将来的に多通貨対応する際もテンプレートを作り直さずに済む |
| 明細が多くなる場合はサマリー形式にする | リセラー向け請求書や大量のUsageチャージがある場合は、明細をすべて載せず要約形式にし、詳細は別レポートで補足する |
Advanced Mail Merge機能（高度なカスタマイズ）
HTMLテンプレートでは、以下のような高度な差し込み機能も利用できます。
| 機能 | 内容 |
|---|---|
| Date and Number Format | 国ごとに異なる日付・数値フォーマットに対応（例：米国はmm/dd/yyyy、英国はdd/mm/yyyy） |
| Custom Fields | Account等のCustomフィールドの値をInvoiceに表示する |
| Sort Order of Invoices | Charge Number順やサービス開始日順など、明細の表示順を指定する |
| If Logic（条件分岐） | テンプレートの乱立を防ぐため、支払い方法やChargeの属性などに応じて条件付きで表示内容を切り替える |
| Previous Transaction Table | 過去の取引履歴を、あらかじめフィルタした順序で表示する |
| Barcodes | Invoiceテンプレートに最大5つまでバーコードを表示でき、スキャナーで読み取れる情報を埋め込める |
Default TemplateとCustom Templateの関係
Zuoraにはあらかじめ用意されたSystem Default Templateと、自社ブランドに合わせて作成するCustom Templateがあります。
| テンプレート | 特徴 |
|---|---|
| System Default Template | Zuoraが標準提供する最小限のレイアウト。カスタマイズは限定的 |
| Custom Template | 自社で新規作成・編集する独自レイアウト。HTML/Wordどちらでも作成可能 |
Custom Templateを作成しただけでは自動的には使われません。**Accountの「Default Template」として明示的に設定する（Zuora UIまたはAPI経由）**ことで、そのAccountに発行されるInvoice・Credit Memo・Debit Memoに適用されます。
HTMLテンプレートとWord Mail Mergeテンプレートの比較
| HTMLテンプレート | Word Mail Mergeテンプレート | |
|---|---|---|
| 作成方法 | HTML・CSS・JavaScript・画像を使って設計 | Wordの差し込み印刷機能でレイアウトを作成 |
| カスタマイズ性 | 高い（条件分岐・ループ・バーコード・多言語対応など） | 限定的 |
| 推奨度 | 現在の推奨方式 | 従来方式（新規テンプレートはHTML推奨） |
| 保存形式 | HTML | .doc形式のみ（.docx不可） |
| 最終出力 | どちらもPDF | どちらもPDF |
HTMLテンプレートでは、行・列・データテーブル・フォント・ページ設定・ヘッダーとフッター・バーコード・画像・JavaScriptなど、細かい要素を個別に構成できます。特に「Group By機能」を使うと、複数のInvoice Itemを商品カテゴリなどでグルーピングして表示するといった高度なレイアウトも組めます。
多言語対応（Multilingual Billing Document）
グローバル展開している企業向けに、1つのテンプレートから顧客ごとの言語でPDFを自動生成する機能があります。英語・ドイツ語・フランス語・スペイン語・中国語・アラビア語など、マルチバイト文字や右書き言語を含む幅広い言語に対応しています。
| 仕組み | 内容 |
|---|---|
| 翻訳の対象 | テキスト系のMerge Fieldのみ（数値・日付は対象外） |
| 言語の決定方法 | 顧客のCommunication Profileに設定されたLocale（地域設定） |
| 日付・数値のフォーマット | Localeに応じて自動的にフォーマットが変わる（翻訳ではなく書式変換） |
PDFの生成・再生成
Invoice・Credit Memo・Debit MemoのPDFは、Zuora画面上から生成・確認できます。3つの異なる操作(生成／自動再生成／手動再生成)を区別して押さえておく必要があります。
| 操作 | 手順 |
|---|---|
| ① 生成したPDFを表示する（Generating a billing document） | Invoiceページで View > Invoice PDF、Credit Memoページで View > Credit Memo PDF、Debit Memoページで View > Debit Memo PDF |
| ② 自動での再生成（Regenerating a billing document） | 表示内容が変わる操作（Invoiceコメントの編集、Invoice本体の編集、税情報の作成・更新、Adjustmentの作成、Paymentの作成、Refundの作成、SOAP APIでRegenerateInvoicePDFをTrueにしたUpdate()呼び出しなど）を行うと、ZuoraはPDFを自動的に再生成する |
| ③ 手動での再生成（Regenerating a billing document manually） | Invoiceページで More > Regenerate Invoice PDF、Credit Memoページで More > Regenerate Credit Memo PDF、Debit Memoページで More > Regenerate Debit Memo PDF から手動でも再生成できる |
請求書生成のタイミング
Invoice・Credit Memo・Debit Memoの生成は、Bill Runに伴う自動生成のほか、個別アカウント単位でのオンデマンド生成にも対応しています。
| 生成方法 | 用途 |
|---|---|
| Bill Run経由（自動） | 通常の月次請求サイクル |
| オンデマンド（個別アカウント） | 特定顧客への単発請求、テスト目的での確認 |
請求業務の実装ベストプラクティス
Zuoraを導入・運用する際は、以下の7つのベストプラクティスを押さえておくと、運用負荷を抑えつつ正確な請求業務を実現できます。
| プラクティス | 内容 |
|---|---|
| Automate posting invoices and notifications（Invoice PostとNotificationの自動化） | Bill Runを設定し、Invoiceを自動でPost・メール送信することで、運用負荷（operational overhead）を削減する |
| Schedule frequent bill runs（頻繁なBill Runのスケジューリング） | Bill Runを頻繁にスケジュールし、毎日Invoiceを生成することでキャッシュフローを改善する |
| Keep invoice templates as simple as possible（Invoiceテンプレートはできるだけシンプルに保つ） | 条件分岐・汎用フォーマット・Translation Profileを活用しながら、テンプレートをシンプルに保つことで長期的な保守コストを最小化する |
| Issue credits for future invoices（将来のInvoiceに向けたクレジット発行） | 過去のInvoiceに対してクレジットを適用するのではなく、将来のInvoiceに向けたサービス分のクレジットを発行する |
| Verify tax exempt status（免税ステータスの確認） | 顧客獲得フロー(customer acquisition flow)の中で免税ステータスを検証し、税務エラーやそれを是正するためのCredit/Debit Memo作成の必要性を最小化する |
| Use billing previews（Billing Previewの活用） | 注文獲得フロー(order acquisition flow)の中でBilling Previewを使用し、請求エラーやそれを是正するためのCredit/Debit Memo作成の必要性を最小化する |
| When possible, aggregate usage（可能な限りUsageを集約する） | 可能な場合は、Zuoraへロードする前に使用量を(時間単位・日単位などで)集約し、Bill Runの処理時間を最小化する |
Proration — 月途中の変更と日割り計算
SubscriptionをBCDの途中で変更すると、Zuoraは変更前後の差分を日割りで計算してInvoiceに反映します。Prorationは「公平な課金」を自動化するZuoraの中核機能の一つです。
Prorationとは
Prorationとは、請求期間の途中で料金が変わった場合に、残り日数に応じて料金を按分する仕組みです。たとえば月額3,000円のプランに月の途中から加入した場合、加入日から月末までの日数分だけを請求します。
月額 3,000円 ／ 31日 × 残り20日 ＝ 1,935円（Prorated金額）
Prorationが発生する主なタイミング
| 操作 | Prorationの内容 |
|---|---|
| 月途中でSubscriptionを新規作成 | 初回請求は残り日数分の日割り額になる |
| 月途中でUpgrade（プランアップ） | 差額の日割りがDebit Memo相当の追加請求になる |
| 月途中でDowngrade（プランダウン） | 過払い分の日割りがCredit Memoとして返金される |
| 月途中でSubscriptionをCancel | 残り期間分がCredit Memoとして生成される（Refund Policy設定に依存） |
Prorationが実務でどう表れるか — 2つの具体例
「月の途中で何かが起きたとき、次のInvoiceにどう反映されるか」を2つの典型例で整理します。
| ケース | シナリオ | 結果 |
|---|---|---|
| Partial Billing Period（部分請求期間） | 毎月1日始まりの月次Bill Cycleを持つビジネスに、顧客が15日に加入した | 次の請求サイクル開始時に生成されるInvoiceで、前月分の日割り（Prorated）期間分を反映する必要がある |
| Mid-Cycle Invoice Generation（サイクル途中の請求生成） | 顧客が請求期間の終了前にSubscriptionを解約した | ビジネスはAd-hoc Bill Runを作成するか、次のBill Runを待ってその変更をInvoiceに反映させる必要がある |
ProrationのOn/Off
Rate Plan ChargeにはProrationを有効にするかどうかの設定があります。
| 設定 | 動作 |
|---|---|
| Proration ON（デフォルト） | 月途中の変更を日割りで計算し、InvoiceまたはMemoに反映 |
| Proration OFF | 月途中の変更があっても、次のBCDまで現行料金で請求される |
Prorationモードの2種類
Zuoraには2つのProrationモードがあります。試験ではどちらが「日単位」かを問われることがあります。
| モード | 計算単位 | 特徴 |
|---|---|---|
| Full Proration（日割り） | 日単位 | 変更日から月末までの実日数で按分。最も一般的。 |
| No Proration | なし | Proration計算を行わない。ChargeレベルでProration OFFと同義。 |
日割り計算の設定（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つのチャージタイプがあります。
| チャージタイプ | 請求タイミング | 例 |
|---|---|---|
| Recurring | 定期的に自動生成（前払い・後払い両対応） | 月額サブスクリプション料金 |
| One-time | Subscription作成時または手動 | 初期設定費、ライセンス費 |
| Usage | 使用量データをロードしてから | API呼び出し回数、ストレージGB、通話分数 |
Usageチャージは、実際の使用量データがZuoraに存在してはじめて請求額が確定します。そのため、必ず**後払い（arrears）**になります。
Usage請求までの4ステップ
Usageを請求するまでには、以下の4つのステップが必要です。
| # | ステップ | 内容 |
|---|---|---|
| 1 | 使用量データの計測・集約 | 複数システムやサードパーティ、リセラーから使用量データを集計する |
| 2 | Zuoraへのロード | Spreadsheet（スプレッドシート）またはAPIで取り込む。APIが推奨方式で、自社の他システムからZuoraへの使用量データ取り込みを自動化できる。多くの企業はAPI経由でロードするためのユーザーインターフェースを自社で構築している |
| 3 | 監査 | 集約した使用量データが有効かつ正確であることを確認する |
| 4 | Bill Run実行 | Usageチャージを含むInvoiceを生成するBill Runを実行する |
Usage請求の2つの方式
請求期間内でのUsageの請求タイミングには、次の2つの方式があります。
| 方式 | 内容 |
|---|---|
| End of Billing Period（期間終了時に一括請求） | 請求期間中のすべての使用量を計測・計算し、期間終了時に請求する。たとえばBCDが毎月1日のアカウントの場合、1月1日〜1月31日の請求期間中の使用量は、期間終了時の2月1日に一括請求される |
| On-Demand（都度課金） | 請求期間中に複数回レーティングを行い、都度請求する（いわゆる「bill as you go」）。使用量をより頻繁にレーティングすることで、顧客はすでに発生した使用量を把握しやすくなり、企業側も製品・サービスの消費直後に請求できる。Per Unit PricingとTiered Pricingの2つのチャージモデルのみ対応 |
使用量データのロード方法
Zuoraにデータを登録する方法は2つだけです。
| 方法 | 向いているケース |
|---|---|
| CSV/Excelアップロード | 月次バッチなど、定期的に一括でデータを投入する場合 |
| API（Usage API） | システムから都度リアルタイムで使用量を連携する場合 |
Usageインポートのエラー通知
Usageファイルをロードした際、テンプレートの不一致などによりエラーが発生することがあります。エラーに気づけるよう、Notificationを設定しておくことが重要です。
| ステップ | 内容 |
|---|---|
| 1. 「Import Processed」通知の有効化 | Import Processed通知には**Completed（成功）とFailed（エラー）**の2つのステータスがあり、どちらもEmail通知として個別に有効化できる。デフォルトのEmailテンプレートがそれぞれ用意されている |
| 2. Email通知の内容を確認する | インポートが失敗すると「Import Notification: Failed」というメールが届く。メール本文にはImport ID・Import Status・Status Description（例：There are some invalid records in this import.）・試行件数（Total Records Attempted）・取込件数（Total Records Imported）が記載される |
| 3. Emailに記載されたリンクからテンプレートスプレッドシートを確認する | 失敗通知のメールには、エラー詳細が記載されたスプレッドシートへのリンク(For additional Import details, please visit:)が含まれている |
| 4. スプレッドシートの「Message」列でエラー内容を確認する | スプレッドシートには元のUsageデータの列(ACCOUNT_ID・UOM・QTY・STARTDATE・ENDDATE・SUBSCRIPTION_ID・CHARGE_ID・DESCRIPTIONなど)に加えて新しくMessage列が追加され、行ごとの具体的なエラー内容(例：The QTY is missing＝数量が未入力、日付形式が不正、AccountとSubscriptionの不整合など)が記録される |
Usageデータの必須項目
必須項目はAccount(Number)・UOM(単位)・Quantity(数量)・Start Date(開始日)の4つです。
| 項目 | 必須か | 役割 |
|---|---|---|
| Account Number | 必須 | どの顧客の使用量かを指定する |
| UOM（単位） | 必須 | Chargeに設定されているUOMと一致させる必要がある |
| Quantity | 必須 | 使用量の数値 |
| Start Date | 必須 | どのInvoice期間にこの使用量を計上するかを決める唯一の日付 |
| End Date | 任意 | 記録用の情報。請求期間の判定には使われない |
| Subscription Number / Charge Number | 任意 | 指定すると特定の契約・チャージにだけ紐づく |
Usage運用のベストプラクティス
Usageを扱う際は、Chargeの設定方法と日付の入力方法について、以下のベストプラクティスを押さえておく必要があります。
同じUOMを持つChargeの扱い（Charges With the Same UOM）
- 同じUOMを持つ2つのChargeが存在する場合、UsageレコードにはSubscription NumberまたはCharge Numberを必ず入力する必要があります
- Subscription NumberまたはCharge Numberが入力されていない場合、その数量は両方のChargeに対して請求され、結果として使用量が二重に請求されてしまう可能性があります
- ビジネスによっては、同じUOMを持つ2つのChargeを意図的に使い、一方をプラスの金額、もう一方をマイナスの金額として設定するケースがあります。この場合、計算されるUsage Chargeの合計額は割引された金額になります
日付フォーマットのローカライズ（Localization of the Date Format）
- USAGE(STARTDATE・ENDDATE)に使われる日付フォーマットは、現在のユーザーのlocale（地域設定）に依存します
- このフォーマットはZuoraテナントに設定されたlocaleでは制御されません。あくまでデータをロードするユーザー個人のlocale設定が基準になります
- 例えば、あるユーザーのlocaleがEnglish(United Kingdom)またはEnglish(Australia)に設定されている場合、日付フォーマットはMM/DD/YYYYになります
Usageのレーティンググループ（Mediation and Aggregation）
Rate Plan Chargeを作成する際、Usageレコードをどうグルーピングしてレーティングするかを4つの選択肢から指定できます。
| Rating Group | グルーピングの単位 |
|---|---|
| By Billing Period | 同じ請求期間内のUsageレコードをまとめて1グループとして扱う |
| By Usage Start Date | Usageレコードの開始日が同じものを1グループとして扱う |
| By Usage Record | Usageレコード1件ごとに個別のグループとして扱う |
| By Usage Upload | 同じアップロードファイル単位でグループ化する |
子アカウントのUsage集計（Account Hierarchy）
Account Hierarchyを利用している場合、子アカウントの使用量を親アカウントにまとめて請求することもできます。
| # | ステップ | 内容 |
|---|---|---|
| 1 | 親アカウントがサービスを契約 | 親アカウントがサービスを契約し、自身のAccountでSubscriptionを維持する |
| 2 | 子アカウントが使用 | この親アカウントに属するすべての子アカウントがそのサービスを使用し、Usageレコードには子アカウントのアカウント識別情報（Account Number）が記録される |
| 3 | Zuoraがリンク | Zuoraは子アカウントのUsageレコードを、一致するUOMを持つSubscriptionを保有する親アカウントにリンクする |
| 4 | 親アカウントでレーティング・請求 | Zuoraは親アカウントからUsageレコードをレーティング・請求する。親アカウントが一致するUOMを持つ複数のSubscriptionを保有している場合、Usageレコードは親アカウント内のすべてのSubscriptionにわたってレーティングされる |
On Demand請求 — ロード直後に請求したい場合
通常のBill Runは毎日夜間バッチで実行されますが、使用量データをロードした翌日のBill Runまで待てないケースもあります。たとえば、解約後すぐに最後の使用量を請求したい場合などです。
Zuoraでは、使用量データをロードした後にOn Demand Bill Runを実行することで、通常のBCDサイクルを待たずに請求書を発行できます。
RecurringのIn Arrearsとの違い
| Recurring（In Arrears） | Usage | |
|---|---|---|
| 請求額の決まり方 | 料金プランで固定（例：月額100ドル） | 実際の使用量 × 単価で計算 |
| データロードの要否 | 不要（自動） | 必要（手動またはAPI） |
| 請求タイミング | BCDに従い自動 | データロード後の次のBill Run |
| 「後払い」の意味 | 当月サービス提供後に翌月請求 | 使用量データを受け取ってから請求 |
Credit / Debit Memo — 調整の業務パターン
Invoiceを発行した後に金額を修正したいとき、Zuoraは元のInvoiceを直接書き換えません。Credit MemoとDebit Memoという専用オブジェクトで差分を記録し、会計上の正確な証跡を残します。
なぜInvoiceを修正しないのか
PostedになったInvoiceは直接編集できません。理由は監査証跡（Audit Trail）の保全です。企業会計では「一度確定した請求書は変更してはならない」という原則があり、Zuoraはこれを設計に反映しています。
Credit Memo と Debit Memo
| オブジェクト | 用途 | 方向 |
|---|---|---|
| Credit Memo | 顧客への返金・減額 | Zuora → 顧客（マイナス調整） |
| Debit Memo | 顧客への追加請求 | 顧客 → Zuora（プラス調整） |
Credit MemoとDebit Memoの3つの分類
| 分類 | 内容 |
|---|---|
| 特定のInvoiceを参照するMemo（Refer to specific invoices） | 既存Invoiceの特定項目を調整するために作成する。値引きなど、Memo Itemが対応するInvoice Itemを参照する |
| スタンドアローンMemo（Standalone） | 特定のInvoiceに紐づかないアドホックな請求・クレジット。延滞料やサービス障害補償など。Rate Plan Chargeを参照するがSubscriptionへの紐付けは不要で、正の残高を持つInvoiceやDebit Memoに充当できる |
| Bill Runにより自動生成されるCredit Memo（Credit Memos generated by bill run） | マイナスの請求書を作る代わりに、Bill RunがCredit Memoとして自動生成する（詳細は後述）。Rating処理の結果として生じたマイナスのCharge Eventすべてを、その内容ごとCredit Memoに反映する。負の請求・残高を直接Credit Memoとして生成する方が、売掛金（Accounts Receivable）の消し込み・管理がしやすくなる |
スタンドアローンMemo
Credit Memoの用途と使えるケース
| 用途 | 具体例 |
|---|---|
| 過請求の修正 | 料金プランの誤設定で高く請求してしまった |
| 解約返金（Refund） | 解約時に残期間分を払い戻す |
| サービス障害補償 | SLA違反に対するサービスクレジット付与 |
| Invoice Cancel | InvoiceをCancelすると自動でCredit Memoが生成される |
| Write-off（不良債権償却） | 回収不能な残高を貸倒処理する際にCredit Memoを活用 |
Credit/Debit Memoが生成される主な状況（一覧）
| Credit Memoを手動作成する状況 | Debit Memoを手動作成する状況 |
|---|---|
| 過請求などの請求書エラー修正 | 過少請求などの請求書エラー修正 |
| 返金せずにアカウントへクレジット付与 | オープンなCredit Memoを消し込む（Offset） |
| アドホックな値引き | 税金分のDebit Memo |
| クレーム対応（値引き・減額） | アドホックな追加請求（延滞料や解約手数料など） |
| パートナーへのリベート | Subscriptionに含まれない追加請求 |
| サービス障害によるSLAクレジット | ― |
| Credit Memoが自動生成される状況 | Debit Memoが自動生成される状況 |
|---|---|
| 契約途中のダウングレード | なし（Debit Memoは自動生成されない） |
| 契約期間中の早期解約 | ― |
ネットネガティブ請求時のCredit Memo自動生成
「Credit Memo for negative invoice」の設定を有効にすると、Bill RunはChargeをグループ化し、グループ合計がマイナスならCredit Memo、プラスなら通常のInvoiceを生成します。グルーピングの有無によって、Credit Memoの作られ方が変わります。
チャージグルーピングあり（ChargeNumberごとにグループ化）
Chargeをそのチャージ番号ごとにグループ化した上で、グループ単位で合計の符号を判定します。たとえば、Charge Aが-$15/月、Charge Bが$10/月の2チャージを持つAnnual Rate Planで、1〜3月分（3ヶ月）を対象にBill Runを実行すると、以下のように処理されます。
| チャージグループ | 合計金額 | 生成される書類 |
|---|---|---|
| Charge Aグループ | -$15 × 3 = -$45 | Credit Memo |
| Charge Bグループ | $10 × 3 = $30 | Invoice |
同様に、既存のチャージに後からマイナスの調整チャージ（値下げなど）が追加された場合も、そのグループの合計がマイナスであれば、その分は別のBill Runで処理された際にCredit Memoとして生成されます。
具体例（契約途中の値下げでCredit Memoが生成されるケース）： 1月1日開始・1年契約の月額$100のRecurring Charge（Charge A）1本だけを持つSubscriptionに、1月20日、Target Dateが5月31日のBill Runが実行され、Jan〜Mayの5ヶ月分（$500）でDraft Invoiceが作成されたとします。その後3月1日に「-$50/月」の値下げチャージが追加され（3月・4月・5月分に適用）、5月31日をTarget DateとするBill Runが再実行されると、このBill Runで新たに処理される対象はChargeグループ内の-$50×3ヶ月分=-$150だけになります。Charge Aは1つのチャージグループしか持たないため、そのグループ合計がマイナス（-$150）であれば、Credit Memoが1件生成され、そのグループに含まれるすべてのChargeがCredit Memo内に表示されます。
チャージグルーピングなし（全チャージを1つとして合算）
一方、チャージグルーピングを行わない設定では、対象アカウントのすべてのチャージ（税込み）を1つにまとめて合計し、その合計がマイナスであればCredit Memo 1枚だけが生成されます。個々のチャージごとにInvoiceとCredit Memoへ振り分けられることはありません。
たとえば、Charge Aが$200/月（税抜き）、Charge Bが-$201/月（税抜き）の2チャージを持つAnnual Rate Planで、1月分を対象にBill Runを実行すると、以下のようにすべてのチャージがまとめて1件のCredit Memoになります。
| 項目 | 金額 |
|---|---|
| Charge A Credit Memo item（税別） | -$200（税 -$20） |
| Charge B Credit Memo item（税別） | +$200（税 +$20） |
| Credit Memoの合計金額 | $1.1（チャージ差額 $1 ＋ 税差額 $0.1） |
Credit Memoの残高を使う — Unapplied Balance
Credit Memoは発行しただけでは現金の動きになりません。以下の2つの使い道があります。
| 使い道 | 説明 |
|---|---|
| 次のInvoiceに充当（Apply） | 翌月請求書からCredit Memo残高を差し引く |
| Refund（返金） | 銀行振込などで現金を顧客に戻す |
充当していない残高は「Unapplied Credit Memo Balance」として顧客のAccountに残り続けます。
Credit Memo → Refundの処理フロー
| ステップ | 操作 |
|---|---|
| 1. Credit Memoを確認 | UnappliedなCredit Memoが対象アカウントに存在することを確認 |
| 2. Refundを作成 | Credit MemoからRefundを生成。金額・Payment Methodを指定 |
| 3. Gateway処理 | ElectronicはPayment Gateway経由で自動処理、ExternalはZuora外で手動処理 |
| 4. Refund確定 | RefundステータスがProcessedになれば完了 |
Auto-Apply設定
| 設定 | 動作 |
|---|---|
| Auto-Apply ON | Bill Run実行後、対象アカウントの未充当Credit Memo残高が新しいInvoiceに自動で差し引かれる |
| Auto-Apply OFF | 担当者が手動でCredit MemoをInvoiceに充当する必要がある |
Credit/Debit MemoとData Modelの関係
Credit MemoとDebit Memoは、いずれもAccount（Customer Account）オブジェクトを起点に、Invoice・Order・Subscriptionなどと関連づけられています。Credit Memo Item / Debit Memo Itemはそれぞれ対応するTax Item（CreditMemoTaxItems / DebitMemoTaxItems）も保持しており、Invoiceと同様の明細構造を持ちます。
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）とは別画面である点に注意してください。