与信管理・債権回収データテンプレート
与信管理・債権回収データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- NetSuite向け抽出ガイド
債権管理と回収の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
特定の時点で発生したビジネス活動の名称。 | ||
|
説明
この属性は、「請求書発行済み」、「支払い受領」、「紛争登録済み」など、与信管理および債権回収プロセスにおける特定のステップまたはイベントを記述します。これらの活動の順序と頻度を分析することは、プロセスマイニングの核であり、実際のプロセスフロー、逸脱、ボトルネックを明らかにします。
その重要性
この属性はプロセスマップの基盤を形成し、プロセスフローの可視化と分析を可能にします。
取得元
このフィールドは通常、トランザクションレコード(例:請求書、顧客支払い)のステータス変更、またはシステムノート、回収活動用のカスタムレコード、CRMタスクなどの関連レコードから派生します。
例
請求書生成済み延滞リマインダー送付済み入金確認済み請求書償却済み
|
|||
|
イベント日時
EventTime
|
アクティビティの発生時刻を示すタイムスタンプです。 | ||
|
説明
この属性は、プロセス内の各活動の正確な日付と時刻を捕捉します。サイクルタイム、期間、ステップ間の待機時間など、すべての時間ベースの分析の基本となります。NetSuiteでは、このタイムスタンプは通常、関連レコードまたはシステムノートの作成日または最終更新日です。
その重要性
サイクルタイムやボトルネックなど、時間に関連するすべてのパフォーマンス指標の計算を可能にし、効率分析にとって重要です。
取得元
これは様々なレコードの日付フィールドから取得されます。例えば、「請求書発行済み」の場合は請求書レコードの「作成日」、ステータス変更の場合はシステムノートのタイムスタンプなどです。
例
2023-01-15T10:00:00Z2023-02-01T14:30:00Z2023-02-15T09:05:00Z
|
|||
|
請求書番号
InvoiceNumber
|
各顧客請求書の一意の識別子。 | ||
|
説明
請求書番号は、特定の売掛金に関連するすべての活動を一意にリンクする主要なケース識別子として機能します。これにより、請求書作成からその後の与信管理措置、最終的な支払いまたは回収活動による解決まで、ライフサイクル全体の包括的な分析が可能になります。NetSuiteでは、通常、取引タイプが「請求書」の場合のトランザクションIDに相当します。
その重要性
請求書の生成から決済までのジャーニーを追跡するための不可欠な鍵であり、エンドツーエンドのプロセス分析を可能にします。
取得元
これは通常、NetSuiteの請求書レコードにおける「Transaction ID」(内部ID: tranid)フィールドです。
例
INV0012345INV0054321INV0098765
|
|||
|
支払期日
DueDate
|
請求書の支払期日です。 | ||
|
説明
支払い期日は、契約上合意された支払日です。これは、支払いが期限内か期日超過かを判断するための基準となります。この属性は、「オンタイム支払い率」などのKPIを計算し、期日を過ぎた場合に督促活動をトリガーするために不可欠です。
その重要性
支払いの適時性を測定するための主要なベンチマークとして機能し、延滞日数の計算や支払条件の順守監視に不可欠です。
取得元
これは請求書トランザクションレコードの「Due Date」(内部ID: duedate)フィールドです。
例
2023-02-142023-03-312023-04-15
|
|||
|
請求書ステータス
InvoiceStatus
|
ライフサイクルにおける請求書の現在のステータス。 | ||
|
説明
請求書の現在の状態(「オープン」、「全額支払い済み」、「延滞」など)を示します。これは、現在アクティブまたは問題のある請求書のみをフィルターして分析するのに役立ちます。「延滞請求書年齢とステータス」ダッシュボードは、この属性に依存して未回収債権のスナップショットを提供します。
その重要性
オープン、延滞、または紛争中の請求書など、請求書ライフサイクルの特定の段階に焦点を絞って分析することができます。
取得元
これは、請求書トランザクションレコードの「Status」(内部ID: status)フィールドに対応します。
例
オープン全額支払い済み期限超過
|
|||
|
請求金額
InvoiceAmount
|
請求書の合計金額。 | ||
|
説明
請求書の総支払額を表します。これは、高額な期日超過請求書の回収優先順位付けなど、ほとんどすべての分析で利用される重要な財務属性です。回収活動の優先順位付けに不可欠なコンテキストを提供します。
その重要性
プロセスに財務的なコンテキストを提供し、金額に基づいた分析を可能にします。これにより、高額な期日超過請求書の回収を優先するなどの対応が可能です。
取得元
これは請求書トランザクションレコードの「Amount (Total)」(内部ID: total)フィールドです。
例
1500.00250.5012500.75
|
|||
|
顧客ID
CustomerId
|
請求書に関連付けられた顧客の一意の識別子。 | ||
|
説明
この属性は、NetSuite内で請求書を特定の顧客エンティティにリンクします。異なる顧客や顧客グループ間でプロセスパフォーマンスを分析するためにデータをセグメント化する上で不可欠です。例えば、戦略的アカウントと中小企業との支払い行動や紛争率の分析を可能にします。
その重要性
顧客中心の分析を可能にし、どの顧客が頻繁に遅延したり、紛争を提起したり、標準外のプロセスに従っているかを特定するのに役立ちます。
取得元
これは請求書トランザクションレコードの「Customer」(内部ID: entity)フィールドです。
例
CUST001CUST002CUST003
|
|||
|
顧客セグメント
CustomerSegment
|
規模、業種、地域などによる顧客の分類。 | ||
|
説明
顧客セグメントは、顧客を意味のあるグループ(例: 「エンタープライズ」、「SMB」、「公共部門」)に分類します。この属性は、「セグメント別回収戦略パフォーマンス」ダッシュボードにとって極めて重要であり、これらのセグメント間で異なる回収アプローチの有効性を比較することができます。これにより、各グループの固有の行動に合わせて戦略を調整するのに役立ちます。
その重要性
特定のプロセス問題や支払い行動が特定の顧客グループに集中しているかどうかを判断するためのターゲットを絞った分析を可能にします。
取得元
これは多くの場合、NetSuiteの顧客レコード上のカスタムフィールドです。データは顧客レコードから請求書トランザクションに結合する必要があります。
例
エンタープライズミッドマーケットSMB
|
|||
|
ソースシステム
SourceSystem
|
データを抽出した元システム。 | ||
|
説明
イベントデータの発生元システムを識別します。このプロセスビューでは、値は常に「NetSuite」となりますが、データガバナンスおよびマルチシステム環境でデータソースを区別するための必須属性です。
その重要性
データリネージとトレーサビリティを確保します。これは、特に複数の統合システムを持つ環境において、データ検証とガバナンスにとって重要です。
取得元
これはデータ変換プロセス中に付加される静的値(「NetSuite」)です。
例
NetSuite
|
|||
|
ビジネスユニット
BusinessUnit
|
取引に関連する事業部門または子会社。 | ||
|
説明
請求書を発行した特定の事業部門、部署、または子会社を表します。NetSuite OneWorldアカウントでは、通常「Subsidiary」フィールドに対応します。これにより、プロセス分析を組織の異なる部分でセグメント化し、パフォーマンス比較や部門固有の問題の特定が可能になります。
その重要性
異なる組織単位間でプロセスパフォーマンスを比較することができ、異なる管理アプローチが必要となる可能性のあるばらつきを明らかにします。
取得元
NetSuite OneWorldでは、これは「子会社」フィールドです。他のアカウントでは、設定に応じて「部門」または「クラス」となる場合があります。
例
米国西部EMEAサービスAPAC製品
|
|||
|
ユーザー`ID`
UserId
|
活動を実行したユーザーの識別子。 | ||
|
説明
特定の活動(支払い記帳や回収電話など)を担当する従業員またはシステムユーザーを特定します。これにより、ワークロードの配分、チームのパフォーマンスを分析し、トレーニングニーズを特定することができます。自動化された活動の場合、これはシステムユーザーIDである可能性があります。
その重要性
ユーザーまたはチームごとのパフォーマンス分析を可能にし、ワークロードの配分を理解し、手動介入が発生する場所を特定するのに役立ちます。
取得元
取引または関連レコード(例:回収電話の電話記録)上の「作成者」、「最終更新者」、または特定の「所有者」のようなフィールドから取得されます。
例
j.doea.smithSYSTEM
|
|||
|
最終データ更新
LastDataUpdate
|
ソースシステムからの最終データ更新のタイムスタンプ。 | ||
|
説明
この属性は、このプロセスのデータがプロセスマイニングツールで最後に抽出および更新された時期を示します。これにより、ユーザーは分析しているデータの鮮度を理解し、最新の情報に基づいて意思決定を行っていることを確認できます。
その重要性
データ鮮度に関する透明性を提供し、ユーザーがプロセス分析の最新性を把握できるようにします。
取得元
この値はデータ抽出時に生成され、データセットに付加されます。
例
2023-10-27T02:00:00Z
|
|||
|
回収担当者名
CollectorName
|
請求書に割り当てられた回収担当者の名称。 | ||
|
説明
延滞請求書の管理を担当する特定の回収担当者またはリソースを特定します。これにより、回収チーム全体のパフォーマンス分析が可能になり、ワークロードの配分と個々の回収担当者の有効性を理解するのに役立ちます。「回収連絡成功率」のようなKPIをサポートします。
その重要性
回収チームのパフォーマンス測定とワークロードバランシングを可能にし、回収活動を特定の個人に紐付けます。
取得元
これは多くの場合、顧客または請求書レコード上のカスタムフィールドです。NetSuiteの債権回収用バンドルによっては、この機能が追加されることがあります。
例
Alice Johnsonロバート・ウィリアムズ未割り当て
|
|||
|
国
Country
|
顧客の請求先住所の国。 | ||
|
説明
この属性は、請求書の顧客請求先住所に関連付けられた国を示します。支払行動、回収効率、紛争率における地理的変動を分析するために使用されます。これにより、特定の地域に合わせた回収戦略の調整や、現地の経済状況の影響を理解するのに役立ちます。
その重要性
プロセスの地理的セグメンテーションを可能にし、支払い行動やプロセス効率における地域差を浮き彫りにすることができます。
取得元
これは請求書トランザクションの「請求先住所」の詳細から取得され、通常は顧客レコードから継承されます。
例
米国ドイツ日本
|
|||
|
延滞日数
DaysOverdue
|
請求書が期日を過ぎている日数。 | ||
|
説明
この計算された指標は、請求書の支払い期日と現在の日付(未決済請求書の場合)または支払日の間の日数を測定します。これは回収業務の基本的なKPIであり、「期日超過請求書の経過日数とステータス」ダッシュボードで回収活動の分類と優先順位付けに利用されます。値がゼロ以下の場合、請求書は期日超過ではないことを示します。
その重要性
支払い遅延の深刻度を直接測定し、債権年齢表や回収活動の優先順位付けのための主要な指標となります。
取得元
これはデータ変換中に計算されます:(現在の日付または支払日)- 支払い期日。
例
1532090
|
|||
|
支払い計上遅延
PaymentPostingLag
|
支払いを受領してからシステムに計上するまでの時間。 | ||
|
説明
この計算された期間は、「支払い受領」活動(資金が受領された時)と「支払い計上」活動(NetSuiteで支払いが請求書に適用された時)との間の遅延を測定します。これは「支払い計上遅延分析」ダッシュボードの主要な指標であり、現金可視性を歪める可能性のある入金処理における内部非効率性を浮き彫りにします。
その重要性
入金処理における内部的な遅延を明らかにし、これは財務報告の正確性や顧客アカウントのステータスに影響を与える可能性があります。
取得元
これはプロセスマイニングツールで計算されます:Timestamp('Payment Posted') - Timestamp('Payment Received')。
例
1日4時間3 days
|
|||
|
支払条件
PaymentTerms
|
請求書に対して顧客と合意された支払条件。 | ||
|
説明
この属性は、「Net 30」や「Net 60」など、顧客が請求書を支払うべき条件を特定します。これは請求書の支払い期日を計算するための基礎となり、顧客が合意された条件を遵守しているかどうかを分析する「支払条件コンプライアンスと逸脱」ダッシュボードにとって不可欠です。
その重要性
支払いスケジュールの契約上の根拠を提供し、コンプライアンスの分析やキャッシュフローに影響を与える逸脱を特定するために不可欠です。
取得元
これは請求書トランザクションレコードの「Terms」(内部ID: terms)フィールドです。
例
支払条件:正味30日支払条件:正味60日受領時支払い
|
|||
|
期日通りに支払い済み
IsOnTimePayment
|
支払いが期日までに受領されたかどうかを示すフラグ。 | ||
|
説明
この計算されたブール属性は、「支払い受領」活動が請求書の「支払い期日」以前に発生したかどうかをチェックします。「オンタイム支払い率」KPIの計算を簡素化し、期限内支払いと遅延支払いを簡単にフィルタリングして分析することを可能にします。これにより、支払いパフォーマンスに関する明確な二者択一の結果を提供します。
その重要性
支払条件のコンプライアンスを評価するためのシンプルで二者択一の指標を提供し、オンタイム支払い率の計算とベンチマークを容易にします。
取得元
これはデータ変換中に計算されます:(Payment Date <= Due Date) の場合TRUE、それ以外の場合FALSE。
例
truefalse
|
|||
|
紛争理由
DisputeReason
|
請求書に関する顧客紛争の理由。 | ||
|
説明
顧客が請求書に異議を唱える際、この属性は「誤った価格設定」、「破損品」、「重複請求」などの理由を捕捉します。「請求書紛争解決時間」および「請求書貸倒れ根本原因分析」ダッシュボードにとって、紛争が発生する理由を理解し、将来の問題を防ぐために対応できるパターンを特定するために不可欠です。
その重要性
顧客紛争の根本原因を特定するのに役立ち、受注処理や請求の正確性といった上流プロセスを改善するために必要な洞察を提供します。
取得元
これは請求書レコード上のカスタムフィールド、または紛争ケースを追跡するために使用される関連カスタムレコードである可能性が高いです。標準のNetSuiteフィールドではありません。
例
数量不一致価格不一致破損品
|
|||
|
自動化
IsAutomated
|
そのアクティビティがシステムによって自動的に実行されたかどうかを示すフラグ。 | ||
|
説明
このブール属性は、活動が自動化されたワークフローによって実行されたか、または人間によって実行されたかを指定します。例えば、「期日超過リマインダー送信」活動は自動化される可能性がありますが、「督促電話」は手動です。これは、自動化レベルを定量化し、さらなる自動化の機会を特定するための「手動活動の頻度と影響」ダッシュボードにとって不可欠です。
その重要性
プロセスにおける自動化のレベルを定量化するのに役立ち、手作業の削減と効率向上に向けたイニシアチブを支援します。
取得元
これは活動タイプまたはそれを実行したユーザーに基づいた派生属性です。例えば、ユーザーが指定された「SYSTEM」ユーザーの場合、活動は自動化されたものとしてフラグ付けされます。
例
truefalse
|
|||
|
請求書現金化サイクルタイム
InvoiceToCashCycleTime
|
請求書発行から最終決済までの総時間。 | ||
|
説明
この計算された指標は、「請求書発行済み」活動から「請求書決済済み」活動までの総期間を測定します。これは、与信管理および債権回収プロセス全体の端から端までのパフォーマンスを表します。このKPIを分析することで、システム的な遅延を特定し、キャッシュフロー速度の高レベルな尺度を提供します。
その重要性
これは、請求書から入金までのプロセス全体の全体的な効率性を測定する、重要で高レベルなKPIです。
取得元
これはプロセスマイニングツールで実行されるケースレベルの計算です:Timestamp('Invoice Settled') - Timestamp('Invoice Generated')。
例
32日間45日間91日間
|
|||
債権管理と回収活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
入金確認済み
|
このイベントは、顧客の支払いが作成され、請求書に適用された時点を示します。これはNetSuiteの顧客支払いトランザクションレコードから直接取得される重要なマイルストーンです。 | ||
|
その重要性
この活動はDSOとオンタイム支払い率を計算するために不可欠です。現金の受領を意味し、回収成功の主要な尺度となります。
取得元
「顧客支払い」取引記録の作成日よりキャプチャされます。この記録の「適用」サブリストは、支払いを1つ以上の請求書にリンクします。
取得
顧客支払いレコードの取引日を使用します。
イベントタイプ
explicit
|
|||
|
支払期日経過済み
|
請求書が全額支払われないまま、現在の日付がその請求書の支払期日を過ぎた場合に発生する計算されたイベントです。これにより、請求書が「現状」から「延滞」ステータスに移行したことを示します。 | ||
|
その重要性
このイベントは、すべての回収活動にとって重要なトリガーとなります。このイベント以降の時間を分析することは、回収効率と督促の有効性を理解する上で鍵となります。
取得元
これは計算されたイベントです。請求書トランザクションレコードの「支払い期日」フィールドと現在の日付を比較することで導出されます。イベントのタイムスタンプは支払い期日そのものです。
取得
タイムスタンプは請求書上の「支払い期日」フィールドの値です。
イベントタイプ
calculated
|
|||
|
請求書の精算完了
|
支払いや適用されたクレジットを通じて残高がゼロになり、請求書ライフサイクルが正常に完了したことを表します。これは、請求書ステータスが「全額支払い済み」に変わったときに推測されます。 | ||
|
その重要性
これは、プロセスの主要な成功終了イベントです。請求書から入金までのエンドツーエンドのサイクルタイムを計算するための最終データポイントとなります。
取得元
請求書取引の「ステータス」フィールドが「全額支払い済み」に変更されたことから推測されます。タイムスタンプは、請求書をクローズした最終支払いまたはクレジットメモの日付から取得できます。
取得
ステータスを「全額支払い済み」に設定する最後の支払い適用のタイムスタンプ。
イベントタイプ
inferred
|
|||
|
請求書償却済み
|
請求書ライフサイクルの失敗した結末であり、債務が回収不能と見なされ、売掛金から削除されます。これは、貸倒処理の仕訳が請求書に適用されたときにキャプチャされます。 | ||
|
その重要性
これは致命的な失敗終点です。貸倒れにつながる経路を分析することで、与信ポリシーと回収戦略における弱点を特定し、最終的に不良債権を削減するのに役立ちます。
取得元
請求書に「仕訳」が適用されたことから推測されます。この仕訳は特に貸倒償却のためです。カスタムステータスも使用される場合があります。
取得
請求書に適用された貸倒れ仕訳伝票の日付を使用します。
イベントタイプ
inferred
|
|||
|
請求書生成済み
|
システムにおける請求書レコードの正式な作成を示します。このイベントはNetSuiteにおける請求書取引の作成日よりキャプチャされ、請求書のライフサイクルの開始点となります。 | ||
|
その重要性
これは、請求書から入金までのプロセスにおける主要な開始イベントです。売掛金回収日数(DSO)や全体的な請求書から入金までのサイクルタイムなどの主要な指標を計算するために不可欠です。
取得元
これは、NetSuiteの請求書トランザクションレコード(Typeが「Invoice」であるトランザクションテーブル)の作成日から取得される明示的なイベントです。
取得
請求書トランザクションレコードの作成タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
クレジットメモ発行済み
|
請求書に対して適用されるクレジットメモの作成を表し、多くの場合、エラーの修正や紛争解決の一環として行われます。これはNetSuiteにおける明示的な取引です。 | ||
|
その重要性
頻繁なクレジットメモは、価格設定エラーや配送問題などのシステム的な問題を示している可能性があります。その発生を分析することは、収益漏れの根本原因を特定するのに役立ちます。
取得元
これは、元の請求書にリンクされたクレジットメモトランザクションレコードの作成日から取得される明示的なイベントです。
取得
クレジットメモトランザクションの作成タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
回収電話実施済み
|
回収担当者が電話で顧客に連絡する手動の回収活動です。このイベントは、NetSuiteのCRMモジュールにあるユーザーが作成した「電話」活動記録からキャプチャされます。 | ||
|
その重要性
この活動は、回収プロセスにおける手動作業を定量化するのに役立ちます。その頻度と成功率を分析することは、リソース配分と自動化を最適化するために重要です。
取得元
関連レコードが顧客であり、請求書番号がメッセージ内で参照されている「電話」活動記録の作成日よりキャプチャされます。
取得
電話CRM活動レコードからのタイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
延滞リマインダー送付済み
|
延滞請求書に関して、最初の、多くの場合自動化されたリマインダーが顧客に送付されます。この活動は通常、NetSuiteの督促モジュールにおける督促状の作成または記録されたコミュニケーションイベントからキャプチャされます。 | ||
|
その重要性
この活動は督促プロセスの最初のステップです。その頻度と支払いへの影響を分析することは、初期の回収努力の有効性を評価するのに役立ちます。
取得元
請求書に関連付けられた「督促状」レコードの作成日よりキャプチャされます。このレコードはNetSuite Dunning SuiteAppによって生成されます。
取得
督促状レコードの作成タイムスタンプを使用します。
イベントタイプ
explicit
|
|||
|
支払い計上
|
支払いの財務的影響が総勘定元帳に正式に記録される日付を表します。これは、顧客支払い取引の計上日から取得されます。 | ||
|
その重要性
「支払い受領」から「支払い計上」までの時間は、管理上の遅延を明らかにします。この遅延を分析することは、正確でタイムリーな財務報告を確保するために重要です。
取得元
「顧客支払い」取引の総勘定元帳への影響における「Posting Period」または取引日付からキャプチャされます。
取得
顧客支払いトランザクションからのGL計上日を使用します。
イベントタイプ
explicit
|
|||
|
督促手続き開始済み
|
期日超過請求書に対する正式な督促または債権回収プロセスの開始を表し、これには複数のステップが含まれる場合があります。これは、特定の督促レベルが請求書に割り当てられたときに捕捉されます。 | ||
|
その重要性
正式な督促の開始を追跡することは、督促の遵守状況と有効性を測定するのに役立ちます。これは、異なる督促戦略が支払い行動にどのように影響するかを分析するための重要なマイルストーンです。
取得元
請求書または顧客レコードの「督促レベル」が最初にゼロ以外または初期の督促状態に設定された日付から推測されます。
取得
督促レベルフィールドが変更されたときのタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
紛争登録済み
|
顧客が請求書に正式に異議を申し立て、標準的な回収プロセスが一時停止されたことを示します。これは通常、請求書のステータスフィールドが「紛争中」の状態に変更されたことから推測されます。 | ||
|
その重要性
このイベントは、紛争解決時間を測定するための出発点です。頻繁な紛争を特定することは、請求または販売プロセスにおける根本的な問題を明らかにする可能性があります。
取得元
システムログ、またはカスタムの「請求書ステータス」フィールドが「紛争中」や「係争中」のような値にタイムスタンプ付きで変更されたことから推測されます。
取得
ステータスフィールドが紛争を反映するように更新されたときのタイムスタンプ。
イベントタイプ
inferred
|
|||
|
紛争解決済み
|
顧客の紛争解決を示し、回収プロセスを再開するか、請求書を決済できるようにします。これは、請求書ステータスが「紛争中」からアクティブな状態に戻されたときに推測されます。 | ||
|
その重要性
これは紛争解決サイクルタイムを測定するための終点です。効率的な紛争解決は、顧客満足度を維持し、キャッシュフローを加速させるために不可欠です。
取得元
システムログ、またはカスタムの「請求書ステータス」フィールドが「紛争中」から「オープン」や「解決済み」のような値にタイムスタンプ付きで変更されたことから推測されます。
取得
ステータスフィールドが解決を示すように更新されたときのタイムスタンプ。
イベントタイプ
inferred
|
|||
|
顧客へ請求書送付済み
|
請求書が顧客に(通常はメールで)伝達された時点を表します。これは多くの場合、請求書取引に関連する送信済み通信を追跡するシステムログから推測されます。 | ||
|
その重要性
この活動を追跡することで、請求書作成から顧客への通知までの遅延を特定でき、これは支払い時間に影響を与える可能性があります。請求書通知プロセスの効率性に関する洞察を提供します。
取得元
請求書レコードから送信されたメールの日付から推測されます。これは、請求書取引のコミュニケーション > メッセージサブタブで見つけることができます。
取得
請求書にリンクされた「メッセージ」レコードのタイムスタンプを使用します。
イベントタイプ
inferred
|
|||