概要
ZuoraはサブスクリプションのすべてのトランザクションをAccounting Codeで勘定科目に紐づけ、仕訳を自動生成します。ERPの補助元帳として機能し、経理クローズ作業を設計・運用できるようになります。
会計の基本 — 複式簿記と収益認識
複式簿記では借方と貸方が常に一致し、前払いを受けてもサービス提供分だけを売上として認識します。サブスクリプションビジネスでは前受収益の管理が会計の核心です。
複式簿記のしくみ
すべての取引を「お金がどこから来たか（貸方）」と「どこへ行ったか（借方）」の2つの側面で記録します。左右の金額は常に一致します。
| 取引例 | 借方（左） | 貸方（右） |
|---|---|---|
| 請求書を発行した | 売掛金（もらう権利が増えた） | 売上（収益が発生した） |
| 入金があった | 現金（手元に入った） | 売掛金（権利が消えた） |
| 前払いを受けた | 現金（手元に入った） | 前受収益（まだ売上にできない） |
会計等式：
資産（Assets）= 負債（Liabilities）+ 純資産（Equity）
この等式が常に成立していることが「帳簿が正しい」状態です。Zuoraエンジニアとして押さえておくポイントは「借方と貸方が常にバランスしている」ことだけで十分です。
資産評価の方法 — Fair Value Method
資産と負債をどの価格で評価するかには複数の方法があります。試験では**Fair Value Method（公正価値法）**の定義が問われます。
| 評価方法 | 定義 |
|---|---|
| Fair Value Method（公正価値法） | 資産・負債を**現在の市場価値（Current Market Value）**で評価・報告する手法 |
| Historical Cost（取得原価法） | 購入当時の価格（原価）で評価する手法 |
サブスクリプションの収益認識
「お金をもらった時に売上計上する」のではなく、**「サービスを提供した時に売上計上する」**のが会計のルールです（収益認識原則）。
12万円の年間前払いを受けた場合：
| タイミング | 前受収益残高 | 売上計上額 |
|---|---|---|
| 契約時（前払い受領） | 120,000円 | 0円 |
| 1ヶ月目 | 110,000円 | 10,000円 |
| 毎月 | 10,000円ずつ減少 | 10,000円ずつ増加 |
| 12ヶ月目 | 0円 | 10,000円 |
Accounting Code — 勘定科目マッピングの設計
Accounting CodeはProduct Rate Plan Chargeに設定し、InvoiceやPaymentが発生するたびに仕訳を自動生成します。ERPの勘定科目体系と合わせて設計します。
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） |
Journal Entry — 仕訳オブジェクトの原理
ZuoraはInvoice・Payment・Credit Memoなどのトランザクションが確定するたびに、Journal Entry（JE）オブジェクトを自動生成します。JEがERPへ転記されることで、Zuoraはサブレジャーとして機能します。
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 Recognition Ruleの種類
| ルール | 振替タイミング | 使いどころ |
|---|---|---|
| Recognize upon invoicing | Invoice生成時に全額を即座に売上計上 | 一回払い・即時提供のサービス |
| Recognize over time（Straight-line） | サービス期間にわたって均等に按分 | 月額SaaSのような期間サービス（最も一般的） |
| Recognize on a specific day | 指定した特定日に全額を計上 | マイルストーン型の契約 |
Revenue Scheduleの調整
Revenue Scheduleが生成された後に契約変更（Upgrade・Downgrade・Cancel）があった場合、Zuoraは自動でRevenue Scheduleを調整します。
| 変更 | Revenue Scheduleへの影響 |
|---|---|
| Upgrade | 差額分の新しいRevenue Scheduleが追加生成される |
| Downgrade | 過剰計上分が将来の期間から減額される |
| Cancel | 残期間分のRevenue Scheduleがゼロに調整される |
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で残高確認と未転記仕訳の確認を完了させます。
会計期間のタイプ
Zuoraでは企業のビジネスカレンダーに合わせた複数の会計期間タイプをサポートしています。
| タイプ | 内容 | 用途 |
|---|---|---|
| Days（日単位） | 任意の日数で期間を定義 | 特殊な決算スケジュールへの対応 |
| Month（月次） | 暦月単位の会計期間 | 最も一般的。多くの企業が採用 |
| Quarter（四半期） | 3ヶ月単位の会計期間 | 四半期決算のみ管理したい場合 |
| 4-4-5 Week | 4週・4週・5週の3期間で1四半期を構成 | 小売業など週ベースの業界標準カレンダー |
会計期間の状態遷移と制約
| ステータス | 内容 | 仕訳の追加・変更 |
|---|---|---|
| Open | 通常の運用状態 | 可能 |
| Pending Close | クローズ作業中。Trial Balanceで確認する | 可能（問題修正のため） |
| Closed | 締め済み | 不可 |
Trial Balance の制約
クローズ前のチェックフロー
| 作業 | 内容 |
|---|---|
| Trial Balance実行 | Zuora内の借方・貸方の残高を確認。CreatedのままのJEがないかチェック |
| Close Process Dashboard確認 | バリデーションエラーや問題箇所を一覧で確認 |
| ERPエクスポート確認 | 当月分のJEがすべてTransferred（ERPへ連携済み）か確認 |
| Period Close実行 | ZuoraのAccounting PeriodをClosedに変更 |
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だけを表すことができません。