概要
ZuoraはサブスクリプションのすべてのトランザクションをAccounting Codeで勘定科目に紐づけ、仕訳を自動生成します。ERPの補助元帳として機能し、経理クローズ作業を設計・運用できるようになります。
会計の基礎用語（Zuora University定義）
Zuora Universityでは会計の基本を、資産・負債・純資産・収益・費用・純利益・取引・借方・貸方という用語で整理しています。試験ではこれらの英語の定義がそのまま問われるため、日本語の意味だけでなく定義の言い回しごと押さえておきます。
| 用語 | 定義 |
|---|---|
| Assets（資産） | 購入・取得したが、まだ消費されていないもの。例：売掛金（Accounts Receivable）、棚卸資産（Inventory） |
| Liabilities（負債） | 後で支払う義務がある財務上の債務。例：買掛金（Accounts Payable）、借入金（Loans Payable） |
| Equity（純資産） | 資産から負債を差し引いた後に残る金額。事業オーナーの持分（Ownership Interest）を表す |
| Revenue（収益） | 商品・サービスの提供に対して顧客から受け取る金額の総額。次の3種類に分類される |
| Expenses（費用） | 測定期間中に消費された資産の金額・数量。例：給与（Wages）、オフィス賃料（Rent） |
| Income（純利益） | 収益から費用を差し引いた後に残るもの。Income = Revenue − Expenses |
| Transaction（取引） | 財務諸表に金銭的な影響を与えるビジネス上の出来事で、会計記録に記帳される |
| Debit（借方） | 次の2通りの見方がある会計上の記帳操作 |
| Credit（貸方） | 次の3通りの見方がある会計上の記帳操作 |
Revenueの3分類
| 種類 | 内容 |
|---|---|
| Deferred revenue（前受収益） | 将来提供する予定の商品・サービスに対して、前もって集めた金銭 |
| Recognized revenue（認識済み収益） | すでに提供が完了した商品・サービスに対する金銭 |
| Cash（現金） | 他の債権とあわせて収益の構成要素になり得るもの |
Income（純利益）とProfit Margin（利益率）
Income（純利益）はRevenue（収益・売上）そのものとは異なる概念です。 収益から費用（税金を含む）を差し引いた後に残る「手取り」を指します。
Income = Revenue − Expenses
Incomeを収益に対する割合（パーセンテージ）で表したものが**Profit Margin（利益率）**と呼ばれます。
Transaction（取引）の例
Transactionは会計記録に記帳されるビジネス上の出来事です。代表例は次の4つです。
- 顧客へ商品・サービス提供分の請求書を発行する
- 顧客が抱える請求書に対して現金の支払いを受け取る
- クレジットカードで顧客に売上を計上する
- 不満を持つ顧客にクレジット（返金相当額）を発行する
Debit（借方）の2つの見方
Debitは次の2通りの視点で説明されます。
- 貸借対照表上の会計エントリ：資産の増加、または負債の減少をもたらす仕訳
- 収益・費用を記録する方法：現金で代金を受け取った場合は現金勘定をDebit（増加）し、賃料などの費用が発生した場合は費用勘定をDebit（使える金額を減少）する
Credit（貸方）の3つの見方
Creditは次の3通りの視点で説明されます。
- 貸借対照表上の会計エントリ：資産の減少、または負債・純資産の増加をもたらす仕訳
- 個人の家計における契約上の合意：借り手が価値あるものを受け取り、将来利息付きで貸し手に返済することに同意する契約。例：クレジットカードで買い物をした場合、そのカードは「後で代金を支払う」というカード発行会社との合意を表す
- 個人・企業の借入余力（Borrowing Capacity）：たとえば住宅など高額な買い物をする際、売り手側の銀行が「ローンを返済できる余力があるか」を確認したいときに使う意味でのCredit
会計処理の方法 — Cash AccountingとAccrual Accounting
収益・費用をいつ記録するかには、Cash Accounting（現金主義）とAccrual Accounting（発生主義）の2つの方法があります。米国会計基準（US GAAP）に準拠する企業はAccrual Accountingを採用する必要があり、Zuoraの収益認識機能もこの発生主義を前提に設計されています。
| 方式 | 収益・費用を記録するタイミング | 例 |
|---|---|---|
| Cash Accounting（現金主義） | 現金を受け取った時に収益を、現金を支払った時に費用を記録する | カメラとフォトエディットサービスの月額サブスクリプションを同時購入した場合、カメラ代金は支払った瞬間に費用として計上される（実際の配送日は関係ない） |
| Accrual Accounting（発生主義） | 請求書の受領日や現金の授受日ではなく、サービスが実際に提供された時点で収益・費用を記録する | 月次の監査サービスに加入し、月初に料金を支払っても、収益は実際にサービスが提供される毎月15日に計上される。この方式では、Invoiceを一定間隔で自動生成し、月次・日次・カスタムスケジュールで収益を認識できる |
会計の基本 — 複式簿記と収益認識
複式簿記では借方と貸方が常に一致し、前払いを受けてもサービス提供分だけを売上として認識します。サブスクリプションビジネスでは前受収益の管理が会計の核心です。
複式簿記のしくみ
すべての取引を「お金がどこから来たか（貸方）」と「どこへ行ったか（借方）」の2つの側面で記録します。左右の金額は常に一致します。
| 取引例 | 借方（左） | 貸方（右） |
|---|---|---|
| 請求書を発行した | 売掛金（もらう権利が増えた） | 売上（収益が発生した） |
| 入金があった | 現金（手元に入った） | 売掛金（権利が消えた） |
| 前払いを受けた | 現金（手元に入った） | 前受収益（まだ売上にできない） |
会計等式：
資産（Assets）= 負債（Liabilities）+ 純資産（Equity）
この等式が常に成立していることが「帳簿が正しい」状態です。Zuoraエンジニアとして押さえておくポイントは「借方と貸方が常にバランスしている」ことだけで十分です。
資産評価の方法 — Fair Value Method
資産と負債をどの価格で評価するかには複数の方法があります。試験では**Fair Value Method（公正価値法）**の定義が問われます。
| 評価方法 | 定義 |
|---|---|
| Fair Value Method（公正価値法） | 資産・負債を**現在の市場価値（Current Market Value）**で評価・報告する手法 |
| Historical Cost（取得原価法） | 購入当時の価格（原価）で評価する手法 |
サブスクリプションの収益認識
「お金をもらった時に売上計上する」のではなく、**「サービスを提供した時に売上計上する」**のが会計のルールです（収益認識原則）。
収益認識の2条件 — Realized or RealizableとEarned
ある取引の収益を認識するには、次の2つの条件を両方とも満たしている必要があります。
| 条件 | 内容 |
|---|---|
| Realized or Realizable（実現している、または実現可能） | 商品・サービスの販売から生じた実際の利益・損失であること |
| Earned（獲得済み） | 対象の商品・サービスが顧客に提供済みであるか、サービスの提供が完全に完了していること |
GAAPが求める収益認識の4基準
US GAAPの下で収益を認識するには、次の4つの基準を満たす必要があります。
| 基準 | 内容 | 例 |
|---|---|---|
| Persuasive Evidence（説得力のある証拠） | 顧客との間に正式・非正式な合意があり、顧客が対価を支払う意思・同意を示す明確な証拠があること | 顧客が会計ソフトのサブスクリプションに申し込む |
| Delivery（提供） | 合意した商品・サービスを提供して初めて、それに紐づく収益を認識できる | 顧客に会計ソフトへのアクセス権限が付与される |
| Fixed/Determinable Price（確定または算定可能な価格） | 顧客に提供する商品・サービスについて、固定または算定可能な価格が定められていること | サインアップ時に月額120ドルの利用料で合意する |
| Collection（回収の見込み） | 回収が合理的に見込まれる限り、企業は回収より前に収益を計上できる | 有効な支払い方法情報を収集する、または与信チェックを行う |
12万円の年間前払いを受けた場合：
| タイミング | 前受収益残高 | 売上計上額 |
|---|---|---|
| 契約時（前払い受領） | 120,000円 | 0円 |
| 1ヶ月目 | 110,000円 | 10,000円 |
| 毎月 | 10,000円ずつ減少 | 10,000円ずつ増加 |
| 12ヶ月目 | 0円 | 10,000円 |
Deferred RevenueとAccrued Revenue — 請求と提供のズレの向き
収益は「提供が完了した期間」に記録されますが、請求書発行・入金のタイミングとのズレの向きによって、次の2種類に分類されます。
| 種類 | 発生条件 | 例 |
|---|---|---|
| Deferred Revenue（前受収益） | サービス・商品を請求または前払いで受領したが、提供はこれから行われる場合。最初は全額をDeferred Revenueとして分類し、提供が完了するたびに収益として認識していく | ソフトウェアベンダーが数ヶ月分の利用料を前払いで受け取り、月ごとに該当分だけ収益認識する |
| Accrued Revenue（未収収益） | 商品・サービスの提供が完了した後に、請求または入金が行われる場合。請求・入金より前に、すでに価値が「Accrue（発生・蓄積）」している状態 | プロジェクト完了時や特定のマイルストーン日にまとめて請求するサービス業で、請求が数ヶ月遅れることがある |
Accounting Code — 勘定科目マッピングの設計
Accounting CodeはProduct Rate Plan Chargeに設定し、InvoiceやPaymentが発生するたびに仕訳を自動生成します。ERPの勘定科目体系と合わせて設計します。
Zuora管理者がFinance関連で設定する項目は、主に次の3つに整理できます。
| 設定項目 | 内容の例 |
|---|---|
| Manage Custom Fields | Zuoraにデフォルトで用意されていない、自社独自のカスタムフィールドを作成する |
| Configure Accounting Codes | 外部の会計システムと連携する際に、収益をより適切に管理できるようAccounting Codeを設定する |
| Manage Revenue Recognition Models | 自社が収益認識に使いたいモデル（Revenue Recognition Model）を管理する |
Chart of Accounts（マスターテーブル）
導入時にまずChart of Accountsを作成します。これがZuoraの勘定科目マスターです。
| フィールド | 内容 | 例 |
|---|---|---|
| Accounting Code名 | Zuora内での識別名 | Revenue_SaaS |
| Type | 勘定科目の種類 | Revenue / Deferred Revenue / Accounts Receivable / Cash 等 |
| GL Account Number | ERPの勘定科目番号（任意） | 4001 |
| GL Account Name | ERPの勘定科目名（任意） | 売上高_SaaS |
Accounting Codeの設定場所
| 設定場所 | 設定するAccounting Code | タイミング |
|---|---|---|
| Product Rate Plan Charge | 売上（Revenue）・前受収益（Deferred Revenue） | 商品設定時 |
| Payment Method / Gateway | 現金（Cash）・クリアリング口座 | 支払い設定時 |
| Discount | 値引き（Discount） | 割引設定時 |
| Tax | 税（Tax Payable） | 税設定時 |
支払い方法ごとに異なる現金コードを設定できます。
| 支払い方法 | Accounting Code例 |
|---|---|
| クレジットカード | Credit_Card_Clearing |
| 口座振替（ACH） | Bank_Account_JPY |
| 現金 | Cash |
Accounting Codeの追加方法
Chart of Accountsの画面から新しいAccounting Codeを追加します。
Finance Settings → Manage Chart of Accounts → New Accounting Code、と進んで名前・Typeなどを入力し作成します。一度作成したAccounting Codeは削除できません。
Accounting Codeは変更してよいか
すでに使っているAccounting Codeも変更できますが、過去の取引には反映されません。
- 名前（Name）は、一度でも取引で使われた後は変更できません
- Product Rate Plan Chargeなどへの割り当てを変更した場合、それ以降に発生する新しい取引にのみ新しいコードが使われます。すでに確定した過去のInvoiceやPaymentは古いコードのまま残ります
トランザクションごとの仕訳自動生成
| トランザクション | 借方 | 貸方 |
|---|---|---|
| Invoice生成 | 売掛金（AR） | 売上 または 前受収益 |
| Payment受領 | 現金（Cash） | 売掛金（AR） |
| Credit Memo発行 | 売上（Revenue） | 売掛金（AR） |
Zuora Finance Accounting Rules — 会計処理の詳細設定
Finance Settings画面のAccounting Rulesでは、Accounting Codeの必須化・クローズ済み期間への例外的な操作・通貨をまたぐJournal Runの集計方法などを、Yes/Noのトグルで細かく制御できます。デフォルトではほとんどの項目がNo（厳格な運用）に設定されています。
| ルール | Yesにした場合の動き | デフォルト |
|---|---|---|
| Allow blank Accounting Codes | Accounting Codeを設定しなくても取引を記録できる。Noにすると、支払い・返金などの取引やProduct Rate Plan ChargeでAccounting Codeの設定が必須になる | Yes |
| Allow Subscription and Amendments to be created in a closed Accounting Period | クローズ済みの会計期間に遡ってSubscriptionやAmendmentを作成できる（バックデート）。ただし、そこから生成されるInvoiceは、実際には最も早い「Open」の会計期間に計上される | Yes |
| Allow Usage to be created in a closed Accounting Period | クローズ済みの会計期間に属する使用量（Usage）レコードを作成・削除できる。この場合もレーティング・請求は最も早いOpenの会計期間で行われる | No |
| Allow Revenue Schedules to have negative amounts in the Open-Ended Accounting Period | Revenue Scheduleの配分額がスケジュール総額を超えることを許可し、結果としてOpen-Ended会計期間にマイナスの収益額が生じることを許容する。Downgradeなどの契約変更でも発生し得る | No |
| Aggregate transactions with different currencies during a Journal Run | Journal Run実行時に、異なる通貨の取引をまとめて1つのサマリー仕訳に集約する。Noの場合は通貨ごとに別々のサマリー仕訳が生成される | No |
| Use Cash Account for Unapplied Payment Transfer Accounting? | Unapplied Payment（未消込の入金）を別の顧客アカウントへ振替する際、Cash勘定をUnapplied Payment勘定への相殺（オフセット）として使う仕訳を生成する。Noの場合は振替元・振替先の両アカウントに対してUnapplied Payment勘定へのCredit／Debitのみが記録される | No |
Journal Entry — 仕訳オブジェクトの原理
ZuoraはInvoice・Payment・Credit Memoなどのトランザクションが確定するたびに、Journal Entry（JE）オブジェクトを自動生成します。JEがERPへ転記されることで、Zuoraはサブレジャーとして機能します。
ビジネス取引が記帳されるまでの3ステップ
Zuora特有の話に入る前に、一般的な会計処理として「取引が発生してから記帳されるまで」の流れを押さえておきます。
| ステップ | 内容 |
|---|---|
| ① 取引の精査 | 発生した取引を確認し、どの勘定科目が影響を受けるかを判断する |
| ② 借方・貸方の決定 | どの勘定科目をDebit（借方）にし、どの勘定科目をCredit（貸方）にするかを決める |
| ③ Journal Entryへの記帳 | 実際に取引をJournal Entry（仕訳）として記録する |
Journal Entryとは
Journal Entry（JE）はZuora内部の仕訳レコードです。「いつ・どのトランザクションで・どの勘定科目に・いくら動いたか」を記録します。
| フィールド | 内容 | 例 |
|---|---|---|
| Journal Entry Date | 仕訳の発生日 | Invoice生成日、Payment受領日 |
| Accounting Period | 帰属する会計期間 | 2025-06 |
| Status | 転記状態 | Created / Transferred |
| Journal Entry Items | 借方・貸方の明細行 | AR Dr. 10,000 / Revenue Cr. 10,000 |
| Source | 元になったオブジェクト | Invoice / Payment / Credit Memo 等 |
JEのStatus — CreatedとTransferred
| ステータス | 意味 |
|---|---|
| Created | Zuora内にJEが生成されたが、まだERPに転記されていない |
| Transferred | ERPへの転記が完了した（エクスポートジョブ実行後に更新される） |
JEが生成されるタイミング
Journal Run — サマリー仕訳のERPエクスポート
個々のトランザクションから生成されるJEはZuora内の詳細な明細レコードです。これをERPに取り込む際は、Journal Runを実行して「サマリー仕訳」を生成します。
| 概念 | 内容 |
|---|---|
| Journal Entry（JE） | Zuora内の個別トランザクション仕訳レコード（詳細） |
| Journal Run | 指定期間のJEを集計してサマリー仕訳を生成するバッチ操作 |
| サマリー仕訳 | ERPにインポートできる形式に集約された仕訳データ |
Revenue Recognition Rule — 前受収益から売上への振替設計
前受収益（Deferred Revenue）を毎月どのルールで売上に振り替えるかは、Revenue Recognition Ruleで設定します。Zuoraはこのルールに従ってRevenue Scheduleを自動生成し、JEを毎月計上します。
Revenue Scheduleとは
Invoice生成時、Product Rate Plan ChargeのRevenue Recognition Ruleに基づいてRevenue Scheduleが自動生成されます。これが「いつ・いくらを前受収益から売上に振り替えるか」のスケジュール表です。
Revenue Scheduleの内訳 — Recognized RevenueとUnrecognized Revenue
Revenue Scheduleの金額（Revenue Schedule Amount）は、常に次の式で分解できます。
Revenue Schedule Amount = Recognized Revenue + Unrecognized Revenue（Distributed + Undistributed）
| 項目 | 内容 |
|---|---|
| Revenue Schedule Amount | そのチャージについて、収益として認識・配分される予定の総額 |
| Recognized Revenue（認識済み収益） | すでにクローズされた会計期間に配分され、実現・認識された収益 |
| Unrecognized Revenue（未認識収益） | まだ収益として認識されていない金額。さらに2つに分かれる |
| ├ Distributed（配分済み） | Openの会計期間には配分済みだが、その期間がまだクローズされていないため未認識のもの |
| └ Undistributed（未配分） | まだどの会計期間にも配分されていないもの |
Revenue Recognition Ruleの種類
Zuora Billingは大きく「Billing-based revenue rule model」と「Custom revenue rule model」の2種類のモデルをサポートしており、Billing-basedモデルの中に5つの収益認識ルールが用意されています。
| モデル区分 | ルール | 振替タイミング |
|---|---|---|
| Billing-based | Full recognition upon invoicing（旧: Recognize upon invoicing） | Invoice生成時（請求日）に全額を即座に売上計上する |
| Billing-based | Daily recognition over time | 認識期間中、毎日均等に収益を認識する |
| Billing-based | Monthly recognition over time（旧: Recognize over time / Straight-line） | 各月へ均等に収益を按分する。この設定を使うには月次の会計期間が必要 |
| Billing-based | Full recognition on a specific date（旧: Recognize on a specific day） | 指定した特定の日に全額を計上する |
| Billing-based | Manual recognition | 収益の配分（Distribution）を手動で行う |
| Custom | Unlimited recognition | Zuoraが用意する定型ルールでは対応できない、独自の収益認識パターンに対応するためのカスタムモデル |
Revenue Scheduleの調整
Revenue Scheduleが生成された後に契約変更（Upgrade・Downgrade・Cancel）があった場合、Zuoraは自動でRevenue Scheduleを調整します。
| 変更 | Revenue Scheduleへの影響 |
|---|---|
| Upgrade | 差額分の新しいRevenue Scheduleが追加生成される |
| Downgrade | 過剰計上分が将来の期間から減額される |
| Cancel | 残期間分のRevenue Scheduleがゼロに調整される |
Revenue Events — 収益スケジュールを変化させる分配モデル
Revenue Eventとは、Revenue Scheduleを変化させるイベントのことです。企業ごとに、どのイベントで収益を認識するかの「分配モデル（Distribution Model）」が異なります。
| 分配モデル | 内容 |
|---|---|
| Sales（販売基準） | 商品が顧客に提供された、販売の時点で収益を認識する |
| Percentage of Completion（進捗度基準） | サービスの完了度合いと同じ割合で収益を認識する。長期の強制力ある契約であり、かつ収益・コスト・契約サービスの進捗割合が確定または算定可能であることが前提となる |
| Completion of All Contracted Activities（全活動完了基準） | 契約したすべての活動が完了した時点で、初めて収益・費用を認識する |
| Cost Recoverability（コスト回収基準） | プロジェクト完了にかかったすべての費用が回収されて初めて、収益を認識する |
| Installment Method（分割回収基準） | 収益を小口の分割払いで認識する方式。顧客からの回収の信頼性が低い場合に使われる |
Zuoraのサブレジャー機能とERP連携
ZuoraはERPが必要とする仕訳データを詳細レベルで管理し、集約してERPに渡します。ERPは個々の契約詳細を知らなくてよくなります。
ZuoraとERPの役割分担
| システム | 管理する情報 | 例 |
|---|---|---|
| Zuora | 契約・請求の詳細 | 誰が・何のプランで・いくら・いつ請求されたか |
| ERP | 会社全体の集計値 | 売上合計・売掛金残高・前受収益残高 |
サブレジャーとGLの方向性
ERPへの連携タイミング
Zuoraのjeが生成された直後にERPへ連携されるわけではありません。連携方式はプロジェクトによって異なります。
| 方式 | 内容 | 特徴 |
|---|---|---|
| 日次バッチ | 毎晩当日分の仕訳をまとめてERPに送る | 一般的な実装 |
| 月次エクスポート | 月末にCSVで経理担当者がERPに取り込む | シンプルな実装 |
| リアルタイムAPI | 仕訳発生のたびに即時連携 | 高度な実装 |
ZuoraとERPが一致しないケース
| 原因 | 内容 |
|---|---|
| 連携タイミングのズレ | Zuoraに仕訳は生成されたが、まだERPへの連携バッチが走っていない |
| 連携エラー | エクスポートジョブが失敗してZuora側だけに仕訳が溜まっている |
| Accounting Codeの設定ミス | ZuoraのコードとERPのGL番号のマッピングが間違っている |
| ERP側の手動入力 | ERP側で手動仕訳が追加されてZuoraと乖離した |
複数通貨と為替差損益
複数の通貨でPaymentを受け取る場合、為替レートの変動によって**外国為替差益または差損（Foreign Exchange Gain / Loss）**が発生します。
| 状況 | 内容 |
|---|---|
| 為替差益（FX Gain） | Invoice発行時より円安になり、受取額が帳簿上の金額より多くなった場合 |
| 為替差損（FX Loss） | Invoice発行時より円高になり、受取額が帳簿上の金額より少なくなった場合 |
会計クローズプロセス
月末にZuoraの会計期間をClosedにすると、その期間への仕訳追加が不可になります。クローズ前にTrial Balanceで残高確認と未転記仕訳の確認を完了させます。
一般的な会計クローズの5ステップ（前提知識）
企業が「帳簿を締める」プロセスは会社ごとに異なりますが、一般的には次の5ステップで整理されます。Zuora固有の手順に入る前に、まずこの一般モデルを押さえておきます。
| ステップ | 内容 |
|---|---|
| ① Journal Entryの作成 | 事業の財務状況に影響するすべての取引を、台帳（Ledger）へのエントリとして記録する |
| ② Revenue Reportの実行 | 収益レポートを実行し、（a）損益計算書に影響する収益の仕訳と、（b）貸借対照表の負債セクションに影響する前受収益の仕訳を作成する。月内に複数回実行してレビュー・エクスポートに使うこともある |
| ③ Trial Balanceの実行 | 会計期間末に試算表を作成・実行する。すべての借方・貸方を一覧化し、バランスしているか（＝帳簿が数学的に正しいか）を確認する。クローズ前だけでなく、期中に何度でも実行して健全性を確認できる |
| ④ Reconciliation and Review（照合とレビュー） | サブレジャーと総勘定元帳（GL）を照合する。数値をレビュー・検証し、必要に応じて調整する。この段階で会計期間がロックされ、新規のSales Orderは次の会計期間に計上されることもある |
| ⑤ Close（締め） | 各財務諸表の数値に問題がなく、照合も完了したら会計期間をクローズする。クローズ後はその期間のデータへの変更が一切できなくなる。監査・レポーティングの観点から重要なステップ |
会計期間のタイプ
Zuoraでは企業のビジネスカレンダーに合わせた複数の会計期間タイプをサポートしています。
| タイプ | 内容 | 用途 |
|---|---|---|
| Days（日単位） | 任意の日数で期間を定義 | 特殊な決算スケジュールへの対応 |
| Month（月次） | 暦月単位の会計期間 | 最も一般的。多くの企業が採用 |
| Quarter（四半期） | 3ヶ月単位の会計期間 | 四半期決算のみ管理したい場合 |
| 4-4-5 Week | 4週・4週・5週の3期間で1四半期を構成 | 小売業など週ベースの業界標準カレンダー |
会計期間の状態遷移と制約
| ステータス | 内容 | 仕訳の追加・変更 |
|---|---|---|
| Open | 通常の運用状態 | 可能 |
| Pending Close | クローズ作業中。Trial Balanceで確認する | 可能（問題修正のため） |
| Closed | 締め済み | 不可 |
クローズ作業に必要な権限（Role）
クローズ作業を実施できるユーザーは、権限に応じて次のように分かれます。
| ロール | Pending Close中の期間への変更 | クローズ処理・期間の削除／再オープン |
|---|---|---|
| Zuora Finance Standard User | 不可 | 不可（権限がない） |
| Zuora Finance Administrator（Manage Close Process権限あり） | 可能 | 可能 |
Trial Balance の制約
クローズ前のチェックフロー
| 作業 | 内容 |
|---|---|
| Trial Balance実行 | Zuora内の借方・貸方の残高を確認。CreatedのままのJEがないかチェック |
| Close Process Dashboard確認 | バリデーションエラーや問題箇所を一覧で確認 |
| ERPエクスポート確認 | 当月分のJEがすべてTransferred（ERPへ連携済み）か確認 |
| Period Close実行 | ZuoraのAccounting PeriodをClosedに変更 |
未解決トランザクション — 必須アクションと任意アクション
Trial Balanceを実行すると、その期間に残っている未解決のトランザクション一覧（Action Needed）が表示されます。このうち一部はクローズ前に必ず解決しなければならない「必須（Required）」項目で、残りは「任意（Optional）」項目です。
| 未解決トランザクション | 区分 | 必要な対応 |
|---|---|---|
| Draft invoice（下書き請求書） | 必須 | キャンセルするか、Postする |
| Draft payment（下書き支払い） | 必須 | 削除する |
| Processing payment / refund（処理中の支払い・返金） | 必須 | 状態が不明なため、Zuora Global Supportに連絡してステータスを更新してもらう |
| Draft credit memo / draft debit memo（下書きのCredit Memo・Debit Memo） | 必須 | キャンセルするか、Postする |
| Unprocessed charges（レーティングされていないUsageチャージなど） | 任意 | クローズ自体は妨げない。レポートをダウンロードして内容を確認し、処理するかどうかを判断する |
Zuora Billingのクローズ処理フロー（公式手順）
Zuora Billing上でのクローズ作業は、次の手順で進みます。
| ステップ | 内容 |
|---|---|
| ① Pending Closeに設定 | クローズ前の中間フェーズ。Draft状態のInvoice・Payment・処理中のRefundが残っていても設定は可能。設定するとFinance Standard Userはその期間に変更を加えられなくなる |
| ② Trial Balance実行 | 借方・貸方の残高をAccounting Codeごとに集計し、バランスを確認する |
| ③ 未解決項目の確認 | Trial Balanceの結果、Required（必須）とOptional（任意）に分かれた未解決トランザクション一覧を確認する |
| ④ 未解決項目の解消・再実行 | 必須項目を解消し、Trial Balanceを再実行して残っていないか確認する |
| ⑤ Closeに設定 | 必須項目がすべて解消されたら、Accounting PeriodをClosedに変更する。この時点でZuoraが自動でTrial Balanceを最終実行する |
| ⑥ 期間サマリー・残高の確認 | クローズ後、Ending AR BalanceやAR Aging Summaryなどの期間サマリーを確認する |
| ⑦ 会計期間情報をエクスポート | JE生成後、Summariesタブでサマリー仕訳をレビューし、Data Exports機能で詳細リストを抽出してERPへの取り込み用にエクスポートする |
クローズ後に確認できる期間サマリー — Ending AR BalanceとAR Aging Summary
クローズ後、Accounting Periodの残高タブ（Balances）から次の2種類のサマリーを確認できます。
Ending Accounts Receivable Balance（期末売掛金残高）
Ending AR Balance = Starting AR Balance + その期間中にARへ影響を与えた取引
前期間のEnding AR Balanceが当期間のStarting AR Balanceとしてそのまま繰り越されます。
AR Aging Summary（売掛金年齢調べサマリー）
会計期間末時点で残高が残っている請求書（Current＝支払期日未到来、または延滞）を、経過日数ごとのバケットに分類して一覧表示します。
knowledgecenter.zuora.comknowledgecenter.zuora.com/Zuora_Payments/Zuora_Finance/E_Accounting_Periods財務諸表 — Statement of Cash Flows
Zuoraで会計期間をクローズしてERPへ仕訳をエクスポートすると、企業はBalance Sheet（貸借対照表）・Income Statement（損益計算書）に加えて、Statement of Cash Flows（キャッシュフロー計算書）を作成できます。3つの財務諸表はそれぞれ別の側面を映し出しますが、相互に関連し合っています。
Statement of Cash Flowsは、ある期間（1年間・特定の会計期間など）に事業へ入ってきた・出ていった現金の動きを示す財務諸表で、Balance SheetとIncome Statementの一部を構成する情報から作られます。3つの主要な活動区分に分かれます。
| 活動区分 | 内容 | サブスクリプションビジネスでの例 |
|---|---|---|
| Operating activities（営業活動） | 原材料の調達など、事業の主たる業務から生じるキャッシュフロー | Invoice経由で回収したSubscriptionチャージの入金がプラス、顧客への返金・クレジット発行がマイナスに影響する |
| Investing activities（投資活動） | 什器・土地・建物などの資産の購入・売却から生じるキャッシュフロー | 設備投資（Capital Expenditure）、資産の売却による収入など |
| Financing activities（財務活動） | 長期の資金調達や、長期借入金・その返済など、事業の資本に関するキャッシュフロー | 長期借入、銀行融資の返済、配当の支払いなど |
実装時のキーテイクアウェイ — Implementation Best Practices
Zuora Finance導入時に押さえておくべきベストプラクティスとして、次の4点が挙げられます。
| ベストプラクティス | 内容 |
|---|---|
| Zuora Billingはフル機能のARサブレジャーとして設計されている | Zuoraは請求・入金消込・回収（Collections）までを含むフル機能のARサブレジャーとして設計されている。サマリーレベルのAccounting連携は、GL勘定科目のサマリーレベルでサブスクリプションデータを抽出するため、個々の取引（明細行）をすべてマッピングする必要がなく、会計システム側の負荷を軽減できる。一方、ERPシステムへの明細レベルのカスタム連携が必要な場合は、すべてのZuoraトランザクションを会計システムのトランザクションにマッピングし、仕訳を作成する必要がある。事業が成長するにつれて取引量が指数関数的に増える点も考慮する必要があり、Zuoraや連携パートナーが用意するコネクタでこの連携を自動化できるが、追加費用がかかる |
| 会計期間は必ずクローズする | 会計期間を必ずクローズすることで、その期間に追加の変更が発生しないことを保証できる。このベストプラクティスにより、たとえ他システム側でクローズ済みの期間であっても、その期間へ遡って取引がバックデートされることを防げる |
| Revenue Automation Start Dateを正しく設定する | Revenue Automation Start Dateは、あらかじめ定義した収益ルールを使って自動的に収益管理をトリガーする、一度だけ設定できる項目である。Invoice作成より前に設定しておく必要があり、Invoice作成後に設定すると、そのPost済みInvoiceのトランザクション日がRevenue Automation Start Date以降であっても、Revenue Scheduleが作成されない。Revenue Automation Dateを正しく設定していなかった場合、Mass Updaterツールを使ってRevenue Scheduleを事後的に作成できる |
| Accounting Codeを空欄（blank）にする運用は推奨されない | Accounting Codeはデフォルトでは空欄が許可されていない。Finance Settingsの「Allow blank Accounting Codes」をYesにすれば、取引やProduct Rate Plan Chargeで空欄のまま運用できるが、Zuoraとしては空欄運用は推奨していない。空欄のまま運用を始めた場合、後から一部の取引にAccounting Codeを設定しても、それ以前に発生した取引は空欄のまま残る。この場合はMass Updaterツールを使って空欄のAccounting Codeを一括更新できる |
Integration Use Cases — APIによるアカウント管理
企業はUI操作だけでなく、Mass Updaterツールと各種APIを使うことで、Zuora Financeを自社のGeneral Ledgerとより密接に連携させることができます。
Mass Updaterツール — CSVによる一括操作
Mass Updaterは、同じ操作を1件ずつ繰り返す代わりに、CSVファイルにまとめてアップロードすることで一括処理できるツールです。UI・APIのどちらからも実行できます。
| 一括操作 | 内容 |
|---|---|
| Update accounting codes（Accounting Codeの一括更新） | Chart of Accountsで勘定科目を更新した際、誤った古いAccounting Codeが紐づいたままの取引をまとめて修正する |
| Create revenue schedules（Revenue Scheduleの一括作成） | カスタムの収益認識ルールを使っている場合、UIで1件ずつRevenue Scheduleを作るのは手間がかかる。Mass Updaterならアップロード時に複数のRevenue Scheduleをまとめて作成できる |
| Update revenue schedules（Revenue Scheduleの一括更新） | Manual ruleに紐づくRevenue Scheduleなど、収益の再配分（再Distribute）が必要な場合に、複数のRevenue Scheduleをまとめて更新できる |
| Delete revenue schedules（Revenue Scheduleの一括削除） | Custom unlimited recognition ruleを使ったRevenue Scheduleを、誤ったスケジュールを作成してしまった場合などに削除する |
| Import foreign exchange rates（為替レートの一括インポート） | Oanda（Zuora標準の為替レートプロバイダ）を使わず、自社独自の為替レートをアップロードする場合に使う |
| Upload mass payments（Paymentの一括アップロード） | 銀行側ですでに回収済みのPaymentなど、外部で発生した支払い情報をZuoraに取り込みInvoiceを支払済みにする場合に使う。REST API経由でのみ利用可能（UIからは実行不可） |
Zuora Finance関連の代表的なAPI
| API | できること | 前提条件 |
|---|---|---|
| POST_JournalRun API | 外部システムからのトリガーで、API経由でJournal Runを作成する | — |
| Accounting Codes API | Accounting Codeの作成・アクティブ化・非アクティブ化・一覧取得・削除・照会・更新を行う | Zuora Financeがテナントで有効化されていること、Configure Accounting Codes権限を持つこと |
| Accounting Periods API | 会計期間のクローズ・Pending Closeへの変更・作成・一覧取得・更新・削除・再オープン・Trial Balance実行を行う | Zuora Financeがテナントで有効化されていること、Manage Close ProcessおよびRun Trial Balance権限を持つこと |
| The export custom exchange rates API | 自社独自の為替レートをインポートする。カスタムの為替レートプロバイダを使っている場合のみレートを照会（Query）でき、レートのアップロードはImport Foreign Exchange Ratesという一括操作を使う。この操作もMass Updater API経由での実行が推奨される | — |
101/201補足 — Accounting CodeとGL Segmentationの周辺論点
Accounting CodeはGLへの「マッピング」
Accounting Codeは、Zuoraの取引を総勘定元帳（GL）の勘定科目にマッピングする役割を持ちます。GLそのものではなく「GLへのマッピング」である点が問われることがあります（例：Subscription Revenue、Tax Liability、Refund Liability）。
Manage Chart of AccountsとConfigure Accounting Codesの役割分担（201）
- Manage Chart of Accounts：勘定科目コードそのものを新規作成する画面（例：「Subscription Revenue」という科目を新たに定義する）
- Configure Accounting Codes：すでにある勘定科目コードを、特定の支払方法やチャージ、税区分などに"紐付ける・有効化する"画面
たとえばDebit Cardの支払い方法に対してAccounting Codeを定義したいが、Finance SettingsでDebit Cardが非アクティブになっている場合の手順は、①Payments Settings > Payment Methodページで「Debit Card」をアクティブにする、②Finance Settings > Configure Accounting Codesページで、Debit Cardに対するAccounting Codeを設定する、の順です。「有効化（Payment Method）→ 紐付け（Configure Accounting Codes）」という順序を覚えておきます。
GL Segmentation Rule（201）
Journal Runで作られる仕訳は初期状態では大きな塊のままです。GL Segmentation Ruleは、この仕訳の出力を「地域別」「支払方法別」「自社独自の分類軸別」に細かく分けるための設定です。Accounting Period Close・Trial Balance・Revenue Recognitionはそれぞれ別の目的を持つ処理であり、GL Segmentationを使う処理ではありません。GL Segmentationを使う処理＝Journal Runと即答できるようにしておきます。
収益認識の設定順序（201）
設定は「Model有効化 → Rule作成 → Charge紐付け」という順番で行います。One-timeチャージに対してInvoicing時点で全額を収益認識したい場合、①「Full recognition upon invoicing」という収益認識モデルを有効化する、②「Recognize upon invoicing」という収益認識ルールを作成する、③Rate PlanのOne-timeチャージにそのルールを紐づける、の順です。先にChargeへの紐付けやRule作成を行う手順は、参照先（モデル・ルール）がまだ存在しないため成立しません。
AR Aging BucketsのCurrentバケット設定（201）
支払期日をまだ迎えていない請求書（Current、0日超過）を表すバケットを設定するには、From（days past due）フィールドを空欄のままにし、To（days past due）フィールドに「0」を入力します。Fromに0を入れてToを空欄にすると「0日以上すべて」を意味するバケットになってしまい、Currentだけを表すことができません。