経費管理データ``テンプレート

Expensify
経費管理`データ``テンプレート`

経費管理データ``テンプレート

この`テンプレート`は、経費管理プロセスを分析するために必要な`データ`を収集するための明確な`ロードマップ`を提供します。収集すべき重要な`属性`、追跡すべき主要な`アクティビティ`、そしてExpensify`システム`からこの情報を抽出するための実用的なガイダンスを概説しています。この`リソース`を使用して、強力なプロセスマイニング`インサイト`のための`データ`を準備してください。
  • 包括的な分析のために収集を推奨する`属性`
  • 正確なプロセスディスカバリのために追跡すべき主要なアクティビティ
  • `データ`抽出のための実用的なガイダンス
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

経費管理属性

これらは、包括的な経費管理分析と最適化のために`イベントログ`に含めることを推奨する`データフィールド`です。
3 必須 5 推奨 13 任意
名前 説明
アクティビティ名
ActivityName
経費報告書に関して特定の時点で発生したビジネス`イベント`の名前。
説明

アクティビティ名とは、「経費報告書提出済み」や「マネージャー承認済み」など、経費管理プロセスにおける特定のステップマイルストーンを記述するものです。これはプロセスマップバックボーンを形成し、アナリストがワークフローを可視化し、一般的なパスを特定し、逸脱やボトルネックを発見することを可能にします。アクティビティの順序を分析することは、プロセスの効率性とコンプライアンスを理解する上で不可欠です。

その重要性

この属性は、プロセスマップにおけるステップを定義し、プロセスフロー、バリエーション、手戻りループを可視化し分析することを可能にします。

取得元

この属性は通常、Expensifyからの報告書ステータス変更、コメント、または履歴ログ``エントリを標準化されたアクティビティリストマッピングすることによって導出されます。

経費レポート提出済みマネージャー承認経理部門却下済み精算実行済み
イベント日時
EventTime
経費報告書に関して特定の`アクティビティ`または`イベント`が発生した日時を示す`タイムスタンプ`。
説明

イベントタイムは、プロセス内の各アクティビティの正確な日付と時刻を提供します。この時間情報は、サイクルタイム、期間、および異なるステップ間の待機時間を計算するために不可欠です。これにより、ボトルネック、時間の経過に伴うパフォーマンス傾向、およびサービスレベル契約へのコンプライアンスの分析が可能になります。正確なタイムスタンプがなければ、プロセスマイニング分析はフローディスカバリに限定されます。

その重要性

タイムスタンプは、すべての時間ベースの分析にとって不可欠です。サイクルタイムの計算、ボトルネックの特定、プロセスパフォーマンスの監視などが含まれます。

取得元

これは、Expensify報告書データにおける各履歴ログ``エントリまたはステータス変更に関連付けられた作成タイムスタンプです。

2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:12:05Z
経費レポートID
ExpenseReportId
経費報告書の一意の識別子で、提出から精算までのすべての関連`アクティビティ`を`グループ`化します。
説明

経費報告書IDは、経費管理プロセスの主要なケース識別子です。各IDは、従業員が承認と精算のために提出した単一の経費のまとまりを表します。この属性は、経費報告書のエンドツーエンドジャーニーを追跡するために不可欠であり、すべての提出、承認、却下、支払いを含むその全ライフサイクルの再構築を可能にします。

その重要性

すべての関連イベントを単一のプロセスインスタンスに集約することを可能にし、これはあらゆるプロセスマイニング分析の基礎となります。

取得元

これは経費報告書データ``オブジェクトの主キーであり、Expensify API報告書エンドポイントを介して「reportID」として利用できることが多いです。

RPT_84321RPT_99012RPT_10573
報告書合計金額
ReportTotalAmount
経費報告書の合計金額。
説明

この属性は、単一の経費報告書に含まれるすべての経費の合計を表します。これは、追加の精査が必要な高額経費や、異なる承認パスをたどる経費を特定するなど、さまざまな分析に使用される重要な財務メトリックです。また、財務報告や組織全体の支出パターンを理解するためにも使用されます。

その重要性

高額な経費レポートの分析を可能にし、支出傾向を特定するのに役立ち、財務およびコンプライアンスダッシュボードにとって不可欠です。

取得元

Expensifyレポートオブジェクトで利用可能であり、しばしば「total」または「amount」と命名されています。

150.752500.0089.50
従業員部門
EmployeeDepartment
申請者が所属する事業部門または部署。
説明

この属性は、経費報告書を提出する従業員の組織部門(「営業部」、「エンジニアリング部」、「マーケティング部」など)を示します。これは分析にとって不可欠なディメンションであり、ビジネスの異なる部門間でサイクルタイム、却下率、規程コンプライアンスの比較を可能にします。これにより、部門固有の問題や研修の必要性を特定するのに役立ちます。

その重要性

強力なドリルダウン分析を可能にし、異なる事業部門間でプロセスパフォーマンスとコンプライアンスを比較できます。

取得元

この情報は、報告書のタグとして、またはExpensifyにおける申請者のユーザー``プロファイルに関連付けられて保存されている場合があります。外部のHR``システムからのエンリッチメントデータの補完)が必要になることもあります。

営業マーケティングエンジニアリング財務
承認者
Approver
経費報告書の承認または却下を担当する`ユーザー`の名前または`ID`。
説明

承認者属性は、提出された経費報告書に対して行動を起こすマネージャーまたは経理チーム``メンバーを特定します。これは、承認時間、却下率、ワークロード配分など、承認者固有の行動を分析するために不可欠です。承認者のパフォーマンスを理解することは、研修の必要性を特定し、ワークロードを再配分し、承認プロセスを効率化するのに役立ちます。

その重要性

この属性は、承認ボトルネックワークロード配分、および承認者固有の却下率を分析するための鍵となります。

取得元

この情報は、報告書の履歴またはワークフロー``ログにあり、多くの場合、承認または却下のイベントに関連付けられています。このフィールドは「managerEmail」などとラベル付けされている場合があります。

jane.doe@example.comjohn.smith@example.comfinance.approver@example.com
提出者
Submitter
経費報告書を作成し、提出した従業員。
説明

申請者属性は、経費を発生させ、精算を求めている従業員を特定します。この情報は、従業員、部門、または役割ごとの経費パターンを分析するために使用されます。どの従業員またはグループが最も遅延を経験しているか、または最も高い規程違反率を持っているかについての疑問に答えるのに役立ち、より良い従業員エクスペリエンス分析に貢献します。

その重要性

従業員の視点からプロセスパフォーマンスを分析することを可能にし、頻繁な問題や遅延があるグループを特定するのに役立ちます。

取得元

これは経費報告書オブジェクトの主要フィールドであり、通常は「policyEmail」、「submitterEmail」、または「employeeEmail」とラベル付けされています。

sara.jones@example.comkevin.lee@example.commaria.garcia@example.com
規程違反`フラグ`
PolicyViolationFlag
レポートがポリシー違反としてフラグ付けされている場合に真となる真偽値`インジケーター`です。
説明

このフラグは、経費報告書が支出上限の超過や領収書の欠如など、1つ以上の規程違反をトリガーしたかどうかを示します。Expensifyの自動システムはしばしばこれらの問題をフラグ付けします。この属性は、規程違反オーバービュー``ダッシュボードにとって不可欠であり、コンプライアンスの問題を定量化し、改善ターゲット領域を特定するのに役立ちます。

その重要性

ポリシーコンプライアンスを直接測定し、追加の精査が必要なレポートを特定するのに役立ち、コンプライアンスダッシュボードの主要な入力となります。

取得元

Expensifyのレポートには、hasViolationsのような特定のフィールドやステータス、あるいは同様の真偽値フラグが含まれていることが多く、これが違反を示します。

truefalse
イベントの終了時刻
EventEndTime
特定の`アクティビティ`が終了した`タイムスタンプ`。測定可能な期間を持つ`アクティビティ`に有用です。
説明

経費管理における多くのアクティビティは瞬時に行われますが、「マネージャー審査」のような一部のアクティビティは開始時刻と終了時刻をモデル化できます。イベント終了時刻は、そのようなアクティビティの完了を示します。これは開始時刻と組み合わせて、個々のステップの正確な処理時間を計算するために使用され、時間の費やされ方についてより詳細な視点を提供します。

その重要性

アクティビティ処理時間の計算を可能にし、実作業時間と待機時間を区別するのに役立ちます。

取得元

これは通常、直接的なフィールドではありません。同じケースに対するシーケンス内の次のイベントタイムスタンプを取得することによって導出されます。

2023-10-26T10:05:12Z2023-10-27T15:00:00Z
ソースシステム
SourceSystem
データを抽出した元システム。
説明

この属性は、プロセスデータオリジンを特定します。このケースでは「Expensify」です。これはデータガバナンスにとって重要であり、特に複数のシステムからのデータが結合される環境ではなおさらです。データの来歴を追跡し、プロセスのコンテキストを理解するのに役立ちます。

その重要性

データの来歴にとって重要なコンテキストを提供し、複数のソース``システムからのデータが同じ環境にロードされる場合に、プロセスを区別するのに役立ちます。

取得元

これはデータ変換プロセス中に付加されるべき静的な値(「Expensify」)です。

ExpensifyExpensifyAPI-v2.0
一次承認であるか
IsFirstPassApproval
レポートが却下や修正なしに承認された場合に真となる算出`フラグ`です。
説明

このブール``フラグは、各経費報告書が却下や修正のための差し戻しなどの負の結果なしに承認プロセスを通過したかどうかを判断するために計算されます。これは、プロセス品質と効率の直接的な尺度であり、一次承認率KPIに直接影響します。高い割合は、申請の質が高く、規程がよく理解されていることを示します。

その重要性

初期提出の品質と承認フローの効率を直接測定し、手戻りの頻度を強調します。

取得元

これは、特定のExpenseReportIdに対するアクティビティのシーケンスをチェックすることで計算されます。シーケンスに「マネージャー却下」、「経理却下」、または「報告書が差し戻しされました」が含まれていない場合、フラグtrueになります。

truefalse
最終データ更新
LastDataUpdate
このレコードのデータがソースシステムから最後に更新された日時を示すタイムスタンプ。
説明

この属性は、データがプロセスマイニングツールに最後に抽出・更新された日時を記録します。これはデータの鮮度に関する透明性を提供し、分析のカレントさを理解するために不可欠です。これにより、ユーザーインサイトを信頼し、タイムリーなデータに基づいた情報ディシジョン(意思決定)を行うのに役立ちます。

その重要性

プロセス分析の関連性と正確性にとって極めて重要であるデータの鮮度を、ユーザーが認識していることを保証します。

取得元

これは通常、データ抽出ジョブタイムスタンプであり、データ変換(ETL)プロセス中に付加されます。

2023-11-20T08:00:00Z2023-11-21T08:00:00Z
処理時間
ProcessingTime
単一の`アクティビティ`に費やされた時間の長さ。
説明

処理時間(Processing Time)は、アクティビティの開始時刻と終了時刻の間の時間を測定する計算されたメトリックです。これは、タスクに費やされたアクティブな時間を表します。例えば、マネージャーが報告書を承認する前に開いていた時間などを測定できます。このメトリックは、アクティブな作業時間と待機時間を区別するために使用され、プロセスの効率性に関するより深いインサイトを提供します。

その重要性

実作業時間と待機時間を区別するのに役立ち、ボトルネックのより正確な特定を可能にします。

取得元

これは、データ変換中にEventEndTimeからEventTimeを減算することによって計算されます。

864003600600
却下理由
RejectionReason
承認者が経費報告書を却下したり、修正のために差し戻したりする際に提供する理由。
説明

経費報告書が却下された場合、承認者は通常その理由を提供できます。このテキスト``属性は、その理由を記録し、報告書が承認されない理由について貴重な定性的インサイトを提供します。却下理由を分析することで、一般的な提出エラー、不明確な規程、または従業員がさらなる研修を必要とする領域を特定するのに役立ち、一次承認率の向上への取り組みを直接的に支援します。

その重要性

手戻りが発生する理由を説明する定性データを提供します。これは、報告書却下の根本原因分析にとって非常に重要です。

取得元

この情報は通常、却下イベントに関連付けられたコメントまたは履歴ログにあります。

75ドルを超える品目の領収書が不足しています誤った経費カテゴリが選択されました重複経費が提出されました
合計サイクルタイム
TotalCycleTime
経費報告書に関して最初の`イベント`の作成から最後の`イベント`の完了までに経過した合計時間。
説明

サイクルタイムは、単一の報告書に対する経費管理プロセスのエンドツーエンドの期間を測定するケース``レベルの計算です。これは、プロセス全体の効率性のための主要業績評価指標(KPI)です。このメトリックは、最初のアクティビティ(例:「経費報告書作成済み」)のタイムスタンプと最後のアクティビティ(例:「精算実行済み」)のタイムスタンプの差を取ることによって計算されます。

その重要性

これは、プロセス全体の速度を測定し、システム的な問題を示す可能性のある長期実行中のケースを特定するための主要なKPIです。

取得元

この属性は、各ExpenseReportIdについて(MAX(EventTime) - MIN(EventTime)) を取得することによって計算されます。

6048001209600259200
報告書`ステータス`
ReportStatus
経費報告書の`ライフサイクル`における現在の`ステータス`。
説明

報告書ステータスは、「OPEN」(オープン)、「SUBMITTED」(提出済み)、「APPROVED」(承認済み)、「REIMBURSED」(精算済み)、「CLOSED」(クローズ済み)など、プロセスにおける経費報告書の現在の位置を示します。これは報告書の進捗状況のスナップショットを提供します。プロセスマイニングでは、この属性アクティビティ名を導出するためによく使用されますが、報告書が各ステータスでどれくらいの時間を費やしているかを分析するためのディメンションとしても使用できます。

その重要性

ケースの現在のステータスを示し、プロセスマイニングのアクティビティログを導き出すための情報源となることが多いです。

取得元

これはExpensify報告書オブジェクトの標準フィールドであり、しばしば「status」または「state」と名付けられています。

SUBMITTEDAPPROVEDREIMBURSED`CLOSED`
支払方法
PaymentMethod
従業員に精算を行うための方法。
説明

この属性は、従業員がどのように精算されたか(「直接預金(ACH)」、「PayPal」、「法人クレジットカード」など)を記述します。支払い方法を分析することは、プロセスにおける精算部分を理解するのに役立ち、特に特定のメソッドがより長い遅延に関連している場合に有効です。プロセスの最終ステップにさらなるコンテキストを提供します。

その重要性

精算フェーズコンテキストを提供し、異なる支払い方法に関連する遅延やコストを分析するために使用できます。

取得元

この情報は通常、クローズされた報告書の精算詳細内で利用可能です。

ACHPayPalBill.com
監査結果
AuditOutcome
経費報告書に対して実施された手動または自動監査の結果。
説明

この属性は、監査の結果(「合格」、「不合格」、「所見付きで合格」など)を記録します。これは、すべての報告書またはサンプルに対して、経費プロセスに正式な監査ステップがある企業にとって関連性があります。監査結果を分析することは、コンプライアンス``レベルと既存のコントロールの有効性を理解するのに役立ちます。

その重要性

コンプライアンスチェックの結果を直接測定し、監査プロセスの有効性を分析するために不可欠です。

取得元

これは概念的な属性であるか、タグとして、またはコメント内に保存されている可能性があります。その存在は、Expensify内での会社の特定のプロセスコンフィグレーションに依存します。

合格失敗 - ポリシー違反所見付きで合格
経費カテゴリ
ExpenseCategory
報告書内の個々の経費明細項目に割り当てられた`カテゴリ`。
説明

経費カテゴリは、「交通費」、「接待交際費」、「ソフトウェア費」など、支出の種類を分類します。レポートには複数のカテゴリを含めることができますが、この属性は、例えば最も頻繁なカテゴリや最高額のカテゴリを採用することで、しばしばレポートレベルに非正規化されます。これは支出傾向の分析や特定の種類の経費に対するポリシーコンプライアンスのチェックに使用されます。

その重要性

支出パターン、ポリシー違反、および異なる種類の経費の承認時間を分析するのに役立ちます。

取得元

レポート内の明細項目レベル(「トランザクション」)で見つかります。ケースレベルに割り当てるには、集計またはビジネスルールが必要です。

航空運賃宿泊費食事代オフィス用品
規程名
PolicyName
報告書に適用された経費規程の名前。
説明

Expensifyでは、異なる従業員グループが異なる経費ポリシーの対象となる可能性があります。この属性は、経費レポートのルールを管理する特定のポリシーを識別します。これは分析にとって重要な側面であり、異なるルールと承認ワークフローを持つ可能性のある異なるポリシー間でのコンプライアンスと効率性を比較できるためです。

その重要性

適用されるルールセットによってプロセス分析をセグメント化することを可能にし、異なるポリシーによって引き起こされる差異を理解するために不可欠です。

取得元

これはExpensifyの報告書オブジェクトの標準フィールドであり、しばしば「policyID」または「policyName」と名付けられています。

米国従業員規程UK営業`チーム`規程役員旅費規程
通貨
Currency
経費報告書内の金額の通貨`コード`。
説明

通貨属性は、報告書合計金額の通貨(例:USD、EUR、GBP)を指定します。これは、複数の国で事業を展開する組織にとって、財務データが正しく解釈されることを保証するために極めて重要です。不正確な集計を避けるため、すべての金銭的価値はこの属性と合わせて分析されるべきです。

その重要性

すべての金額に必要なコンテキストを提供することで、正確な財務分析とレポート作成を保証します。

取得元

これはExpensify報告書オブジェクトの標準フィールドであり、しばしば「currency」と呼ばれます。

USDEURGBPCAD
必須 推奨 任意

経費管理アクティビティ

正確なプロセス発見とボトルネック特定のため、イベントログに記録すべき主要ステップとマイルストーンは次のとおりです。
7 推奨 6 任意
アクティビティ 説明
マネージャー承認
直属のマネージャーまたは一次承認者が経費報告書を審査し、承認しました。この`イベント`は承認`ワークフロー``ログ`から取得され、承認者の行動と`タイムスタンプ`が記録されています。
その重要性

承認プロセスにおける重要な節目です。提出からこのイベントまでの時間を分析することで、マネージャー関連のボトルネックを特定し、マネージャー承認サイクルタイムKPIを測定するのに役立ちます。

取得元

レポートの履歴または監査証跡から捕捉され、そこには承認アクション、承認者の名前、およびタイムスタンプが明示的に記録されています。

取得

レポートのワークフロー履歴に個別の承認アクションとして記録されます。

イベントタイプ explicit
報告書が差し戻しされました
マネージャーまたは経理部門のいずれかの承認者が、修正または追加情報を求めるためにレポートを従業員に返却します。これは通常、「処理中」の後に`ステータス`が「オープン」に変更されたことから推測されます。
その重要性

このアクティビティは、非効率の主な原因である手戻りを表します。これを追跡することで、手戻りループを定量化し、手戻り率KPIを測定し、根本原因を特定するのに役立ちます。

取得元

レポートステータスが「処理中」または「提出済み」から「オープン」に戻る変更から推測されます。このステータス変更のタイムスタンプイベントを示します。

取得

レポートステータスが「処理中」から「オープン」に戻る変更から推測されます。

イベントタイプ inferred
報告書クローズ済み
精算や会計同期を含むすべての処理が完了した後、経費報告書は`システム`内で正式にクローズされます。この`イベント`は通常、「クローズ済み」のような最終的な`ステータス`から推測されます。
その重要性

プロセスに明確な終点を提供します(精算とは別)。これは最終的な会計処理やアーカイブ``ステップの分析に役立ちます。

取得元

レポートステータスが「クローズ済み」のような最終状態に変更されることから推測されます。これは通常、払い戻しと会計エクスポートの後で発生します。

取得

レポートステータスが「クローズ済み」に変更されること、および関連するタイムスタンプから推測されます。

イベントタイプ inferred
精算実行済み
支払いが従業員に正常に送金され、プロセスの精算部分が完了しました。これは、支払い処理`ログ`またはExpensifyにおける最終`ステータス`更新から取得されます。
その重要性

これは、従業員向けのサイクルタイムを測定するための主要なエンドポイントです。「平均経費報告書サイクルタイム」と「平均精算リードタイム``KPI」にとって不可欠です。

取得元

レポートステータスが「払い戻し済み」に変更されることから推測されます。Expensifyの支払いシステムとの連携により、このステータス変更のタイムスタンプが提供されます。

取得

レポートステータスが「払い戻し済み」に変更されること、および関連するタイムスタンプから推測されます。

イベントタイプ inferred
経理部門承認済み
経理部門または最終承認者が経費報告書を審査し、最終承認を与えました。この行動は`ワークフロー`履歴に記録され、通常は報告書`ステータス`を「承認済み」に変更します。
その重要性

これは精算前の最終承認ゲートです。このステップにかかる時間は、全体のサイクルタイムと「平均精算リードタイム``KPI」にとって不可欠です。

取得元

レポートの履歴または監査証跡から捕捉され、そこには最終承認アクション、経理チームの承認者、およびタイムスタンプが記録されています。

取得

レポートのワークフロー履歴に個別の最終承認アクションとして記録されます。

イベントタイプ explicit
経費レポート作成済み
従業員による新しい経費レポートの開始を示します。これは通常、Expensifyにレポートが最初に保存されたときの作成`タイムスタンプ`付きの明示的な`イベント`として捕捉されます。
その重要性

このアクティビティは、すべてのプロセス分析の開始点であり、作成から精算までの総サイクルタイムを測定するために不可欠です。

取得元

このイベントは、Expensifyの報告書履歴または監査ログにある報告書作成タイムスタンプから取得されます。すべての報告書オブジェクトには作成日があります。

取得

経費レポートの初回作成および保存時に記録されます。

イベントタイプ explicit
経費レポート提出済み
従業員は、承認`ワークフロー`を開始するために完成した経費報告書を正式に提出します。これは`データ`入力から審査プロセスへの重要な移行であり、通常は`ステータス`変更と提出`タイムスタンプ`によって記録されます。
その重要性

このアクティビティは、承認サイクルトリガーする重要なマイルストーンです。これは、マネージャーと経理の審査時間を測定するための開始点として機能します。

取得元

レポートのステータスが「オープン」または「下書き」から「処理中」または「提出済み」に変更されること、およびこの変更に関連するタイムスタンプから推測されます。

取得

ステータスが「処理中」に変更されること、および関連する提出タイムスタンプから推測されます。

イベントタイプ inferred
マネージャー却下済み
一次承認者が経費報告書を審査し、却下したため、通常はプロセスが停止します。これは`ワークフロー``ログ`に却下`イベント`として記録され、多くの場合、理由が提供されます。
その重要性

却下イベントを分析することは、経費レポート却下率KPIを理解する上で重要です。これにより、失敗の一般的な理由とプロセス改善が必要な領域を特定するのに役立ちます。

取得元

レポートの履歴から捕捉され、却下アクション、却下者の身元、およびタイムスタンプが記録されています。レポートステータスは通常「却下済み」に変わります。

取得

レポートのワークフロー履歴に個別の却下アクションとして記録されます。

イベントタイプ explicit
レポートに経費を追加
スキャンされた領収書や手入力された経費など、従業員が特定の明細項目を報告書に追加する行為を表します。これは報告書の詳細な履歴`ログ`に`エントリ`として記録されます。
その重要性

レポート作成から経費が追加されるまでの時間を分析することで、従業員による証拠収集や提出準備における遅延が明らかになることがあります。

取得元

経費レポートの監査証跡または履歴から取得され、個別の経費エントリーの追加などのアクションが記録されます。

取得

新しい経費明細が追加されるたびに、レポートの履歴に記録されます。

イベントタイプ explicit
会計計上済み
経費報告書からの財務`データ`は、会社の会計`システム`または`ERP`にエクスポートされ、転記されました。これは財務記録の観点からプロセスが完了したことを示す最終`ステップ`です。
その重要性

財務システムにおける経費報告書の最終的なクローズを表します。これは、完全なエンドツーエンドプロセスを測定し、データ同期を確保するために重要です。

取得元

Expensifyと会計ソフトウェア間の連携ログから捕捉されます。これは2つのシステムからのデータを結合する必要がある場合があります。

取得

データが会計システムに正常に同期されたときに、連携履歴に記録されます。

イベントタイプ explicit
精算予定
最終承認後、経費レポートは支払い処理のためにキューに追加されます。この`イベント`は承認から支払い段階への移行を示し、レポート`ステータス`が「Reimbursing」に変わったときにしばしば捕捉されます。
その重要性

払い戻しリードタイムの開始を示します。これと実際の支払いとの間の期間を分析することで、支払いプロセスにおける遅延を特定するのに役立ちます。

取得元

レポートステータスが「払い戻し中」または「支払い処理中」に変更されること、および関連するタイムスタンプから推測されます。

取得

レポートが支払い処理のためにキューに追加されたことを示すステータス変更から推測されます。

イベントタイプ inferred
経理部門却下済み
経理部門が経費報告書を審査し、却下したため、精算プロセスが停止しました。この`イベント`は`ワークフロー`履歴に`タイムスタンプ`と却下理由とともに記録されます。
その重要性

最終審査段階でのボトルネックと失敗の原因を特定します。これは全体的な却下率とコンプライアンス問題を分析するために不可欠です。

取得元

レポートの履歴から捕捉され、経理チームによる却下アクションが、タイムスタンプとユーザーとともに記録されています。

取得

レポートのワークフロー履歴に個別の却下アクションとして記録されます。

イベントタイプ explicit
規程違反を検出
自動チェックにより、予算超過や領収書不足など、会社ポリシーに違反する経費が特定されます。この`イベント`は、レポートまたは明細項目に特定のポリシー違反`フラグ`が設定されたときに捕捉されます。
その重要性

コンプライアンス問題を強調し、どのポリシーが頻繁に違反されているかを特定するのに役立ち、ターゲットを絞ったトレーニングやポリシーの明確化を可能にします。これはポリシー違反数KPIにとって重要です。

取得元

経費レポートデータで「ポリシー違反」フラグまたは属性がtrueに設定されることから推測されます。タイムスタンプは、このフラグが設定された時点に対応します。

取得

レポートのポリシー違反属性が更新されたときのタイムスタンプから推測されます。

イベントタイプ inferred
推奨 任意

抽出ガイド

Expensifyから`データ`を取得する方法