概要

Customer Accountは、Zuoraにおける請求のすべての起点です。誰に・どこへ・何通貨で・いつ・どんな形式で請求するかという意思決定が、すべてAccountの設計に集約されています。

通貨など「作成後に変更できない属性」があるため、設計フェーズでの意思決定が重要
Bill To / Sold Toの2つのコンタクトがそれぞれ異なる役割を持つ
Account階層・カスタムフィールドで複雑なビジネス要件にも対応できる

なぜAccountが「主語」なのか

ZuoraにはSubscription（契約）・Invoice（請求書）・Payment（支払い）など多くのオブジェクトが存在します。しかし、これらすべての起点となるのがCustomer Accountです。

Subscriptionを作るにも、InvoiceをRunするにも、「誰への請求か」が確定していなければ動き出せません。Accountは請求システム全体の主語です。

Customer Account
  └── Subscription（どんな契約か）
        └── Invoice（いくら請求するか）
              └── Payment（どう払うか）

逆にいうと、Accountに設定した属性（通貨・支払い条件・請求テンプレートなど）が、そのアカウントに紐づくすべてのInvoiceやPaymentの振る舞いを決めます。**「Accountを設計する＝そのお客さんへの請求を設計する」**と言っても過言ではありません。

Accountに何が入っているか ― 請求を決める属性たち

Accountには多くのフィールドがありますが、特に重要なのは「作成後に変更できない、または変更すると請求全体に影響する属性」です。

設計フェーズでの意思決定が後から響いてくるため、慎重に決める必要があります。

属性	役割	変更の難易度
Currency（通貨）	そのAccountに発行されるすべてのInvoiceの通貨	❌ 作成後変更不可
Payment Terms（支払い条件）	InvoiceのDue Date（支払い期限）を決める（例：Net 15 = 請求日から15日後）	⚠️ 変更すると以降の全Invoiceに影響
Invoice Template	請求書のレイアウト・デザイン	✅ 後から変更・追加可能
Batch	請求処理をまとめてRunするためのグループ分け（例：Batch1=国内顧客、Batch2=海外顧客）	✅ 後から変更可能
Auto Pay	請求書が確定したとき自動で決済処理するかどうか	✅ 後から変更可能

特にCurrencyは一度Accountを作ると変更できません。「日本円で作ったAccountを後からドルに変えたい」という要望はよくありますが、Zuoraはそれを許可していません。通貨が変わる場合は新しいAccountを作り直す必要があります。

Payment Termsは「Net 〇〇」という形式で表現します。 Net 15であれば「請求日から15日後が支払い期限」、Net 30であれば「30日後」です。このTermsはAccountレベルで設定しますが、Flexible Billing Attributes機能を使えばSubscriptionレベルで上書きすることもできます。

Bill To / Sold To ― 2つのコンタクトの役割分担

Accountには「誰に請求するか」を表すコンタクト情報が2種類あります。

コンタクト	役割
Bill To Contact	請求書の送付先。Invoiceのあて名・メール送信先になる
Sold To Contact	商品・サービスの届け先。税計算の基準住所として使われる

この2つが分かれている理由は、「請求書を受け取る人」と「実際にサービスを使う場所」が異なるケースが存在するからです。

たとえば、本社の経理部門が請求書を受け取るが、サービスの利用拠点は地方の支社、というケースです。この場合、税率は「サービスが届く場所（Sold To）」の住所で計算されます。日本国内だけを見ると税率は一律ですが、グローバル展開しているビジネスでは国や州によって税率が大きく異なるため、Sold Toの住所精度が税計算の正確さを左右します。

Bill To Contact  →  請求書の宛名・送付先メールアドレス
Sold To Contact  →  税率計算の基準（どの国・州に届けているか）

AccountとContactの関係

Accountそのものには企業名・プロジェクト名・個人名など「請求の単位の名前」が入ります。Bill To / Sold To ContactはそのAccountに紐づく「人」の情報です。

Account（例：株式会社〇〇）
  ├── Bill To Contact（例：経理部 田中太郎）
  └── Sold To Contact（例：東京支社 鈴木花子）

B2Bであれば企業名・プロジェクト名、B2Cであれば個人名がAccountに入ることもあります。「請求の単位に名前をつけたもの」と考えると分かりやすいです。

Account階層 ― 組織の複雑さをどう表現するか

現実のビジネスでは、1つの企業が複数の子会社・部門・拠点を持つことが当たり前です。ZuoraのAccount階層（Parent-Child）はその複雑さをそのまま表現するための仕組みです。

Zuoraが想定するAccount階層の用途は主に2つです。

ユースケース	内容
組織整理	親会社と子会社、本社と支社など、ビジネス上の関係をZuora内で可視化する
Usage集約	子AccountのUsage（従量課金の利用量）を親Accountに集めて、まとめて請求する

階層は何段でも作れます。子AccountがさらにParentになれるため、大規模な企業グループの構造もそのまま表現できます。

Prospect・Lead・Customer ― 誰をいつZuoraに入れるか

ZuoraのAccountは「請求が発生する相手」を管理するための仕組みです。まだ契約していない見込み顧客をZuoraに入れるべきかどうかは、用途と目的によって判断が変わります。

Zuoraのドキュメントでは、顧客になる前の段階を以下のように整理しています。

区分	説明	Zuoraに入れるべきか
Prospect（見込み顧客）	まだ契約していないが、無料トライアルなどでサービスを試している	条件付きでYes
Lead（リード）	興味はあるが具体的なアクションはまだ	基本的にNo
Customer（顧客）	契約・課金が発生している	Yes

LeadやProspectの情報はCRM（SalesforceなどのCustomer Relationship Managementツール）で管理するのが基本です。 ZuoraはあくまでBilling（請求）のシステムであり、見込み顧客のデータで埋め尽くすと請求データの品質が下がります。

無料トライアルについては、以下の2パターンで対応が分かれます。

カスタムフィールド ― Accountに独自情報を持たせる

ZuoraはAccountをはじめ、Subscription・Invoice・Productなど主要なオブジェクトに対して、独自のフィールドを追加できます。これがカスタムフィールドです。

Zuoraが標準で用意しているフィールド（Account名・通貨・支払い条件など）だけでは、自社のビジネス固有の情報を持ちきれないことがあります。たとえば：

社内の顧客管理番号をZuoraのAccountに持たせたい
営業担当者のIDを紐づけておきたい
契約の種別（直販／代理店経由）をフラグで管理したい

こういったケースでカスタムフィールドを使います。

特徴	内容
定義場所	Zuoraの管理画面（テナント設定）で追加する
対象オブジェクト	Account・Subscription・Product・Invoiceなど主要オブジェクト全般
UI表示	追加したフィールドはZuoraのUI上にも表示される
API経由	REST API・SOAP APIどちらからも読み書き可能

まとめ

Customer Accountは、Zuoraにおける請求のすべての起点です。導入プロジェクトの初期段階で、ビジネス側と一緒にAccountの設計を確定させることが、Zuora導入成功の第一歩です。

テーマ	要点
Accountの役割	Subscription・Invoice・Paymentすべての起点。Accountなしに請求は動かない
変更できない属性	通貨（Currency）は作成後に変更不可。設計フェーズで確定させる
2つのコンタクト	Bill Toは請求書の送付先、Sold Toは税計算の基準住所
Account階層	組織整理とUsage集約の2つの用途。必要なときだけ使う
誰をいつ入れるか	LeadはCRMで管理。Zuoraに入れるのは課金が発生するタイミングから
カスタムフィールド	独自のビジネス情報をAccountに持たせる手段。設計は慎重に

Accountの設計ミスは、後から修正するコストが非常に高くつきます。特に通貨や階層構造は「動き始めてから変えたい」となっても簡単には変えられません。