売掛金（AR）業務を効率化：Zuora Collections & Cash Application の新機能

ケイ、最初の投票を開始します。次の画面です。質問はこうです：現在のARプロセスで最大のギャップは何ですか？そして具体的に、何について理解を深めたい、あるいはZuoraでどう対処できるかを知りたいと思って参加されていますか？ご回答まで1〜2分ほどお時間を取ります。あ、ロンドンからの方がいらっしゃいますね。素晴らしい。ご参加ありがとうございます。オランダ、ハンプシャーからも。サウスカロライナ州グリーンビル、ジョージア州からもいらっしゃいますね。先ほどアリゾナ州を見落としていました。ご参加ありがとうございます。ノースカロライナ州からも。

インドからだと、時差がありますよね。ご参加ありがとうございます。ボルダー。あそこに通っていました。[笑い] では、アンケートへの回答にあと30秒ほどお時間をいただいて、その後こちらで結果を表示します。サンディエゴもかなり早い時間ですね、ケイティ。[笑い] ゴー・バックス。アリソン、手作業が多いことが――手作業が多いことが……最大のギャップになっているようですね。ええ。素晴らしいです。というか、それは本当に……それを聞けてとても良いですね。というのも、まさにそこに対応するために私たちは作ってきたからです。では、そういうことで、今朝早い時間帯の方もいらっしゃる中、アンケートにご協力いただきありがとうございます。

えー、あるいはインドにいらっしゃる皆さまにとっては夜遅い時間かもしれませんね。[笑い] それではここで、デモンストレーションを開始するケイに引き継ぎます。ありがとうございます、アリソン。皆さま、こんにちは。本日はご参加いただき誠にありがとうございます。それではデモを開始いたします。本日ご紹介する内容ですが、まずは入金消込（Cash Application）から始め、続いてZuora Collectionsへ進みます。そしてその後、新機能の先行紹介として、サプライヤーポータルとフランス語UIをご覧いただきます。最後にお時間を設け、質疑応答としてご質問にお答えし、その他の点についても対応いたします。なお、すでにデモをご覧になり、入金消込におけるCollectionsをご覧になった方もいらっしゃるかと思いますが

これまでにご覧になった方もいらっしゃいますが、まだご覧になったことのない方もいらっしゃいます。そこで、以前ご覧になった方向けに簡単なおさらいを行い、また今回初めてこのセッションにご参加いただいた方向けに、Zuora Collectionsおよび入金消込（Cash Application）で実現できることを一通りご説明します。そして、リリース予定のサプライヤーポータルもご紹介できることを大変楽しみにしています。デモでは、2つの異なるペルソナの視点でご覧いただきます。一般的には、ARアナリスト、入金消込スペシャリスト、入金消込アナリストなどと呼ばれる役割です。つまり、入金消込を実質的に担当する人です。通常、この担当者は各種銀行ポータルにログインし、ダウンロードして

明細を作成し、その後、大量のExcelでの複雑な加工を行っています。ええと、まず最初に私たちが確認するペルソナはこの方で、Zuoraの入金消込（Cash Application）が、このプロセスをいかに迅速に、そして容易にできるかを見ていきます。その後、回収アナリスト／回収スペシャリストの視点に切り替えます。この方は通常、売掛金年齢表（Aging）をトラッキングしています。複数のツールやシステムからレポートを抽出し、売掛金年齢表を取りまとめるのですが、ここでもやはりスプレッドシート中心で作業しています。高リスクのアカウントを優先付けし、誰に連絡すべきかを見極め、DSO（売上債権回転日数）を低減しようとしています。ただ、両者に共通している点、そして投票結果でもおっしゃっていた共通点は、

ええと、業務を回すために、非常に多くの手作業が必要です。以上がペルソナです。これらは間違いなく非常に、非常に、ええと、関連性が高く、皆さまや皆さまのチームが現在どのように業務を進めているかを、まさに反映していると思います。そこで、Zuoraがこれら2つの役割を、双方の観点からどのように支援できるかを見ていきます。まずは入金消込（Cash Application）からです。ええと、これまでの経緯として、先ほど申し上げたとおり、当社がお客様とお話しする中で、そして私自身が見てきた限りでは、入金消込担当者は実際に、ええと、当社のペルソナでは「Jamie」という名前になっています。彼女は午前中を使って、ええと、日次終了（EOD）のファイルを取得します。彼女は、ええと、取引銀行が何行あるかに応じて、複数のポータルにログインしており、ええと、そしてこれらは……これは一部の……の例にすぎません……図

顧客が送ってきた送金情報があれば、それを確認し、突合しようとしますよね。それから、たとえばZuoraに入ったり、別のERPなど別システムに入って、手作業の入金処理を作成しようとする。そうなると非常に煩雑になります。おっしゃるとおり、ものすごく手作業になります。ですので、そうしたポータルにログインする必要がなくなり、そのプロセスは完- 完全に排除されます。なぜなら、これらの支払いは直接Zuoraに流れ込んでくるからです。では、それがどのように見えるかを確認していきますが、さらに私たちは統合も行っています

ええと、送金（リミッタンス）の受信ボックスからその送金データを取り込みます。そうすると、ZuoraのAIが作動して照合を支援します。これにより、チームで発生している手作業を大幅に削減できます。では、実際にどのように見えるのかを確認しましょう。一般的な支払いダッシュボードを見て、いくつかの照合シナリオも確認します。送金情報の抽出も含めて見ていきます。それでは早速始めましょう。では、いまこちらにログインしています。画面が更新されているとよいのですが。いま、キャッシュアプリケーション担当のJamieとしてログインしています。Zuora Cash Applicationsに入っています。Jamieがログインすると、最初に表示されるのは、すべての支払いが一か所に集約されている画面です。

そして、これらは複数の区分に分かれています。未適用、一部適用、適用済みです。適用済みとは、すでに入金として取り込まれているすべてを指します。100%マッチしており、自動で仕訳・計上されています。ここではJamieが対応する必要は一切ありません。彼女が時間をかけるのは、未適用または一部適用のものです。ここからはもはやExcelでもスプレッドシートでもありません。Jamieは、この画面上ですべての業務を行います。Zuora BillingとCash Applicationsがシームレスに連携し、必要に応じた調査に使える適切な情報をJamieに提供し、さらにZuora Billingへも滞りなく計上できるようにします。

これらの入金の例をいくつかお見せして、どのように見えるかをご紹介します。では、Jamieが確認しようとしている入金データを開いてみます。ええ、このケースでは、入金の説明に関する情報や、銀行からメタデータとして入ってくる情報の一部が確認できます。これは、ポータルから銀行ファイルを取得する際に通常表示される説明フィールドである可能性があり、ええ、私が見る限り、アナリストが手作業でコピー＆ペーストしなければならないことが多い部分です。もしかすると、そこに請求書番号が埋め込まれているかもしれません。そうした情報がすべて取り込まれ、ZuoraのAIが実際にこの情報を活用して自動抽出し、照合（マッチング）を支援できるようにします。ここには入金額があり、ええ、顧客情報も表示されています。ですので、ええ、実際にクリックして中に入ると、確認できるのは

この顧客については、実際には自動でマッチングされています。次に請求書の画面に入ると、手動で調整が必要な場合に備えて、該当する請求書の一覧を呼び出せます。ただ、今回は自動的にこちらの請求書に紐付けられています。画面下部では、送金明細情報（remittance information）も自動でタグ付けされています。つまり、これまでJamieが手作業で対応していた要素が、すべて1か所にまとまった形です。3つの情報を探し回る必要はなく、ここにすべて揃っています。支払情報があり、顧客も自動でタグ付けされ、請求書もこれに添付され、さらに送金明細もあります。したがってこのケースでは、100%一致、または

照合率については、ご自身が許容できる任意の割合で設定でき、この内容はZuora Billingに自動投稿（auto-post）されます。したがって、ここで必要な作業はありません。これは、見え方をお示しするための一例です。では、支払（payment）画面に戻って、照合（match）が見つからない入金（payment）の例を確認していきます。通常は、ここで、どのように表示されるかを見ていきます。支払（payment）はあるものの、送金案内（remittance）はなく、情報もほとんどありません。しかし、ZuoraのAIにより照合（match）を取得できます。これは、通常このような流れになりますよね。理想的に完璧な状況では、送金案内（remittance）があり、それが揃っていて、完全に一致する、という形です。

照合。アナリストが時間を費やしているのは、そこではありません。それ以上に時間がかかっているのは、その調査作業です。この顧客はいったい何を支払おうとしているのか、何が起きているのか。ですから、顧客がすでに照合された状態になっていて、そのうえで請求書を確認しながら、「これは支払いが少しイレギュラーな場合、どう照合したいか」を判断できるようにします。ここでは支払金額が$115,000で、これらがどのように合算されるかが示されています。両方に紐づけるのか、どちらか一方に紐づけるのか、などです。そこで実行していくと、こちらでこの1件が全額消し込まれ、残額が残りに配賦されていくのが分かります。そうしたことを提示できるだけの賢さがあります。さらに将来的には、Jamieがシステム上でこれらの操作を行っていくことで、機械学習の要素が

この仕組みは継続的に学習するため、実際に「まず最も古い請求書に全額を充当し、残額は新しい請求書に充当しましょう」といったレコメンデーションを提示するようになります。そして、そのような提案を継続的に行うことで、たとえJamieがこれらのチェックを実施する必要がある場合でも、手作業の負担は時間の経過とともに減少し、彼女にとってシステムがより効果的に機能するよう改善されていきます。完了したら、そのまま計上（ポスト）できます。では、ここまでJamieの視点で確認した内容を手短にまとめます。というのも、手元の時間で回収業務（collections）に入りたいので。ええと、私たちは、Jamieのような入金消込（cash application）アナリストが

AI駆動の消込による照合を用いて、支払の自動マッチングを実現できるため、計上および充当処理をより迅速かつ容易に行えます。また、処理が容易なものに注力するのではなく、必要な情報が不足している例外案件に注力できるようになります。さらに、例外案件を確認して処理を進めるための支援も充実しており、それらをはるかに迅速に処理して完了として計上できます。総じて、これにより売掛金（AR）の精度が向上します。入金の可視性が高まり、回収担当チームが延滞年齢表（Aging）の残高を参照している一方で既に入金が行われている、といった状況ではなく、チーム（および貴社チーム）が最新のエイジング残高に基づいて業務を遂行できるよう確実にします。

ただ、まだシステムには取り込まれていません。ですので全体としては、ええと、入金を消込に反映させるスピードをいかに高めるか、という点です。次に確認するのは、当社の回収プラットフォームです。ここで重要なのは、皆さまのチームが「文脈を踏まえた回収」を実行できる状態を確実にすることです。つまり、関係性を損なわずに維持しつつ、支払いを前倒しで促進し、顧客で何が起きているのかについて完全な履歴コンテキストを把握できるようにする、ということです。そうすることで、こちらから連絡する場合でも、顧客側から連絡があった場合でも、その全履歴を踏まえて対応でき、受注から入金までの全体像を把握したうえで、AIインサイトに基づいて意思決定ができるようになります。ではここで、ジェシカのジャーニーに切り替えます。彼女は当社のキャッシュ・アプライド担当です……

失礼、回収担当アナリストですね。ご記憶のとおり、彼女の主な目的は、先ほど申し上げたとおり、必要に応じて顧客へ適切に連絡できること、顧客からの問い合わせに対応できること、そしてDSOの低減や高リスクの大口顧客のリスク軽減等に注力することです。したがって、彼女の視点では、ARダッシュボードと、必要に応じて顧客の優先順位付けを行うために利用できる各種レポーティング等をご覧いただきます。また、顧客アカウントページも確認します。ここでは、いわゆる「コンテキストを伴う回収（Collections with context）」が具体的に何を意味するのかを説明します。さらに、Zuora内で自動化されている督促（dunning）戦略についても、簡単に一部をご紹介します。それでは早速、始めましょう

それでは、その方針で進めましょう。完璧です。では、ジェシカがログインした際に表示される画面に切り替えました。ええと、これはどちらかというと回収管理のダッシュボードで、ジェシカが債権の状況を把握できるようにするものです。つまり、未回収残高がいくらあるのか、DSOがどの程度か、といった点です。ええと――直近30日で11日短縮できているようですね、これは素晴らしいです。ということは、私たちが行っている取り組みが機能している、ということになります。うーん、キャッシュ・アプリケーションに未消込のクレジットが滞留しているようなものがあれば、その点も把握できます。繰り返しになりますが、これはシステム全体として機能します。これらの設定可能なエイジング区分により、ジェシカは請求書に基づいて、その状況を確認できます。ですので、こちらを見ると

その多くが、120日超の滞留（エイジング）区分に滞留しています。また、それらの請求書がどのように内訳として分かれているのか、理由は何なのかも確認します。つまり、係争はあるのか。係争がある場合、その係争理由は何なのか。実際の全体的な回収状況はどうなのか。実際、係争中の案件が多数あることが分かります。中には、回収業務がサードパーティに移管されているものもある、等々です。これにより、Jessicaは何が起きているのかを完全に把握できます。さらに言えば、これまではJessicaが状況を把握するために、複数の異なるレポートを抽出していました。しかし、そうしたエイジングレポートを抽出する代わりに、ARエイジングにアクセスするだけで、ライブのスナップショットを取得できます

レポートを1本も抽出することなく、すぐに確認できます。これにより、全体のスナップショットを把握できるほか、必要に応じてこれらの列を入れ替え、将来に向けてそのビューを保存しておくことも可能です。このビューでは、顧客情報も確認できます。さらにもう少し詳しく見たいので、いったんそれを閉じて、このAIヘルススコアも確認します。Zuoraは顧客の支払行動、経過日数（Aging）情報、異議申立（Dispute）などをすべて把握しているため、各顧客が1〜5の尺度でどのように評価されているかを理解するためのスナップショットを提供できます。したがって、ヘルススコアが低い顧客は、ええと、パフォーマンスがあまり良くないことが分かります。未決済の未回収残高が大量にあります

残高です。これらはエイジング区分ごとに確認できます。未解決の異議申立てが非常に多くあります。さらに見ていくと、各アカウントで何件のタスクがオープンになっているか、またはPromise to Payが未処理のまま残っているかも分かります。つまり、彼女が把握している情報は非常に多く、たとえば、これらの顧客に最後に連絡したのがいつか、といった内容も含まれます。したがって、こうした作業をExcelで行う代わりに、何もしなくても、必要な情報がすべてここに一か所で揃っています。また、直近のアクティビティも確認できます。これによりJessicaは、なるほど、ヘルススコアが低いこれらのアカウントでは、エスカレーションや異議申立てが発生しているようだ、また一部はメールを受信できていない、確認が必要だ、と理解できます。つまり、Jessicaが得られるのは、すぐに行動につなげられる示唆です。そして、文脈を理解するために

各顧客について、Jessicaはこの顧客アカウントページにアクセスすれば、すべての内訳を確認できます。したがって、ここにあるTop Circuit Techにメールを送る場合や連絡を取る必要がある場合でも、別の受信トレイや別のメモ、GoogleスプレッドシートやExcelなど複数の場所を確認することなく、このアカウントの全履歴を把握できます。請求書（未決済・決済済み）や入金など、必要な情報はすべてここに集約されています。Top Circuit Techには、実際に未計上の入金がいくつかあることも確認できます。これは回収チームが得られる追加のインサイトです。Top Circuit Tech宛て／Top Circuit Techから送信されたメールも含め、AIサマリーを含めて、あらゆる情報をここで確認できます。

彼女がこうしたスレッドを一つひとつ辿る必要はありません。状況の要点と、完全なアクティビティログをすぐに把握できます。ここには異議申立てがあり、メモもあります。この請求書の特定の明細行については質問も出ていました。つまり、ジェシカがこの取引先の状況を短時間で把握するためのコンテキストが豊富に揃っています。さらに、必要に応じてその場で何かを個別に送付する必要があれば、未消込のクレジットや未払いの請求書、ステートメントなどを添付して、そのまま対応できます。これにより、彼女が回収担当者として業務を遂行するのが非常に容易になります。ただし、督促の連絡という観点では、こちらはより手作業になります。Zuora の自動回収戦略を利用すれば、それらはすべて処理され、督促のアプローチも実際には自動的に実行されます。

ただし、ハイリスクのお客様やホワイトグローブ対応が必要なお客様など、本当に手厚い対応や個別対応を行いたいお客様については、常に別の回収戦略に振り分けることができます。こちらをご覧いただくと、このケースでは「ハイリスク・高価値顧客」として設定しており、これが何を意味するのかはこの後すぐにご説明します。Zuoraの自動化機能と自動回収戦略により、Jessicaは顧客セグメントを複数作成し、それらのセグメントを自動督促（dunning）戦略に活用することで、大幅な効率化を実現できています。それでは、Jessicaが作成した内容を見ていきましょう。

このハイリスクかつ高価値の顧客に対して。これらの回収戦略は設定が非常に容易です。ビジネスユーザーであり、技術系のIT担当者ではないジェシカでも、必要に応じて素早く調整でき、実際にポイント＆クリックで操作できるソリューションです。したがって、ジェシカがここに別のアクションを追加する必要があれば、そのまま追加できます。その際、このアクションをいつ実行するのか（支払期日後なのか、支払期日当日なのか、何日後なのか）を定義します。さらに、メールテンプレートを活用して、メッセージのトーンや含めるべき内容の種類をコントロールでき、すべての連絡先に対して適用できる動的プレースホルダーも含められます

そのメール内で事前にお客様へ提示しておくことで、ええと、さらに、キャッシュアップ担当アナリストとの間でお客様が行う可能性のあるやり取りの往復を一切なくせます。たとえば、ここにこれを挿入すると、Zuora Billingから既に流れ込んでいる情報が文脈に沿って自動的に反映されます。したがって、ここで情報を手作業で入力する必要は一切なく、さらに請求書やステートメント等も自動で添付されます。これにより、この回収戦略における新しいアクション項目の設定が非常に容易になります。ただし、実際にここに何が含まれているのかを確認するために、この例では、ええと、この高リスク顧客について、Jessicaは対応が必要だと判断し

より多くのタッチポイントです。したがって5日ごとに設定されていますが、ご覧いただいたとおり、これは非常に簡単に調整できます。最初のリマインダーから、回収担当アナリストが実際に対応するためのタスク作成に至るまで、一連の流れを用意しています。各アカウントにはそれぞれ回収担当者を割り当てることができます。そこで、このカテゴリに該当するJessica担当のアカウントについては、10日目に電話連絡を行うよう彼女に促されます。彼女向けにそのタスクが作成され、彼女は自分のワークリスト上で、発生し得るエスカレーションも含めて、何があるかを確認できます。さらにその先では、Jessicaは営業担当（Sales Rep）とアカウントマネジメントチームも、このプロセスに組み込み始めたいと考えています

関係者にも状況の可視性が必要ですので、営業担当者をCCに追加し始めることができます。特に高額・高リスクのアカウントについては、営業担当者またはアカウントチームが何が起きているのかを把握していることが重要です。そうすることで、更新交渉などの会話に入る際に、そのアカウントで実際に何が起きているのかという文脈を把握したうえで臨めます。設定は非常に簡単です。ただし、たとえば顧客が返信して「異議申し立てがある」または「支払約束（Promise to Pay）が未解決のまま残っている」といった場合、督促はルールや支払約束に設定された日付を読み取り、インテリジェントに自動で一時停止します。

そして、もし（あるいはいつ）その状態が崩れた場合でも、督促はそのまま継続されます。つまりジェシカは、顧客体験を最優先に考えながら、すでに支払い意思を示しているお客様にメールが送られてしまうことがないよう、何が起きるかを完全にコントロールできます。そしてその請求書がクローズされれば、督促は完全に停止します。ですので、今後これらの督促戦略を調整していく必要がある場合でも、また顧客セグメントごとに差別化したい場合でも、彼女にとっては非常に管理しやすい仕組みです。では最後に、ジェシカの例で見た内容を手短にまとめると、売掛金全体で何が起きているのかについて簡単に把握し、そこからさまざまな

指標を確認でき、また、さまざまな場所にある別々のレポートを取りに行って状況を把握しようとしたり、複数の情報源からの内容を、ええと、読み解こうとしたりすることなく、売掛金の滞留（ARエイジング）をすぐに呼び出せるようになります。さらに、顧客に関する完全なコンテキストを、ええと、一か所に集約して持てることが重要です。そうすれば、顧客から連絡があった場合でも、あるいは彼女のほうから連絡を取る必要がある場合でも、ええと、これまでの全履歴を把握したうえで、顧客に合わせて体験をきめ細かくパーソナライズできます。また、他のメンバーと協業できること、ええと、そうしたコミュニケーションのコンテキストをすべて一か所に集約できることも大きいです。そして私たちは、ええと、多くの顧客で大きな成果を、数多く目にしてきましたので、ええと、あの、たとえば……私たちが確認してきた数値の一部や、ええと、これまでいただいたコメントのいくつかを、継続して……

Zuora CollectionsおよびCash Applicationsを通じて、顧客を獲得し、そして、その成功を支援します。では、次のパートに移りますね。素晴らしい……次の内容に入ります。Kay、ありがとうございます。はい。ここで投票も実施する予定でしたよね。はい、出ました。では、ここまでご覧になった内容が良いと感じられ、私たちと面談をご希望の場合は、Kayのような担当者、または、このツールを専門に担当している別のメンバーも数名おりますので、

お知らせいただければ、本ミーティング終了後にこちらから改めてご連絡いたします。では、あと約30秒ほどお待ちし、その後ベータ版の内容をプレビューいたします。なお、チャットにご質問をご投稿いただいている皆さまへ、こちらで確認しておりますので、Q&AセクションにてKayに質問を投げかけてまいります。承知しました。Sabrina、投票は締め切って大丈夫です。それでは、サプライヤーポータルについて皆さまとお話ししましょう。完璧です。

では始めましょう。まず本題に入る前に、少し前提を整理させてください。ええと、私たちがより多くのお客様とこの点についてお話しする中で一般的に見えてきていることですが、お客様側でCoupaやAribaといったポータルの利用が進むにつれて、売掛金（AR）チームに管理業務の負担が大きく寄ってしまう傾向があります。請求担当、回収担当などは、複数のポータルに手作業でログインし、請求書情報を入力し、書類を添付し、さらにPO番号の突合や、空欄のある請求書への記入対応などが必要になる場合もあります。そのため、アップロードするだけでも相当な作業量になりますが、その後に進捗を追跡して状況を把握することにも、かなりの工数がかかってしまいます。つまり、

それに関連する手順が非常に多く、ええと、そのうえで実際の消込（リコンシリエーション）に至ります。つまり、手順が本当に、本当に多いのです。ええと、これらの一部は必ずしもそのまま当てはまらないかもしれませんし、当てはまるものもあるかもしれませんが、概ね私たちが目にしているのはそういう状況です。そして、複雑さと圧倒的な処理量がある中で、私が売掛金（AR）チームに現在課されている管理面のオーバーヘッドについて話すとき、それには、ええと、チーム内に蓄積された暗黙知も含まれます。ええと、こうした事象を追跡するうえでの可視性が限定的である、といった点です。総じて言えば、それがDSOに影響します。どのように影響するかというと

貴社のチームがどれだけ迅速かつ効率的に移動し、業務を遂行できるか、という点です。そこでZuoraのAPポータル自動化では、ARチームのためにデジタルワークフォースとして稼働する自律型AIエージェントを組み込んで構築しています。具体的には、請求書を受け取ると、それをポータルへ自動でアップロードし、必要な各入力項目を操作して、請求書を自動的に提出します。ただし、先ほど申し上げたとおり、それは戦いの一部に過ぎません。追跡も必要です。そのため、これらのエージェントはポータルを継続的に監視し、却下があった場合には、最新のステータス更新を取得できます。

その理由として、情報がそのままZuoraへ自動的に戻されます。ええ、そして支払ステータス等も確認できるようになります。つまり、こうしたポータル対応において、AR（売掛金）チームに継続的にのしかかっている手作業の負荷を大幅に削減できるということです。では、実際にどのように見えるのかをご覧いただきます。たとえば、これをCoupaに投入する世界を想像してみてください。そうすると、見え方は……。では、Jessicaをここに戻しましょう。Jessicaがログインしており、手動でアップロードする必要はなく、これらはすべて自動的にアップロードされた請求書です

Zuoraを使用しています。そこで彼女が追跡すべき内容は、これまでのように複数の顧客ポータルを行き来するのではなく、何が起きているのかを一覧で確認するだけになりました。もちろん、先ほどご覧いただいたとおり、引き続き回収業務（Collections）の配下です。彼女はこの請求書が何かを確認できます。ページを少し更新しますね。彼女はこの請求書の内容を確認でき、どうやら実際にはすべて解決済みになっています。おかしいですね。えーと、ここに全部入っていたのですが、解決されてしまいました。では、まだ残っている別のものを探します。ただ全体としては、ここで未解決だったもの、つまり問題の原因になっていたものを確認でき、さらにステータス別に並べ替えもできるので、承認待ちのもの、進行中のもの、却下されたものが何かを把握できます。

ええと、場合によっては完全に失敗してしまったりして、え、え、え、あれはどうなったのか、といった点ですね。あるいは作成日での並べ替え、別のお客様ごと、など。そうした機能によって、その追跡に対するコントロール性が大きく高まり、さらにワンクリックで提出できるようにもなります。ここでご覧いただいたとおり、私ならそれらを再提出できたはずです。ええと、そしてそれを継続的に監視しているため、ステータスを更新できます。もう一つ例をお見せするために、ええと、別の例をここに出してみます。

承知しました。ではそれを進めながら、フランス語UIも少しだけ確認します。グローバルチームに対応するうえで、これも非常に重要です。たとえばフランスで稼働しているチームがあり、テナントを当然フラ——フランス語で表示できる必要がある場合でも、そのように表示できます。ではここで手早くフランス語に切り替えて、実際にどのように見えるかもさっとお見せします。とはいえ、いつも［笑］言語設定に戻る道筋を探すことになるのですが。ですがご覧のとおり、ここで全体が更新されています。通貨については、ご利用の通貨がそのまま反映されます。ですので、USDをご利用であれば、

ええと、つまり、ローカライズ設定で……別の設定にする必要があって、そうするとそれに応じて調整されます。ただ、こちらでダッシュボード内を見ていただくと、ええと、当社のカスタマーエイジングやアカウントページなど、そうした文脈を含めて、ええと、フランス語になっています。完璧です。デモとQ&Aの時間も、ちょうど終盤に差しかかっていますので、ええと、アリソン、こちらから対応を始められそうなご質問はありますか。はい。ええと、承知しました。実は性質の近いものがいくつかありますので、まずはそのうちの一つから始めます。

ええと、質問の一つは、Cash Appの件に戻るのですが、複数の口座（アカウント）にまたがる請求書に対して支払いが行われた場合はどうなりますか。ええと、その複数の口座は、請求先名と住所によってのみ紐づけられている可能性があります。ええと、そして二つ目のバージョンとしては、ええと、ご存じのとおり、当社の一部の顧客グループでは、それぞれ固有の銀行口座を持つ複数の関連口座（関連アカウント）があり、時としてそのうちの一つの口座（アカウント）に対して一括で入金を受領するのですが、その入金を複数の請求書に分割して充当する必要があります。その場合、Cash Appではどのように処理されますか。ですので、ええと、一般的には、ええと、複数の…… 複数の支払いを受領している場合

分割されているケースとしては、親子関係になっている場合もあれば、無関係な場合もありますが、こうした状況は、ええと、リセラーのユースケースで頻繁に見受けられます。ええ、また、請求先（Bill To）と配送先（Ship To）の情報が異なる場合には、さまざまな要因が絡んできます。ええ、ただしZuoraのCash Applicationであれば、引き続きAIによる照合結果を提示できますし、請求先（Bill To）／配送先（Ship To）の情報だけに依存していないため、住所が異なっていても、ええ、（おそらく）Zuora Billing上では紐づいているはずです。仮に紐づいていない場合でも、送金案内（remittance information）に基づく場合であれ、私がCash Applicationでお見せした各種メタデータに基づく場合であれ、顧客および請求書情報を認識できるので、照合は可能です。つまり、異なるコンテキスト上の手がかりを用いても、引き続き照合結果を提示できるということです。

また、モデルが学習すべき特定のフィールドがある場合には、弊社の導入チームが、お客様固有のエッジケースのようなユースケースについても、実際にその学習（トレーニング）を行う対応が可能です。承知しました。ええと、次のご質問は、銀行取引明細（bank statement）をどのように取り込むのか、という点でした。特に、その点に関する懸念として、銀行取引明細のデータがAIと共有されたり、AIの学習に使用されたりしないか、また、Zuoraテナントの外部に当該データが露出してしまわないか、という点が挙げられていました。こちらについてですが……。弊社はお客様の銀行と直接連携し、ZuoraのFTP—SFTPサイト（非常にセキュア）を設定します。そのうえで、銀行と連携して、当該銀行ファイルをSFTPに直接取り込む形になります。

ええと、各種テストなどをすべて実施します。そして、そのデータはお客様ご自身のテナント内でのみ使用されます。他のAIモデルの学習等に使用されることは一切ありません。これは導入フェーズにおいて、お客様固有のユースケースに合わせて学習させる目的で使用され、当該データがその外部のいかなる場所とも共有されることはありません。承知しました。次の質問は回収（Collections）に関するもので、先ほど見たエイジング・バケットはZuora Billingで設定されているものと同じですか、という点でした。いいえ、エイジング・バケットはお客様側で任意に設定できます。Zuora Billingの設定に基づくこともできますし、Collections側で別の形に設定することも可能です。なるほど、ということは実質的に両方持てるということですか。はい、可能です。ただ、理想としては、もしお客様が…ユース

データ全体の標準化を維持するという観点では、そのケースに応じて最適な推奨事項を提示できると思います。可能性はありますが、なぜ同一にしない方針をご希望なのか、その理由をもう少し把握したいです。はい。分かりました。ええと、では、入金（remittance）を受領したものの、金額が請求書残高の合計と一致しない場合――たとえば銀行手数料、税控除、その他の費用などがある場合――キャッシュ・アプリケーション機能ではどのように処理されますか。支払差額は自動的に識別されますか。それとも、手動で突合・調整したうえで、Zuoraで調整仕訳等の対応が必要になりますか。方法はあります。たとえば銀行手数料であれば、そこで追加する形で調整を行うことが可能です。ただ、もし

短期の入金不足（short pay）や過入金（overpay）のようなケースですね。これは、いわゆる基本シナリオの一つで、必要に応じて該当する請求書（invoice）に対して残高（balance）を充当できます。必要であれば、私が先ほどお見せしたように、別の請求書に充当することも可能です。また、請求書が1件のみで過入金が発生した場合は、そのアカウント上に残高が保持されます。その後、Zuora Billing から返金（refund）を行うこともできますし、残高をそのまま維持しておくこともでき、選択肢があります。さらに、銀行手数料（bank fee）等については、調整してから計上（post）できるようになります。はい。では次の質問ですが、アカウントのヘルススコア（health scores）について考えると、これらは設定可能でしょうか、それともご自身で定義できますか。

ええと、上書きすることが可能です。つまり、それを算出するために、一定数の属性、あるいは複数の属性を用いているのですが、こちらで上書きできます。ですので、特定の知識として把握していて、かつ利用可能な情報がある場合は、それを上書きすることができます。ええと、それと本当に手短にですが、ポータル用に画面に出すための、もう少し分かりやすい例を探す必要があったので、私の分がすべて提出済みになっている状態で、どのように見えるかを手早くお見せしたいと思います。ですので、その点は失礼いたしました。アリソン、私の画面はいま更新されていますか？ はい、更新されています。これを手早く表示したかったので、念のため確認しました。先ほどお見せしたとおり、ええと、……ジェシカに戻ります。ジェシカが、ええと、戻ってきています。

彼女は、提出が必要となっているこれらすべての請求書を確認しています。請求書をクリックして状況を把握し、詳細を取得し、PDFも含めて確認する必要がある場合でも、すべてがここに用意されており、繰り返しになりますが、すべてZuora内で完結します。さらに、そのステータスも確認できます。つまり、これがスケジュール済みかどうか、提出に進められるかどうかが分かります。失敗している場合は、何が起きたのか、何らかの問題があるのかを確認できます。そのうえで、再提出することも可能です。つまり、必要な情報はすべてここで確認できます。また、提出済みのものについても確認でき、例として挙げると、このAPポータルのステータスが確認できます。ここでJessicaは、すでに承認されたものを確認でき、実際に全額支払い済みで、すべて完了していることが分かります。

ええと、「支払保留」って何が該当するのか、ええと、「承認待ち」とは何か、という点ですね。APポータルにはさまざまなフィールドがあるので、それが何を意味するのかが分かるように、ここで正しく表示されるよう適切にマッピングできます。ですので、ドラフトのままのものや承認待ちのものもありますが、これまではそれらを手動で提出しに行く必要があったところ、今はここでステータスを確認して、必要に応じてトラブルシューティングを行ったり、調整したり、再提出したりできるようになりました。つまり、手動で提出するための手間は、いまや取り除かれたということです。Zuoraを通じて、回収、入金消込、そしてAPポータルへの提出を、単一の画面で一元的に行えます。別の場所を探すために急いで対応してくれてありがとう—

はい。[笑い]…そのようにしていただけると。私も以前デモ担当の席にいたことがあって、同じことが起きた経験がありますが、あれは正直フラストレーションが溜まるので、配慮いただけてありがたいです。まさにそのとおりです。ええと、時間の終わりに入る前に、ここにある質問をいくつか確認させてください。次の質問は、「回収プロセスで、必要なときに営業担当者やCSMに介入してもらうために、どのように関与を促すのがおすすめですか？」というものです。具体的には、Salesforce上に回収用のダッシュボードは構築しているものの——はい…担当者がSalesforceのタスクを使っていないため、代替手段を探している、ということですね。Zuoraの回収システムから担当者へ連絡する方法として、Slackまたはメールが望ましいとのことです。なるほど。Slack連携はあると思います。では、その点について少し説明していただき、どのような進め方を提案されるか教えてください。

はい、もちろんです。自動化を通じてご覧いただいた督促戦略を覚えていらっしゃると思いますが、顧客ジャーニーのどの段階であっても、必要に応じて営業担当やCSMなどをCCに入れることができます。ただし、Slack経由で関係者を巻き込む方法もあります。そうすると、Slack上で通知を受け取れます。つまり、コラボレーション手段がいくつか用意されています。先ほどご覧いただいた例のようにメールで連絡することもできますし、Slackで通知することも可能です。@メンションで呼びかけたり、Collections内でタスクを作成したりすると、その内容がSlackに表示されます。私たちは、相手が実際に作業している場所で確実に通知したいのです。Slackが主なワークスペースであれば、それに合わせられます。加えて、ええと……Salesforceを使っているようですね。

Salesforce には、顧客レコード、正確には取引先（Account）レコード上に、売掛金（AR）の経過日数（Aging）を確認できるビューがあります。つまり、その取引先に関する情報が、当該取引先レコードに直接連携されて表示されるということです。したがって、相手が自社の取引先レコードをきちんとモニタリングしていれば、「なるほど、未解決のDisputeがいくつもある」「支払期日を過ぎた請求書が多数ある」といった状況を把握できます。次回の打ち合わせ、たとえばQBRなどのタイミングで、その点を取り上げるのが適切かもしれません。ですので、少なくとも3つの異なる場所（方法）で可視化し、相手がそのうち少なくとも1つでは必ず目にできるようにします。つまり、あなたが言っているのは、たとえSalesforceのタスク機能を使っていなくても、気づいていないという言い訳は通らない、ということですね。— そのとおりです。取引先レコード上、Slack、そしてメールです。

はい。ええと——チャンネルには入っていますよ。[笑い] そうですね、Zuoraは社内でも当社の回収（Collections）プロダクトを利用しているのですが、Slack連携は、財務担当者から「本当に助かっている」と声が上がっている機能の一つです。というのも、必要なときにすぐ担当者へメッセージを送り、意見をもらったり、状況を共有して認識してもらったりできるからです。ぜひそのSlack連携をチェックしてみてください。ええと、次の質問は、Zuoraを各種カスタマーポータルに接続する際の初期設定はどのようなものか、という点ですね。これは、たとえばCUPAやRIBAといったものを指しているのだと思います。接続後、Zuoraは、どの顧客について請求書を手動で提出するのではなく、ポータルへアップロードする必要があるのかを、どのように判別するのでしょうか？

ご質問の意図を完全に理解できているか自信がないのですが、つまり、どのポータル（あるいは…）なのかを特定しようとしている、という理解でよろしいでしょうか。失礼しました。はい。では、質問の前半は「それらのポータルに接続するための初期設定はどのようなものか」ということですね。承知しました。ええと、そして質問の後半は「どの顧客がポータル経由で進める必要があるのか、あるいは手動で対応すべきなのかを、どのように判断するのか」という点ですね。承知しました。では、私どもとしては…おそらく顧客ごとに異なるログイン、あるいはポータルごとに担当者が異なるログインをお持ちだと思います。まずは、それらのワークフローがどうなっているのかを整理するところから、御社と一緒に進めていきます。つまり、ログイン情報を入手し、どの顧客が実際にその対象に該当するのかを切り分ける作業で、これは導入（実装）の一部になります。ですので、ええと、実際にはログイン情報を安全に保管する方法という観点でも、御社がそうならないように

そうした作業をいま改めて管理していただく必要はありません。実装プロセスの一部として、実際にその情報をお客様からご提供いただく形になりますので、お知らせいただければ、その内容をセットアップに組み込み、自動で連携できるようにします。以後、調整が必要になった場合も、バックエンドで簡単に追加・変更できます。さらに、項目（フィールド）が更新された場合でも、マッピングも非常に容易に更新可能です。了解です。では次の質問です。少し時間をオーバーしていることは承知しています。Q&A は残り2件で、チャット側にもフォローアップとして1件残っていますので、ここで数分だけいただき、これらを終わらせたいと思います。次は「SFTP の件で、英国（UK）の銀行は利用できますか？」という質問です。つまり、英国の銀行で Cash App を利用できますか、という趣旨だと理解しています。

すべてはフォーマット次第です。したがって当社では、ええと、対応フォーマットの一覧は追って共有しますが、BAI2、CMT などに対応しています。つまり、特定の銀行に依存するのではなく、ファイルをどのフォーマットで送付できるかという点です。ですので、これらのいずれかのフォーマットであれば問題ありません。必要であれば、先方がどのフォーマットで対応しているかの確認について、こちらからフォローアップして一緒に進めることも可能です。なお当社は、オーストラリア、英国などを含め、グローバルのお客様と取引実績があります。はい。承知しました。現時点のQ&Aの最後の質問です。カナダドルで送金されたACH支払いについて、銀行側で着金時にUSDへ換算される場合はどうなりますか

銀行口座宛ですが、カナダ・ドルで適用する必要があり、えーと、実際に顧客が送金した金額です。Zuora Cash Appはそれをどのように読み取るのでしょうか。そうしたユースケースにおいて、どの明細（line item）を読み取るかをカスタマイズできますか。非常に良いご質問です。えーと——この件は後ほど持ち帰って確認します。申し上げられるのは、選択肢はあります、ということです。ええ、どのように設定したいかによって変わります。では、その請求書はカナダ・ドル建てですか、それとも米ドル建てですか。Zuora BillingでFXレートを管理されていますか。えーと、それは継承される可能性もあるので、そのあたりも含めて整理して検討したいところです。ただ、これらは、えー、当社が顧客でよく見かける一般的な事象です。分かりました。ではDahi、この件は

ええと、その点についてもフォローアップさせていただき、想定されるユースケースをより十分に把握したうえで、適切な回答へ確実につなげられるようにいたします。承知いたしました。ありがとうございます。Q&Aについては、実はすべてのご質問に回答し終えています。ええと、あわせてお伝えしますが、もし本日の議論の内容にご関心をお持ちいただき、以前はチームからのご連絡をご希望されていなかったものの、やはり連絡を受けたいという場合は、チャットでお知らせください。また、サブリナが共有していたリソースについてもご案内します。当社ウェブサイトにて、コレクション（債権回収）およびキャッシュ・アプリケーション（入金消込）のセルフアセスメントを最近公開しました。現在直面されている課題を入力していただくことで、今が検討を開始すべきタイミングかどうかを把握できるようになっています

製品の導入にあたってですが、そちらに必要事項をご入力いただけます。また、Zuora 製品がそうしたニーズに対応できるかどうかをご理解いただくための、便利なチャット機能もご利用いただけますので、ぜひそちらもご確認ください。ええと、そして繰り返しになりますが、弊社の AR エキスパートからの連絡をご希望の場合は、その旨をチャットにご入力いただければ、こちらからフォローアップいたします。本日はご参加いただき、ありがとうございました。ご参加中のご協力・ご質問等についても、ありがとうございました。また、デモ中の不具合にもかかわらず進行してくれた Kay にも感謝いたします。[笑い]