経費管理データテンプレート
経費管理データテンプレート
- 詳細な分析に必要な推奨属性
- 正確なプロセスの把握に必要な主要アクティビティ
- データ抽出の手順
経費管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ名
ActivityName
|
経費レポートについて、特定の時点で発生した業務イベントの名前です。 | ||
|
説明
アクティビティ名は、「経費レポート申請」や「マネージャー承認済み」など、経費管理プロセスの具体的なステップやマイルストーンを表します。プロセスマップの基盤となり、業務の流れやよくある経路を可視化し、逸脱やボトルネックを見つけるのに役立ちます。アクティビティの順序を分析することは、プロセスの効率性とコンプライアンスを把握するうえで欠かせません。
重要な理由
この属性によってプロセスマップのステップが定まり、プロセスの流れやバリアント、手戻りのループを可視化して分析できます。
入手先
通常、この属性はExpensifyのレポートのステータス変更、コメント、履歴ログを、標準化されたアクティビティ一覧に対応付けて作成します。
例
経費報告書を提出マネージャー承認済み経理却下払い戻し実行
|
|||
|
イベント時刻
EventTime
|
経費レポートの特定のアクティビティまたはイベントが発生した日時を示すタイムスタンプです。 | ||
|
説明
イベント時刻には、プロセス内の各アクティビティの正確な日時が記録されます。この時間情報は、サイクルタイムや所要時間、ステップ間の待ち時間の計算に欠かせません。ボトルネックや時間の経過に伴うパフォーマンスの傾向、サービスレベル合意の遵守状況も分析できます。正確なタイムスタンプがなければ、プロセスマイニングで分析できるのは業務の流れの把握に限られます。
重要な理由
サイクルタイムの計算、ボトルネックの特定、プロセスパフォーマンスの監視など、時間に基づく分析にはタイムスタンプが欠かせません。
入手先
Expensifyのレポートデータにある各履歴ログ項目またはステータス変更に記録された作成日時です。
例
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:12:05Z
|
|||
|
経費レポートID
ExpenseReportId
|
経費レポートを一意に識別するIDです。申請から払い戻しまでの関連アクティビティをまとめます。 | ||
|
説明
経費レポートIDは、経費管理プロセスにおける主要なケース識別子です。各IDは、従業員が承認と払い戻しのために申請した一連の経費を表します。この属性を使うと、申請、承認、却下、支払いを含む経費レポートの全ライフサイクルを再構成し、追跡できます。
重要な理由
関連するすべてのイベントを1つのプロセスインスタンスに集約できます。これは、プロセスマイニング分析の基盤となります。
入手先
経費レポートのデータオブジェクトにおける主キーです。Expensify APIのreportsエンドポイントでは、多くの場合「reportID」として取得できます。
例
RPT_84321RPT_99012RPT_10573
|
|||
|
ポリシー違反フラグ
PolicyViolationFlag
|
レポートがポリシー違反としてフラグ付けされている場合にtrueとなる真偽値です。 | ||
|
説明
このフラグは、支出上限の超過や領収書の不足など、経費レポートに1つ以上のポリシー違反があるかを示します。Expensifyの自動システムが問題を検出してフラグを付けることがよくあります。コンプライアンス上の問題を把握し、改善対象を絞り込むための「ポリシー違反の概要」ダッシュボードに欠かせない属性です。
重要な理由
ポリシーの遵守状況を直接測定し、追加確認が必要なレポートを特定できます。コンプライアンスのダッシュボードに欠かせないデータです。
入手先
Expensifyのレポートには、「hasViolations」など、違反を示す専用の項目や真偽値のフラグが含まれていることがよくあります。
例
truefalse
|
|||
|
レポート合計金額
ReportTotalAmount
|
経費レポートの合計金額です。 | ||
|
説明
この属性は、1つの経費レポートに含まれるすべての経費の合計を表します。追加確認が必要な高額経費や、異なる承認経路をたどる経費の特定など、さまざまな分析に使う重要な財務指標です。財務報告や、組織全体の支出傾向の把握にも利用できます。
重要な理由
高額な経費レポートの分析や支出傾向の把握に役立ち、財務・コンプライアンスのダッシュボードにも欠かせません。
入手先
Expensifyのreportsオブジェクトで取得できます。多くの場合、「total」または「amount」という名前の項目です。
例
150.752500.0089.50
|
|||
|
従業員の部門
EmployeeDepartment
|
申請者が所属する事業部門または組織単位です。 | ||
|
説明
この属性は、経費レポートを申請した従業員の所属部門を示します。たとえば、「営業」「エンジニアリング」「マーケティング」などです。部門間でサイクルタイム、却下率、ポリシーの遵守状況を比較するための重要な分析軸です。部門固有の問題や研修の必要性を特定するのに役立ちます。
重要な理由
事業部門ごとにプロセスパフォーマンスやコンプライアンスを比較するドリルダウン分析に役立ちます。
入手先
レポートのタグ、またはExpensifyの申請者のユーザープロフィールに保存されている場合があります。外部の人事システムからデータを補う必要があることもあります。
例
営業マーケティングエンジニアリング経理
|
|||
|
承認者
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
|
|||
|
イベント終了時刻
EventEndTime
|
特定のアクティビティが終了した日時を示すタイムスタンプです。所要時間を測定できるアクティビティに役立ちます。 | ||
|
説明
経費管理の多くのアクティビティは瞬時に完了しますが、「マネージャー確認」などは開始時刻と終了時刻を設定してモデル化できます。イベント終了時刻は、そのアクティビティの完了時刻を示します。開始時刻とあわせて使うことで、個々のステップの正確な処理時間を計算し、どの段階に時間がかかっているかを詳しく把握できます。
重要な理由
アクティビティの処理時間を計算し、実作業時間と待ち時間を区別できます。
入手先
通常、直接取得できる項目ではありません。同じケースの次のイベントのタイムスタンプから算出します。
例
2023-10-26T10:05:12Z2023-10-27T15:00:00Z
|
|||
|
ソースシステム
SourceSystem
|
データの抽出元となるシステムです。 | ||
|
説明
この属性はプロセスデータの取得元を示します。この場合は「Expensify」です。複数のシステムのデータを組み合わせる環境では、データガバナンスの観点から重要です。データの来歴を追跡し、プロセスのコンテキストを把握するのに役立ちます。
重要な理由
データの来歴を把握するための重要なコンテキストを提供します。複数のソースシステムのデータを同じ環境に読み込む場合、プロセスを区別するのにも役立ちます。
入手先
「Expensify」という固定値で、データ変換の際に追加します。
例
ExpensifyExpensifyAPI-v2.0
|
|||
|
ポリシー名
PolicyName
|
レポートに適用された経費ポリシーの名前です。 | ||
|
説明
Expensifyでは、従業員のグループごとに異なる経費ポリシーを適用できます。この属性は、経費レポートに適用されるルールを定めたポリシーを示します。ポリシーごとにルールや承認ワークフローが異なる場合があるため、ポリシー間でコンプライアンスと効率性を比較する重要な分析軸です。
重要な理由
適用されるルールごとにプロセス分析を分けられるため、ポリシーの違いによる変化を把握するうえで欠かせません。
入手先
Expensifyのレポートオブジェクトにある標準項目です。通常、「policyID」または「policyName」という名前が付いています。
例
米国従業員向けポリシー英国営業チーム向けポリシー役員出張ポリシー
|
|||
|
レポートステータス
ReportStatus
|
ライフサイクルにおける経費レポートの現在の状態です。 | ||
|
説明
レポートステータスは、「OPEN」「SUBMITTED」「APPROVED」「REIMBURSED」「CLOSED」など、プロセス内での経費レポートの現在の状態を示します。レポートの進捗状況を把握できます。プロセスマイニングでは、この属性からアクティビティ名を導出することがよくあります。また、各状態にレポートがとどまる時間を分析する軸としても使えます。
重要な理由
ケースの現在の状態を示します。プロセスマイニングのアクティビティログを作成する際に、元データとして使われることがよくあります。
入手先
Expensifyのレポートオブジェクトにある標準項目です。通常、「status」または「state」という名前が付いています。
例
申請済み承認済み払い戻し済み終了済み
|
|||
|
最終データ更新日時
LastDataUpdate
|
このレコードのデータがソースシステムから最後に更新された日時を示すタイムスタンプです。 | ||
|
説明
この属性には、データを最後に抽出し、プロセスマイニングツールで更新した日時が記録されます。データの鮮度を確認でき、分析結果がどの程度最新かを把握するうえで重要です。最新のデータに基づくインサイトへの信頼が高まり、適切な判断に役立ちます。
重要な理由
データがどの程度最新かを把握できるため、プロセス分析の関連性と正確性を保つうえで重要です。
入手先
通常、データ抽出ジョブのタイムスタンプを、データ変換(ETL)の際に追加します。
例
2023-11-20T08:00:00Z2023-11-21T08:00:00Z
|
|||
|
初回承認
IsFirstPassApproval
|
却下や修正がなくレポートが承認された場合にtrueとなる計算フラグです。 | ||
|
説明
このブール型フラグは、却下や修正のための差し戻しなどの否定的な結果を伴わずに、各経費精算レポートが承認プロセスを完了したかどうかを示します。プロセスの品質と効率を直接測定し、初回承認率のKPIに反映されます。数値が高い場合、申請の品質が高く、ポリシーがよく理解されていることを示します。
重要な理由
初回申請の品質と承認フローの効率を直接測定し、手戻りの頻度を明らかにします。
入手先
指定されたExpenseReportIdのアクティビティの順序を確認して算出します。「Manager Rejected」「Finance Rejected」「Report Sent Back For Revision」が含まれていない場合、フラグはtrueになります。
例
truefalse
|
|||
|
却下理由
RejectionReason
|
経費レポートを却下する場合や修正のために差し戻す場合に、承認者が記載する理由です。 | ||
|
説明
経費レポートを却下する際、承認者は通常、理由を記載できます。このテキスト属性には、承認されなかった理由に関する重要な定性的情報が記録されます。却下理由を分析すると、申請時によくある誤り、分かりにくいポリシー、従業員に追加研修が必要な領域を特定でき、初回承認率の改善に直接役立ちます。
重要な理由
手戻りが発生する理由を示す定性的なデータであり、レポート却下の根本原因を分析するうえで重要です。
入手先
通常、却下イベントに関連付けられたコメントまたは履歴ログに記録されています。
例
75ドルを超える明細の領収書が不足経費カテゴリの選択誤り経費の重複申請
|
|||
|
合計サイクルタイム
TotalCycleTime
|
経費精算レポートの最初のイベントが発生してから、最後のイベントが完了するまでの総経過時間。 | ||
|
説明
総サイクルタイムは、1件のレポートについて経費管理プロセスの開始から完了までにかかる時間を測定する、ケース単位の計算値です。プロセス全体の効率を測る重要業績評価指標(KPI)です。最初のアクティビティ(例:「経費精算レポートの作成」)と最後のアクティビティ(例:「払い戻しの実行」)のタイムスタンプの差として算出します。
重要な理由
プロセス全体の処理速度を測定し、組織的な問題の兆候となる長期化したケースを特定するための主要なKPIです。
入手先
各ExpenseReportIdについて、(MAX(EventTime) - MIN(EventTime))を計算して算出します。
例
6048001209600259200
|
|||
|
支払い方法
PaymentMethod
|
従業員への払い戻しに使われた方法です。 | ||
|
説明
この属性は、従業員への払い戻し方法を示します。たとえば、「銀行口座への直接振込(ACH)」「PayPal」「会社のクレジットカード」などです。支払い方法によって遅延が長くなる場合があるため、分析するとプロセスの払い戻し段階を把握できます。プロセスの最終段階に関する追加のコンテキストも得られます。
重要な理由
払い戻し段階のコンテキストを把握でき、支払い方法ごとの遅延やコストの分析に利用できます。
入手先
通常、終了済みレポートの払い戻し詳細から取得できます。
例
ACHPayPalBill.com
|
|||
|
監査結果
AuditOutcome
|
経費レポートに対して手動または自動で実施した監査の結果です。 | ||
|
説明
この属性には、「合格」「不合格」「指摘事項ありで合格」などの監査結果が記録されます。すべてのレポートまたは一部のレポートを対象に、経費プロセスで正式な監査を実施する企業に関係する属性です。監査結果を分析すると、コンプライアンスの水準や既存の統制の有効性を把握できます。
重要な理由
コンプライアンスチェックの結果を直接測定でき、監査プロセスの有効性を分析するうえで欠かせません。
入手先
概念上の属性であるか、タグやコメントに保存されている可能性があります。Expensifyでの会社固有のプロセス設定によって、存在するかどうかが異なります。
例
合格不合格:ポリシー違反指摘事項ありで合格
|
|||
|
経費カテゴリ
ExpenseCategory
|
レポート内の個々の経費明細に割り当てられたカテゴリです。 | ||
|
説明
経費カテゴリは、「交通費」「飲食・接待費」「ソフトウェア」など、支出の種類を分類します。1つのレポートに複数のカテゴリが含まれる場合、この属性は最も頻度の高いカテゴリや金額が最大のカテゴリを選ぶなどして、レポート単位に集約されることがあります。支出傾向の分析や、経費の種類ごとのポリシー遵守状況の確認に使います。
重要な理由
支出傾向やポリシー違反、経費の種類ごとの承認時間の分析に役立ちます。
入手先
レポート内の明細項目(「transactions」)に記録されています。ケース単位で扱うには、集約または業務ルールによる割り当てが必要です。
例
航空運賃宿泊費飲食費事務用品
|
|||
|
通貨
Currency
|
経費レポートの金額に使われる通貨コードです。 | ||
|
説明
通貨属性は、レポート合計金額の通貨を示します。たとえば、USD、EUR、GBPなどです。複数の国で事業を展開する組織では、財務データを正しく解釈するために欠かせません。誤った集計を防ぐため、すべての金額はこの属性とあわせて分析してください。
重要な理由
すべての金額の通貨を把握できるため、正確な財務分析と報告に役立ちます。
入手先
Expensifyのレポートオブジェクトにある標準項目です。通常、「currency」という名前が付いています。
例
USDEURGBPCAD
|
|||
経費管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
|
マネージャー承認済み
|
直属のマネージャーまたは一次承認者が経費レポートを確認し、承認しました。このイベントは、承認者の操作とタイムスタンプを記録する承認ワークフローのログから取得されます。 | ||
|
重要な理由
承認プロセスにおける重要なマイルストーンです。申請からこのイベントまでの時間を分析すると、マネージャーの承認に関するボトルネックを特定でき、マネージャー承認サイクルタイムの重要業績評価指標(KPI)を測定できます。
入手先
承認操作、承認者名、タイムスタンプが明示的に記録されたレポートの履歴または監査証跡から取得されます。
記録
レポートのワークフロー履歴に、個別の承認操作として記録されます。
イベントタイプ
explicit
|
|||
|
レポート終了
|
払い戻しや会計システムとの同期など、すべての処理が完了すると、経費レポートはシステム上で正式に終了します。通常、「終了済み」などの最終ステータスから判定します。 | ||
|
重要な理由
払い戻しとは別に、プロセスの明確な終了点を示します。最終的な会計処理やアーカイブの段階を分析する際に役立ちます。
入手先
レポートのステータスが「終了済み」などの最終状態に変わったことをもとに判定します。多くの場合、払い戻しと会計データのエクスポート後に発生します。
記録
レポートのステータスが「終了済み」に変わったことと、そのタイムスタンプから判定します。
イベントタイプ
inferred
|
|||
|
修正のため差し戻し
|
マネージャーまたは経理部門の承認者が、修正や追加情報の提出を求めてレポートを従業員に差し戻します。通常、「処理中」から「オープン」へのステータス変更をもとに判定します。 | ||
|
重要な理由
このアクティビティは手戻りを表し、業務効率を損なう主な要因の1つです。記録することで、手戻りの発生回数や手戻り率の重要業績評価指標(KPI)を測定し、根本原因を特定できます。
入手先
レポートのステータスが「処理中」または「申請済み」から「オープン」に戻ったことをもとに判定します。このステータス変更のタイムスタンプがイベント時刻になります。
記録
レポートのステータスが「処理中」から「オープン」に変わったことをもとに判定します。
イベントタイプ
inferred
|
|||
|
払い戻し実行
|
従業員への支払いが正常に送金され、プロセスの払い戻し部分が完了しました。このイベントは、支払い処理ログまたはExpensifyの最終ステータス更新から取得されます。 | ||
|
重要な理由
従業員の視点でサイクルタイムを測定する際の重要な終点です。経費レポートの平均サイクルタイムと平均払い戻しリードタイムの重要業績評価指標(KPI)を測定するうえで欠かせません。
入手先
レポートのステータスが「払い戻し済み」に変わったことをもとに判定します。Expensifyと支払いシステムの連携により、このステータス変更のタイムスタンプを取得できます。
記録
レポートのステータスが「払い戻し済み」に変わったことと、そのタイムスタンプから判定します。
イベントタイプ
inferred
|
|||
|
経理承認済み
|
経理部門または最終承認者が経費レポートを確認し、最終承認しました。この操作はワークフロー履歴に記録され、通常、レポートのステータスは「承認済み」に変わります。 | ||
|
重要な理由
払い戻し前の最終承認ゲートです。この段階にかかる時間は、プロセス全体のサイクルタイムと平均払い戻しリードタイムの重要業績評価指標(KPI)を測定するうえで重要です。
入手先
最終承認操作、経理チームの承認者、タイムスタンプが記録されたレポートの履歴または監査証跡から取得されます。
記録
レポートのワークフロー履歴に、個別の最終承認操作として記録されます。
イベントタイプ
explicit
|
|||
|
経費報告書を作成
|
従業員が新しい経費報告書を作成したことを示します。通常、Expensifyで報告書を初めて保存した時点の作成日時を、明示的なイベントとして記録します。 | ||
|
重要な理由
このアクティビティは、すべてのプロセス分析の起点です。作成から精算までのサイクルタイム全体を測定するうえで欠かせません。
入手先
このイベントは、Expensifyの報告書履歴または監査ログに記録された作成日時から取得します。すべての報告書オブジェクトに作成日があります。
記録
経費報告書を初めて作成して保存した時点で記録されます。
イベントタイプ
explicit
|
|||
|
経費報告書を提出
|
従業員が完成した経費報告書を正式に提出し、承認ワークフローが始まります。データ入力から確認プロセスへの重要な移行点であり、通常はステータスの変更と提出日時で記録されます。 | ||
|
重要な理由
このアクティビティは、承認サイクルを開始する重要な節目です。上司や経理部門による確認時間を測定する際の起点になります。
入手先
報告書のステータスが「オープン」または「下書き」から「処理中」または「提出済み」に変わったことと、その変更日時から推定します。
記録
ステータスが「処理中」に変わったことと、対応する提出日時から算出します。
イベントタイプ
inferred
|
|||
|
ポリシー違反を検出
|
自動チェックにより、予算超過や領収書の不足など、会社のポリシーに違反する経費を検出します。報告書または明細に特定のポリシー違反フラグが設定された時点で、このイベントが記録されます。 | ||
|
重要な理由
コンプライアンス上の問題を明らかにし、頻繁に違反されるポリシーを特定することで、対象を絞った研修やポリシーの明確化に役立ちます。ポリシー違反件数の重要業績評価指標(KPI)を測定するうえでも欠かせません。
入手先
経費報告書データで「ポリシー違反」フラグまたは属性がtrueに設定されたことから推定します。タイムスタンプは、このフラグが設定された日時に対応します。
記録
報告書のポリシー違反属性が更新された日時から算出します。
イベントタイプ
inferred
|
|||
|
マネージャー却下
|
一次承認者が経費レポートを確認して却下したため、通常はプロセスが停止します。この操作はワークフローのログに却下イベントとして記録され、多くの場合、理由も記載されます。 | ||
|
重要な理由
却下イベントの分析は、経費レポート却下率の重要業績評価指標(KPI)を把握するうえで重要です。よくある却下理由や、プロセスの改善が必要な領域を特定できます。
入手先
却下操作、却下者、タイムスタンプが記録されたレポートの履歴から取得されます。通常、レポートのステータスは「却下済み」に変わります。
記録
レポートのワークフロー履歴に、個別の却下操作として記録されます。
イベントタイプ
explicit
|
|||
|
会計システムに転記済み
|
経費レポートの財務データがエクスポートされ、会社の会計システムまたはERPに転記されました。財務記録の観点では、これがプロセスの最終段階です。 | ||
|
重要な理由
財務システムにおける経費レポートの最終処理を表します。プロセス全体の所要時間の測定や、データ同期の確認に役立ちます。
入手先
Expensifyと会計ソフトウェア間の連携ログから取得されます。2つのシステムのデータを組み合わせる必要がある場合があります。
記録
データが会計システムに正常に同期されると、連携履歴に記録されます。
イベントタイプ
explicit
|
|||
|
払い戻し予定
|
最終承認後、経費レポートは支払い処理の待ち行列に入ります。このイベントは承認段階から支払い段階への移行を示し、多くの場合、レポートのステータスが「払い戻し処理中」に変わった時点で記録されます。 | ||
|
重要な理由
払い戻しリードタイムの開始を示します。この時点から実際の支払いまでの時間を分析すると、支払い処理の遅れを特定できます。
入手先
レポートのステータスが「払い戻し処理中」または「支払い処理中」に変わったことと、そのタイムスタンプをもとに判定します。
記録
レポートが支払い待ちの状態になったことを示すステータス変更から判定します。
イベントタイプ
inferred
|
|||
|
経理却下
|
経理部門が経費レポートを確認して却下し、払い戻しプロセスが停止しました。このイベントは、タイムスタンプと却下理由とともにワークフロー履歴に記録されます。 | ||
|
重要な理由
最終確認段階のボトルネックや却下理由を特定できます。全体の却下率やコンプライアンス上の問題を分析するうえで欠かせません。
入手先
経理チームによる却下操作、タイムスタンプ、ユーザーが記録されたレポートの履歴から取得されます。
記録
レポートのワークフロー履歴に、個別の却下操作として記録されます。
イベントタイプ
explicit
|
|||
|
経費を報告書に追加
|
従業員が、スキャンした領収書や手入力した経費などの明細を報告書に追加したことを示します。報告書の詳細な履歴ログに記録されます。 | ||
|
重要な理由
報告書の作成から経費の追加までにかかった時間を分析すると、従業員による証憑の収集や提出準備の遅れを把握できます。
入手先
経費報告書の監査証跡または履歴から取得します。個々の経費明細の追加などの操作が記録されています。
記録
新しい経費明細が追加されるたびに、報告書の履歴に記録されます。
イベントタイプ
explicit
|
|||
データ抽出ガイド
準備はよろしいですか?
このテンプレートを使うと、データ準備を効率よく進め、経費管理プロセスに関するインサイトを得られます。払い戻しの迅速化と業務の最適化に向けて、今すぐ始めましょう。
経費管理を最適化:今すぐ無料トライアルを開始しましょう。
Expensifyの経費処理を効率化し、サイクルタイムを30%短縮して、満足度を高めましょう。
クレジットカードは不要です。今すぐ最適化を始めましょう。