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

Brex

経費管理の属性(22) 経費管理のアクティビティ(14) データ抽出ガイド(2)

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

このテンプレートでは、経費管理プロセスの分析に必要なデータを収集する手順をご確認いただけます。重要な属性や主要なアクティビティに加え、ソースシステムからデータを抽出する方法も説明しています。プロセスマイニングに必要なデータを漏れなく集めるためにご利用ください。

分析に推奨される属性
プロセス全体で記録する主要なアクティビティ
データ抽出の手順

イベントログを初めて作成する方はこちら：プロセスマイニング用イベントログの作成方法.

テンプレートをダウンロード

経費管理の属性

経費管理を詳しく分析するために、イベントログに含めることを推奨するデータ項目です。

3 必須 5 推奨 14 任意

	名前	説明
	アクティビティ名 ActivityName	経費精算レポートのライフサイクルで発生した特定のイベントまたはタスクの名前です。
説明アクティビティ名は、「経費精算レポートの提出」「マネージャー承認済み」「経費精算の支払い実行」など、プロセスの各段階を示します。これらのイベントが、プロセスの流れを構成する一連の操作です。アクティビティを分析すると、プロセスマップを可視化し、各段階のボトルネックを特定できます。また、承認や却下など、結果ごとの発生頻度も算出できます。経費管理プロセスで何が起きているかを把握するための基礎となる情報です。重要な理由各経費精算レポートがたどるイベントの順序を把握し、プロセスマップを作成するために欠かせない属性です。入手先 Brexのイベントログまたは取引ステータスから取得します。ステータスコードやイベント種別を、ユーザーにわかりやすい名称に対応付ける必要がある場合があります。例経費精算レポートの作成マネージャー承認済み経理却下経費精算の支払い実行
	イベント時刻 EventTime	特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプです。
説明イベント時刻は、プロセス内の各アクティビティが発生した正確な日時を示します。イベントの時系列を確定するため、プロセスマイニングの基礎となる情報です。このタイムスタンプを使って、アクティビティ間のサイクルタイムを算出し、待ち時間や遅延を特定できます。また、期間ごとのプロセスの状況も分析できます。「マネージャー確認の平均時間」や「経費精算の支払い処理までの遅延」などの重要指標の算出に使われ、ボトルネック分析やパフォーマンスの監視に役立ちます。重要な理由サイクルタイムや待ち時間など、時間に基づく指標の算出に欠かせないタイムスタンプです。遅延の特定にも必要です。入手先 Brexの各イベントまたは取引レコードには、タイムスタンプが設定されているはずです。経費精算レポートのAPIレスポンスやデータエクスポートで確認できます。例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
	経費精算レポートID ExpenseReportId	経費精算レポートを一意に識別するIDです。ライフサイクルを追跡する際の主なケース識別子として使われます。
説明経費精算レポートIDは、経費管理プロセスの基盤となる情報です。作成から提出、承認、経費精算まで、関連するすべてのアクティビティを1つのケースにまとめます。プロセスマイニングでは、このIDを使って各経費精算レポートの一連の流れを分析できます。レポートがたどった経路の再現、サイクルタイム全体の計測、修正のために差し戻された際の手戻りの特定、よくある流れや例外的な流れを把握するためのバリアント分析に利用します。重要な理由経費精算レポートのライフサイクル全体を追跡するために欠かせないIDです。サイクルタイム、ボトルネック、プロセス逸脱の分析に役立ちます。入手先 Brexの経費管理モジュールで使われる主な識別子です。通常、経費精算レポートに関連するすべてのデータエクスポートとAPIエンドポイントで利用できます。例 ER-2023-08-1012ER-2023-09-2345ER-2023-10-5567
	イベント実行者 EventUser	アクティビティを実行したユーザーです。たとえば、レポートを承認したマネージャーが該当します。
説明イベント実行者属性は、アクティビティを担当した個人を特定します。レポートを提出した従業員、確認を行ったマネージャー、経費精算を処理した経理担当者などが該当します。「承認者のパフォーマンスと業務量」ダッシュボードでの分析など、業務量やパフォーマンスの追跡に欠かせない属性です。どの承認者が最も多くのレポートを処理しているか、誰の承認が最も早いか、プロセスのボトルネックとなっている人がいないかを特定できます。これにより、業務をより均等に割り振り、必要な担当者に的を絞った支援を行えます。重要な理由操作を担当した人を特定できます。個人単位での業務量やパフォーマンスの分析、ボトルネックの特定に役立ちます。入手先通常、Brexの経費精算レポートの監査証跡またはイベント履歴に記録されます。例 john.smith@example.comjane.doe@example.com経理ボット
	レポートのステータス ReportStatus	ライフサイクルにおける経費精算レポートの現在のステータスです。
説明レポートのステータスは、「マネージャー承認待ち」「承認済み」「支払い済み」「却下」など、経費精算レポートがプロセスのどの段階にあるかを示します。「未完了の経費精算レポートのステータス監視」ダッシュボードなど、業務状況の監視に欠かせない属性です。マネージャーや経理チームは、現在の業務量をすばやく確認し、特定の状態で滞留しているレポートを見つけ、対応の優先順位を決められます。各ステータスにかかった時間を分析すると、プロセスの遅延や非効率な箇所を特定できます。重要な理由ワークフローにおける経費精算レポートの現在の状況を示します。業務ダッシュボードやステータスの監視に欠かせない情報です。入手先 Brexの経費精算レポートオブジェクトに設定される主要なステータスフィールドです。例承認待ち承認済み却下支払い済み
	合計金額 TotalAmount	経費精算レポートの合計金額です。
説明この属性は、経費精算レポートで申請された合計金額を示します。支出傾向や経費精算プロセスが財務に与える影響を把握するための重要な指標です。分析では、合計金額に応じてレポートを分類できます。たとえば、高額と低額のレポートでは、承認経路や確認の厳しさが異なる場合があります。財務報告、予算分析、部門別またはカテゴリ別の支出傾向の把握にも欠かせません。重要な理由財務分析に利用できます。たとえば、より慎重な確認が必要な高額の経費精算レポートや、承認に時間がかかるレポートを特定できます。入手先 Brexの各経費精算レポートに標準で設定されるフィールドです。APIレスポンスやエクスポートのメインの経費精算レポートオブジェクトで確認できます。例 150.752500.0079.99
	従業員の部門 EmployeeDepartment	経費精算レポートを提出した従業員が所属する部門です。
説明この属性は、提出した従業員が所属する営業、エンジニアリング、マーケティングなどの部門を示します。分析における重要な組織上の分類項目です。部門別にデータを分析すると、組織内の特定の部門におけるプロセスの違い、ボトルネック、コンプライアンス上の問題を特定できます。たとえば、ある部門で他部門より却下率が大幅に高い、または承認に時間がかかる場合、対象を絞った研修やプロセスの見直しが必要だとわかります。部門別の予算管理やコスト配賦にも役立ちます。重要な理由事業部門ごとにプロセスの状況を絞り込んで比較し、部門固有の問題や傾向を特定できます。入手先通常、Brexの従業員プロフィールから取得します。人事情報システムと同期されている場合もあります。例営業エンジニアリングマーケティング経理
	規定違反フラグ PolicyViolationFlag	経費精算レポートに規定違反のフラグが設定されたかどうかを示すブール値です。
説明この属性は、Brexの自動規定チェック機能が、カテゴリごとの上限超過や領収書の未添付など、規定違反の可能性を検出したときに設定されるtrueまたはfalseの値です。コンプライアンス分析の基礎となり、「規定違反率」重要業績評価指標（KPI）の算出に使われます。規定に準拠していないレポートをすばやく絞り込み、処理時間や却下率への影響を把握できます。フラグが設定されたレポートを分析すると、社内規定の見直しや、従業員への説明が必要な箇所の特定に役立ちます。重要な理由コンプライアンスの監視を直接支援し、ポリシー違反がプロセスの効率や手戻りに与える影響を定量化できます。入手先 Brexの経費精算データに含まれる真偽値フィールドまたはステータス指標と考えられます。多くの場合、ポリシーエンジンによって管理されます。例 truefalse
	ソースシステム SourceSystem	データの抽出元となるシステムです。
説明この属性は、プロセスデータの取得元を示します。この場合は「Brex」です。複数のシステムのデータを組み合わせてプロセス全体を把握する環境では、データガバナンスと追跡可能性の確保に役立ちます。複数のソースシステムがある場合、分析対象のデータを絞り込み、分類するために使います。取得元に応じて指標やプロセスマップを正しく解釈できます。単一システムを対象とする場合は、データの取得元を確認するために使います。重要な理由データの取得元に関するコンテキストを示します。追跡可能性を確保し、複数システムの環境でデータを正しく絞り込むのに役立ちます。入手先通常、データの抽出と変換の段階で追加される固定値「Brex」です。例 BrexBrex-API-v2.1
	ポリシー違反の詳細 PolicyViolationDetails	違反したポリシーの具体的な内容を示すテキストです。
説明ポリシー違反フラグで違反の発生を確認できるのに対し、この属性からは違反の理由がわかります。「食事代の上限50ドルを超過」や「25ドルを超える経費には領収書が必要」など、違反した具体的なルールが記録されます。この詳細情報は、「ポリシー違反と手戻り分析」ダッシュボードで特に役立ちます。違反の種類ごとの発生頻度を特定し、根本原因を分析できます。特定のポリシーをわかりやすく説明する、従業員にリマインダーを送る、自動化されたシステムルールを調整するといった、的を絞った対策につなげられます。重要な理由ポリシー違反の根本原因を明らかにし、ポリシー、ユーザー研修、システム設定の改善に役立ちます。入手先 Brexでフラグが付いた経費に関連する、コンプライアンスまたはレビューのメモ欄に記録されます。例経費がカテゴリの上限を超えています。領収書が添付されていません。経費の重複が検出されました。
	最終データ更新日時 LastDataUpdate	ソースシステムからデータが最後に更新された時刻を示すタイムスタンプです。
説明この属性は、分析対象データの鮮度を示します。Brexからデータを最後に正常に抽出した日時を記録します。最終データ更新日時を把握すると、インサイトがどの程度最新の情報に基づいているかを確認できます。ダッシュボードが業務の最新状況を反映しているのか、古いデータに基づいているのかを判断し、分析のリアルタイム性に関する期待値を調整できます。重要な理由データの更新時期を把握できます。正確で最新の業務判断を行ううえで欠かせない情報です。入手先 Brexからのデータ取得が正常に完了した時点で、データ抽出ツールまたは処理によって生成されるタイムスタンプです。例 2023-11-20T02:00:00Z2023-11-21T02:00:00Z
	初回承認 FirstPassApproval	却下や修正なしでレポートが承認されたかを示すフラグです。
説明この計算済みの真偽値属性は、最も効率的なプロセスのケースを特定します。経費レポートが申請から最終承認まで、却下や修正の差し戻しを一度も受けずに進んだ場合にのみ、trueに設定されます。この属性は、プロセスの品質と効率を測る重要な指標である「初回承認率」重要業績評価指標（KPI）の基礎となります。初回承認率が高い場合、従業員が質の高いコンプライアンスに準拠したレポートを提出し、承認プロセスもわかりやすいことを示します。初回承認に至らなかったレポートの特徴を分析すると、プロセスの障害や誤りの原因を特定できます。重要な理由滞りなく処理されたレポートを特定し、初回申請の品質と主要なワークフローの効率を測定します。入手先プロセスマイニングプラットフォームで、各ケースのアクティビティの順序を分析し、却下や修正のアクティビティがないことを確認して算出します。例 truefalse
	却下理由 RejectionReason	経費レポートを却下する際に、マネージャーまたは経理担当者が記載した理由です。
説明この属性には、経費レポートの却下時に入力された自由記述または定型の理由が記録されます。自動的に付与されるポリシーフラグとは異なり、承認者による手動の判断を示します。却下理由を分析すると、プロセスの失敗や手戻りの原因を把握できます。申請時によくある誤り、わかりにくいポリシー、従業員やマネージャーの認識違いなどを特定できます。この情報を研修資料やよくある質問の改善に役立てることで、却下や手戻りの発生率を抑えられます。重要な理由手動で却下される理由を明らかにし、ユーザー研修の改善や今後の誤りの削減に役立つ情報を提供します。入手先通常、Brexの画面で承認者が「却下」を選択した際に入力できるコメント欄です。例経費カテゴリが正しく選択されていません。業務上の必要性について、より詳しく説明してください。この購入は事前承認を受けていません。
	国 Country	従業員または経費取引に関連付けられた国です。
説明この属性は、従業員の主な勤務先またはコストセンターの国を示します。グローバル企業では、比較分析に欠かせない切り口です。国別にプロセスを分析すると、プロセスのパフォーマンス、コンプライアンス率、支出傾向における地域差を把握できます。たとえば、現地の規制や管理体制の違いにより、ある国では承認に時間がかかる場合があります。こうした分析は、各地域の事情に配慮しながら、グローバルでプロセスを標準化するうえで役立ちます。重要な理由地域ごとのプロセスのパフォーマンスとコンプライアンスを分析できます。多国籍企業にとって重要な指標です。入手先 Brex内の従業員プロフィールから取得します。多くの場合、中央の人事システムと同期されています。例 USACANGBRDEU
	従業員名 EmployeeName	経費精算レポートを作成し、提出した従業員の名前です。
説明この属性は、経費精算レポートを申請した従業員の名前を示します。イベント実行者が操作を行った人を示すのに対し、従業員名はケースの対象者を示します。分析では、従業員ごとの経費を追跡できます。規定違反を含むレポートを頻繁に提出する人や、レポートが繰り返し却下される人を特定し、追加の研修が必要かどうかを判断できます。また、組織内の従業員やロールごとの支出傾向を把握するのにも役立ちます。重要な理由経費精算レポートの申請者を特定し、従業員ごとの申請品質やコンプライアンス状況を分析できます。入手先すべての経費精算レポートに含まれる基本情報です。Brexの作成者プロフィールに関連付けられています。例アリス・ジョンソンロバート・ウィリアムズマリア・ガルシア
	手戻りの有無 IsRework	レポートが少なくとも1回、修正のために差し戻された場合に真となる計算フラグです。
説明この真偽値属性は、プロセスの流れから算出されます。経費レポートの履歴に「レポートを修正のため差し戻し」アクティビティが含まれる場合、trueに設定されます。これにより、手戻りが発生したケースを簡単に分類して分析できます。このフラグは、「経費レポートの手戻り率」重要業績評価指標（KPI）の算出や、「ポリシー違反と手戻り分析」ダッシュボードに使用されます。プロセスを滞りなく進んだケースと差し戻されたケースを比較し、手戻りに伴う時間やコストを定量化できます。重要な理由追加の作業や修正が必要だった経費レポートを特定し、手戻りの原因やコストを分析できます。入手先この属性はソースシステムにはありません。ケースのアクティビティの順序に「レポートを修正のため差し戻し」など、手戻りを示すアクティビティが含まれているかを確認して算出します。例 truefalse
	支払い方法 PaymentMethod	法人カードや個人資金など、経費の支払い方法を示します。
説明この属性では、Brexの法人カードで支払った経費と、従業員が立て替えて払い戻しを受ける経費を区別します。支払い方法によってプロセスが大きく異なるため、この区別は重要です。法人カードでの取引では確認や照合が行われる一方、立替経費では申請と払い戻しが行われます。支払い方法別に分析すると、それぞれの流れに固有の問題を特定し、個別に改善できます。重要な理由法人カードでの支払いと立替経費の払い戻しでは、プロセスの流れや必要な手順が異なることが多いため、バリアント分析に欠かせない属性です。入手先この情報はBrexの取引データに含まれています。例 Brex法人カード払い戻し請求書支払い
	終了時刻 EndTime	アクティビティが完了した時刻を示すタイムスタンプです。
説明 StartTime（EventTime）がアクティビティの開始を示すのに対し、EndTimeは終了を示します。「マネージャーのレビュー開始」や「マネージャーによる承認」など、所要時間のあるアクティビティで特に重要です。アクティビティの開始時刻と終了時刻が両方記録されていれば、処理時間を正確に算出し、その前に発生する待ち時間と区別できます。実際の作業にかかる時間を正確に測定できるため、ボトルネック分析に役立ちます。重要な理由待ち時間と区別してアクティビティの処理時間を正確に算出でき、ボトルネック分析の精度向上につながります。入手先 EndTimeには、次のアクティビティのStartTimeが使われることがよくあります。所要時間が定義されたアクティビティでは、ソースデータに専用のフィールドが用意されている場合もあります。例 2023-10-26T10:05:12Z2023-10-26T14:40:00Z2023-10-27T09:15:25Z
	経費カテゴリ ExpenseCategory	出張費、食事代、ソフトウェアなど、経費に割り当てられたカテゴリです。
説明経費カテゴリは、経費の内容を示すために従業員が選択する分類です。会計、予算管理、ポリシーの適用に使用されます。プロセスマイニングでは、経費をカテゴリ別に分類することで、プロセスをより細かく分析できます。たとえば、海外出張など特定のカテゴリで承認に時間がかかるか、却下率が高いかを確認できます。こうした分析は、支出の種類に応じたポリシーやプロセスの見直しに役立ちます。重要な理由支出の種類ごとにプロセスを分析でき、経費の種類による動きの違いやボトルネックを把握できます。入手先経費明細に標準で用意されているフィールドです。レポートに複数のカテゴリが含まれる場合は、経費レポート単位に集約する必要があります。例航空運賃食事・接待費ソフトウェアのサブスクリプション事務用品
	自動処理かどうか IsAutomated	アクティビティがシステムユーザーまたはボットによって実行されたかを示す真偽値フラグです。
説明この属性では、ポリシーの自動チェックなどシステムが自動で実行したアクティビティと、手動承認などユーザーが実行したアクティビティを区別します。自動処理と手動処理を区別することは、プロセスの自動化の度合いを把握するうえで重要です。ルールベースのシステムの効果を評価し、さらなる自動化の余地を特定できます。たとえば、自動承認されたレポートと手動対応が必要なレポートの件数を比較し、人手を介さない処理を増やす取り組みに役立てられます。重要な理由プロセスの自動化の度合いを測定し、人とシステムのどちらが各ステップを実行しているかを特定できます。入手先通常、イベントに関連付けられたユーザーを確認して判定します。システムが生成したイベントには、「system」や「bot」などの汎用ユーザーが関連付けられていることがよくあります。例 truefalse
	通貨 Currency	経費精算レポートの合計金額に使われる通貨コードです。
説明通貨属性は、合計金額の単位を示します。たとえば、USD、EUR、GBPなどです。複数の通貨を扱う多国籍組織で、正確な財務分析を行うために欠かせません。この属性により、財務データを正しく解釈できます。経費金額を適切に集計、比較するために使い、通常は共通の報告通貨への換算が必要です。異なる通貨の金額を合算してしまう分析上の誤りも防げます。重要な理由複数通貨を扱う環境で財務データの正確性を保ち、経費金額を正しく集計、報告できます。入手先通常、Brexの経費精算データでは金額フィールドとともに利用できます。例 USDEURGBP
	領収書の期限内添付 ReceiptsAttachedOnTime	レポートの提出前に領収書が添付されたかを示すフラグです。
説明この計算済みの真偽値属性は、経費レポートをレビューに提出する前に必要な領収書をすべて添付するという、一般的なベストプラクティスの遵守状況を測定します。該当するケースで「領収書を添付」アクティビティが「経費レポートを提出」アクティビティより前に発生した場合、trueに設定されます。このフラグは、「領収書の遵守状況と影響」ダッシュボードと「領収書添付の遵守率」重要業績評価指標（KPI）に直接役立ちます。この属性を分析すると、領収書の添付遅れや未添付の頻度を定量化し、遅延、却下、手戻りなどのプロセスの結果との関連を確認できます。重要な理由領収書提出ポリシーの遵守状況を測定し、プロセスの遅延や却下につながるよくある根本原因を特定できます。入手先プロセスマイニングツールで、各ケースの「領収書を添付」と「経費レポートを提出」アクティビティのタイムスタンプを比較して算出します。例 truefalse

必須推奨任意

経費管理のアクティビティ

経費管理プロセスを正確に把握するため、イベントログに記録する主要なステップと節目です。

7 推奨 7 任意

	アクティビティ	説明
	マネージャー承認済み	一次承認者であるマネージャーが経費精算レポートを確認し、次の処理に進めることを承認しました。この重要な判断により、レポートは通常、経理確認または自動承認の段階に進みます。
重要な理由この節目で最初の承認段階が完了します。承認にかかる時間、マネージャーの業務量、「初回承認率」の追跡に欠かせません。入手先承認履歴テーブルまたは監査証跡に、承認者IDとタイムスタンプを含むイベントとして明示的に記録されていると考えられます。記録イベントログ、またはタイムスタンプを伴う「マネージャー承認済み」へのステータス変更から取得します。イベントタイプ explicit
	会計システムへの計上	経費データが会社の総勘定元帳またはERPシステムに正常に計上されたことを示す最終段階です。これにより、経費精算の財務照合が完了します。
重要な理由このアクティビティは、財務会計の観点からプロセスが完了したことを示します。経費精算から計上までの遅れは、システム連携や会計ワークフローの問題を示している可能性があります。入手先 APIによる確認、または会計システムとの同期が正常に完了した後のステータス更新から取得できると考えられます。イベントのタイムスタンプは計上時刻を示します。記録連携先のERPまたは会計ソフトウェアからAPIコールバックを受信した後、またはステータスが更新された後に記録されます。イベントタイプ explicit
	修正のためレポートを差し戻し	マネージャーまたは経理の承認者が、修正のためレポートを従業員に差し戻します。却下とは異なり、手戻りが発生することを示します。
重要な理由このアクティビティは、手戻りを示す主な指標です。発生頻度の追跡は、「経費精算レポートの手戻り率」重要業績評価指標（KPI）と「規定違反と手戻り分析」ダッシュボードに欠かせません。入手先ステータスが「修正が必要」または「差し戻し」に変わったことから特定できると考えられます。システムには、このステータス更新のタイムスタンプを記録する必要があります。記録「修正が必要」などへのステータス変更から特定します。コメントが付く場合もあります。イベントタイプ inferred
	経理承認済み	経理部門が確認を完了し、経費精算レポートを最終承認しました。経費精算の支払い処理に進む前の最後の承認段階です。
重要な理由支払いを許可する重要な節目です。承認プロセス全体の計測がここで完了し、「経費精算の支払い処理までの遅延」重要業績評価指標（KPI）の計測が始まります。入手先最終承認者のIDとタイムスタンプを含め、承認履歴または監査証跡にイベントとして明示的に記録する必要があります。記録イベントログ、または「経理承認済み」や「支払い承認済み」へのステータス変更から取得します。イベントタイプ explicit
	経費精算の支払い実行	従業員への支払いが実際に行われた時点を示すアクティビティです。従業員から見た最終段階であり、プロセスが正常に完了したことを示します。
重要な理由このプロセスが正常に完了したことを示す主な終了イベントです。「処理全体の平均サイクルタイム」と「経費精算の支払い処理までの遅延」の重要業績評価指標（KPI）の算出に必要で、従業員満足度にも直接影響します。入手先支払い取引ログ、または銀行や決済処理業者からのAPI確認を通じて記録します。実際に支払いが実行された日付に該当します。記録実行タイムスタンプを含む支払い取引ログから取得します。イベントタイプ explicit
	経費精算レポートの作成	従業員が経費精算レポートを作成した時点を示すアクティビティです。新しいレポートが下書きとして作成されたとき、または最初の経費項目が追加されたときに、システムがこのイベントを記録します。
重要な理由このプロセスの主な開始イベントです。この時点から提出までの時間を分析すると、従業員の行動や経費報告の遅れにつながる要因を把握できます。入手先このイベントは、Brexのデータベースにある経費精算レポートの作成タイムスタンプから取得できると考えられます。経費精算レポートIDに関連付けられた最も早いタイムスタンプに該当します。記録経費精算レポートのヘッダーレコードの作成日から特定します。イベントタイプ explicit
	経費精算レポートの提出	従業員が完成した経費精算レポートを正式に承認へ回したときに発生するアクティビティです。ユーザーが行う重要な操作で、レポートのステータスが「下書き」または「オープン」から「承認待ち」に変わります。
重要な理由承認ワークフローが正式に始まる重要な節目です。提出から最終承認までの時間は、全体のサイクルタイムを構成する重要な要素です。入手先通常は監査ログに明示的なイベントとして記録されます。または、対応するタイムスタンプとともにステータスが「提出済み」や「マネージャー承認待ち」に変わったことから特定できます。記録イベントログ、または経費精算レポートの「submission_timestamp」フィールドから取得します。イベントタイプ explicit
	マネージャーによる確認の開始	経費精算レポートがマネージャーの承認待ちキューに入った時点を示します。通常、提出直後にレポートのステータスが「マネージャー承認待ち」に変わったことから特定します。
重要な理由最初の承認段階の開始を示します。この時点から「マネージャー承認済み」または「マネージャー却下」までの時間は、「マネージャー確認の平均時間」重要業績評価指標（KPI）の算出に欠かせません。入手先経費精算レポートのステータスが「マネージャー承認待ち」または同様の状態に変わった時刻から特定します。多くの場合、「経費精算レポートの提出」と同時に発生します。記録ステータスが「マネージャー承認待ち」に変わった時刻から特定します。イベントタイプ inferred
	マネージャー却下	一次承認者であるマネージャーが経費精算レポートを確認し、却下しました。この操作によってプロセスが停止するか、レポートが修正のため従業員に差し戻されます。
重要な理由このアクティビティは、否定的な結果とプロセス上の例外を示します。「経費精算レポートの却下率」の算出や、最初の承認段階で却下された理由の特定に欠かせません。入手先承認と同様に、タイムスタンプと理由コードを含め、承認履歴テーブルまたは監査証跡に明示的に記録する必要があります。記録イベントログ、またはタイムスタンプを伴う「マネージャー却下」へのステータス変更から取得します。イベントタイプ explicit
	社内規定違反の検出	レポート内の1つ以上の経費項目が社内規定に違反していることを示す、自動または手動のイベントです。システムルールが適用されたときや、確認担当者が問題を手動で指摘したときに記録できます。
重要な理由「規定違反と手戻り分析」ダッシュボードと「規定違反率」重要業績評価指標（KPI）では、このアクティビティが重要です。よくあるコンプライアンス上の問題や、規定の明確化が必要な箇所を特定できます。入手先「規定違反フラグ」属性がtrueに設定されたことから特定します。タイムスタンプには、フラグのステータスが最後に更新された時刻を使用します。記録規定違反を示すブール値フラグまたはステータスフィールドの変更から特定します。イベントタイプ inferred
	経理却下	経理部門が、通常は社内規定、コンプライアンス、文書化に関する理由で経費精算レポートを却下しました。プロセスを停止させる最終的な却下です。
重要な理由これは重要な例外イベントです。発生頻度と原因を分析すると、コンプライアンス上の問題を把握し、「経費精算レポートの却下率」を算出できます。入手先ほかの承認判断と同様に、承認者ID、タイムスタンプ、理由を監査証跡に明示的に記録する必要があります。記録イベントログ、または「経理却下」へのステータス変更から取得します。イベントタイプ explicit
	経理確認の開始	経費精算レポートが、最終確認のため経理部門または会計部門のキューに入った時点を示します。通常、マネージャー承認後のステータス変更から特定します。
重要な理由最終承認段階の開始を示します。この段階は、最も重要な承認段階となることも少なくありません。所要時間を分析すると、経理部門のボトルネックを特定できます。入手先マネージャー承認後、レポートのステータスが「経理承認待ち」または同様の状態に変わった時刻から特定します。記録ステータスが「経理確認待ち」に変わった時刻から特定します。イベントタイプ inferred
	経費精算の支払い予定	最終承認後、経費精算レポートは次回の支払い処理に向けてキューに登録されます。このアクティビティは、承認から支払いシステムへの引き継ぎを示します。
重要な理由この段階を確認すると、最終承認から実際の支払い処理までの遅れがわかります。承認のボトルネックと、支払いシステムの非効率を区別するのに役立ちます。入手先「支払い準備完了」または「予定済み」へのステータス変更から特定できます。システムが別の支払いシステムやERPと連携している場合は、明示的なイベントとして記録されることもあります。記録「支払い待ち」へのステータス変更、または支払いバッチレコードの作成から特定します。イベントタイプ inferred
	領収書の添付	ユーザーが経費明細に領収書の画像や文書をアップロードまたは添付したことを示します。通常、添付ごとにタイムスタンプ付きのイベントとして記録されます。
重要な理由「領収書の提出状況と影響」ダッシュボードでは、このアクティビティの追跡が欠かせません。領収書の未提出や提出の遅れが、処理の遅延や差し戻しと関係しているかを確認できます。入手先添付ファイルと経費明細を関連付けるテーブルに記録されていると考えられます。各添付レコードには、それぞれ作成タイムスタンプが設定されているはずです。記録ユーザーが経費明細に関連付けられたファイルを正常にアップロードした時点で記録されます。イベントタイプ explicit

推奨任意

データ抽出ガイド

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

ステップ

Brexにログインします： 会社全体の経費データを表示・エクスポートするには、管理者または経理担当者の権限が必要です。該当する権限を持つアカウントでBrexダッシュボードにアクセスしてください。
経費に移動します： 左側のナビゲーションメニューから「経費」を選択し、経費管理ダッシュボードを開きます。
会社の経費を表示します： 「経費」セクションで、会社全体の経費を表示する画面に移動します。「会社の経費」などの名称が付いている場合があります。
フィルターを設定します： 必要なデータを抽出できるよう、フィルターを設定します。たとえば、直近6か月などの期間を指定すると、分析に適したデータを取得できます。各レポートの全体像を把握できるよう、下書き、保留中、承認済み、却下、支払い済みなど、すべての経費ステータスを含めてください。
エクスポートを開始します： 「エクスポート」ボタンを選択します。エクスポート設定のダイアログまたは新しいページが開きます。
エクスポート設定を行います： エクスポート形式に「CSV」を選択します。列の選択画面では、ID、金額、ユーザー、部門、ステータスに関する項目と、利用可能なすべての日時（作成日、申請日、承認日、支払日、エクスポート日など）を含めてください。イベントログの作成には、すべての日時データが欠かせません。
CSVファイルをダウンロードします： 選択内容を確認し、生成されたCSVファイルをローカル環境にダウンロードします。このファイルには、取引の生のデータが含まれています。
データ形式を確認します： エクスポートされたファイルは状態ベースのログで、経費またはレポートごとに1行あり、複数の日付列が含まれています。プロセスマイニングで使うには、各行が1つのアクティビティを表すイベントログに変換する必要があります。
データを変換します： Microsoft ExcelやGoogleスプレッドシートなどの表計算ソフト、またはPythonなどのスクリプト言語でCSVを開きます。元のエクスポートの各行から、関連するアクティビティの日時ごとに新しい行を作成します。たとえば、申請、マネージャー承認、支払いの日時が記録された経費レポートは、変換後のファイルでは3行になります。
列をイベントログのスキーマに対応付けます： データの変換時に、Brexのエクスポート列をイベントログに必要な構造に対応付けます。Expense IDはExpenseReportIdに、各日時列は対応するアクティビティのEventTimeに設定します。また、アクティビティ名（例：「経費レポートを申請」）をActivityNameに設定します。
完成したイベントログを保存します： 変換が完了し、ExpenseReportId、ActivityName、EventTimeの列を含む縦持ち形式のテーブルができたら、新しいCSVファイルとして保存します。このファイルは、プロセスマイニングツールにアップロードできる形式になっています。

設定

ユーザー権限： Brexで全従業員の経費データにアクセスしてエクスポートするには、管理者または経理担当者のロールが必要です。
期間： 有意義な分析を行うには、3～6か月分のデータをエクスポートすることを推奨します。1年を超えるデータをエクスポートすると、時間がかかり、ファイルサイズも非常に大きくなる場合があります。
ステータスフィルター： プロセスの開始から完了までを把握できるよう、下書き、承認待ち、承認済み、却下、支払い済みなど、すべてのステータスを含めるように設定してください。
エクスポートする列： エクスポート時には、利用可能なすべての列を選択してください。EmployeeDepartmentやTotalAmountなどの属性に加え、プロセスの時系列を正確に再構成するために必要なすべての日時を取得するうえで重要です。

クエリの例 sql

/*
 This script represents the data transformation logic to be applied to the downloaded
 Brex CSV file. Treat the CSV as a source table named 'brex_export'.
 Column names like 'ExpenseReportId', 'CreatedAt', 'SubmittedAt', 'ManagerApprovedAt',
 'PolicyViolationReason', 'FinanceApprovedAt', 'RejectedAt', 'RevisionRequestedAt',
 'ReimbursementScheduledAt', 'ReimbursementExecutedAt', and 'PostedToLedgerAt' are
 representative and should be mapped to the actual column names in your export file.
*/

SELECT
  ExpenseReportId,
  'Expense Report Created' AS ActivityName,
  CreatedAt AS EventTime,
  TotalAmount,
  EmployeeDepartment,
  EventUser,
  ReportStatus,
  CASE WHEN PolicyViolationReason IS NOT NULL THEN 'true' ELSE 'false' END AS PolicyViolationFlag
FROM brex_export
WHERE CreatedAt IS NOT NULL

UNION ALL

SELECT
  ExpenseReportId,
  'Receipts Attached' AS ActivityName,
  ReceiptAttachedAt AS EventTime, -- Note: This timestamp may not be available and might need to be inferred.
  TotalAmount,
  EmployeeDepartment,
  EventUser,
  ReportStatus,
  CASE WHEN PolicyViolationReason IS NOT NULL THEN 'true' ELSE 'false' END AS PolicyViolationFlag
FROM brex_export
WHERE ReceiptAttachedAt IS NOT NULL

UNION ALL

SELECT
  ExpenseReportId,
  'Expense Report Submitted' AS ActivityName,
  SubmittedAt AS EventTime,
  TotalAmount,
  EmployeeDepartment,
  EventUser,
  ReportStatus,
  CASE WHEN PolicyViolationReason IS NOT NULL THEN 'true' ELSE 'false' END AS PolicyViolationFlag
FROM brex_export
WHERE SubmittedAt IS NOT NULL

UNION ALL

SELECT
  ExpenseReportId,
  'Policy Violation Flagged' AS ActivityName,
  PolicyViolationFlaggedAt AS EventTime, -- Note: This specific timestamp may need to be inferred from the submission or review time.
  TotalAmount,
  EmployeeDepartment,
  'System' AS EventUser,
  ReportStatus,
  'true' AS PolicyViolationFlag
FROM brex_export
WHERE PolicyViolationReason IS NOT NULL

UNION ALL

SELECT
  ExpenseReportId,
  'Manager Review Started' AS ActivityName,
  SubmittedAt AS EventTime, -- This event is inferred to start immediately upon submission.
  TotalAmount,
  EmployeeDepartment,
  ManagerName AS EventUser,
  ReportStatus,
  CASE WHEN PolicyViolationReason IS NOT NULL THEN 'true' ELSE 'false' END AS PolicyViolationFlag
FROM brex_export
WHERE SubmittedAt IS NOT NULL

UNION ALL

SELECT
  ExpenseReportId,
  'Manager Approved' AS ActivityName,
  ManagerApprovedAt AS EventTime,
  TotalAmount,
  EmployeeDepartment,
  ManagerName AS EventUser,
  ReportStatus,
  CASE WHEN PolicyViolationReason IS NOT NULL THEN 'true' ELSE 'false' END AS PolicyViolationFlag
FROM brex_export
WHERE ManagerApprovedAt IS NOT NULL

UNION ALL

SELECT
  ExpenseReportId,
  'Manager Rejected' AS ActivityName,
  RejectedAt AS EventTime,
  TotalAmount,
  EmployeeDepartment,
  ManagerName AS EventUser,
  'Rejected' AS ReportStatus,
  CASE WHEN PolicyViolationReason IS NOT NULL THEN 'true' ELSE 'false' END AS PolicyViolationFlag
FROM brex_export
WHERE RejectedAt IS NOT NULL AND FinanceApprovedAt IS NULL -- Assumes rejection before finance approval is a manager rejection.

UNION ALL

SELECT
  ExpenseReportId,
  'Report Sent For Revision' AS ActivityName,
  RevisionRequestedAt AS EventTime,
  TotalAmount,
  EmployeeDepartment,
  ApproverName AS EventUser,
  'Needs Revision' AS ReportStatus,
  CASE WHEN PolicyViolationReason IS NOT NULL THEN 'true' ELSE 'false' END AS PolicyViolationFlag
FROM brex_export
WHERE RevisionRequestedAt IS NOT NULL

UNION ALL

SELECT
  ExpenseReportId,
  'Finance Review Started' AS ActivityName,
  ManagerApprovedAt AS EventTime, -- This event is inferred to start immediately after manager approval.
  TotalAmount,
  EmployeeDepartment,
  '[Configure Finance Reviewer]' AS EventUser,
  ReportStatus,
  CASE WHEN PolicyViolationReason IS NOT NULL THEN 'true' ELSE 'false' END AS PolicyViolationFlag
FROM brex_export
WHERE ManagerApprovedAt IS NOT NULL

UNION ALL

SELECT
  ExpenseReportId,
  'Finance Approved' AS ActivityName,
  FinanceApprovedAt AS EventTime,
  TotalAmount,
  EmployeeDepartment,
  '[Configure Finance Reviewer]' AS EventUser,
  ReportStatus,
  CASE WHEN PolicyViolationReason IS NOT NULL THEN 'true' ELSE 'false' END AS PolicyViolationFlag
FROM brex_export
WHERE FinanceApprovedAt IS NOT NULL

UNION ALL

SELECT
  ExpenseReportId,
  'Finance Rejected' AS ActivityName,
  RejectedAt AS EventTime,
  TotalAmount,
  EmployeeDepartment,
  '[Configure Finance Reviewer]' AS EventUser,
  'Rejected' AS ReportStatus,
  CASE WHEN PolicyViolationReason IS NOT NULL THEN 'true' ELSE 'false' END AS PolicyViolationFlag
FROM brex_export
WHERE RejectedAt IS NOT NULL AND ManagerApprovedAt IS NOT NULL -- Assumes rejection after manager approval is a finance rejection.

UNION ALL

SELECT
  ExpenseReportId,
  'Reimbursement Scheduled' AS ActivityName,
  ReimbursementScheduledAt AS EventTime,
  TotalAmount,
  EmployeeDepartment,
  'System' AS EventUser,
  'Processing Payment' AS ReportStatus,
  CASE WHEN PolicyViolationReason IS NOT NULL THEN 'true' ELSE 'false' END AS PolicyViolationFlag
FROM brex_export
WHERE ReimbursementScheduledAt IS NOT NULL

UNION ALL

SELECT
  ExpenseReportId,
  'Reimbursement Executed' AS ActivityName,
  ReimbursementExecutedAt AS EventTime,
  TotalAmount,
  EmployeeDepartment,
  'System' AS EventUser,
  'Paid' AS ReportStatus,
  CASE WHEN PolicyViolationReason IS NOT NULL THEN 'true' ELSE 'false' END AS PolicyViolationFlag
FROM brex_export
WHERE ReimbursementExecutedAt IS NOT NULL

UNION ALL

SELECT
  ExpenseReportId,
  'Accounting Posted' AS ActivityName,
  PostedToLedgerAt AS EventTime,
  TotalAmount,
  EmployeeDepartment,
  'System' AS EventUser,
  'Closed' AS ReportStatus,
  CASE WHEN PolicyViolationReason IS NOT NULL THEN 'true' ELSE 'false' END AS PolicyViolationFlag
FROM brex_export
WHERE PostedToLedgerAt IS NOT NULL;

ステップ

事前準備：Python 3.6以降がインストールされていることを確認します。ターミナルで次のコマンドを実行し、必要なライブラリであるpandasとrequestsをインストールします：pip install pandas requests。
Brex APIトークンを作成します：Brexダッシュボードにログインし、「Developer」セクションに移動して、新しいユーザートークンを作成します。必要なデータにアクセスできるよう、トークンには次のスコープを付与してください：team:read、transactions:read、expenses:read。作成したトークンは安全にコピーしてください。
Pythonスクリプトを準備します：extract_brex_expenses.pyという名前の新しいファイルを作成します。「Query」セクションに記載されているPythonスクリプト全体を、このファイルにコピーします。
スクリプトのパラメーターを設定します：extract_brex_expenses.pyを開き、先頭にあるプレースホルダー変数を更新します。API_TOKEN変数に手順2で作成したトークンを設定します。抽出期間を指定するため、START_DATEとEND_DATE変数を「YYYY-MM-DD」形式で設定します。
スクリプトを実行します：ターミナルでpython extract_brex_expenses.pyを実行します。スクリプトがBrex APIに接続し、指定した期間の経費データを取得します。ページネーションも自動で処理されます。
データを処理・変換します：スクリプトはAPIから取得した生のJSONデータを処理します。各経費レポートとステータス履歴を確認し、作成から会計システムとの同期まで、必要な14種類のプロセスアクティビティごとに行を作成します。
イベントログを作成します：スクリプトの実行が完了すると、同じディレクトリにbrex_expense_event_log.csvというCSVファイルが作成されます。このファイルは、アクティビティごとに1行で構成されたイベントログです。
アップロードの準備をします：作成されたCSVファイルはProcessMindの要件に沿った形式です。追加のデータ変換は必要ありません。このファイルをProcessMindのプロジェクトに直接アップロードできます。

設定

APIトークン： Brex Developerダッシュボードで作成したユーザートークンが必要です。トークンではteam:read、transactions:read、expenses:readのスコープを有効にしてください。
期間： スクリプトにはSTART_DATEとEND_DATEの変数があります。初回の分析では、代表性のあるデータを確保しつつ過度な負荷を避けるため、3～6か月分のデータを抽出することを推奨します。
ページネーションの上限： スクリプトはAPI呼び出し1回あたり最大100件の経費を取得するよう設定されています（limit=100）。APIが返すnext_cursorを使ってページネーションを自動処理し、指定期間内のすべてのレコードを取得します。
処理時間に関する注意： 1年を超えるデータを抽出する場合、APIのレート制限や処理するデータ量により、スクリプトの実行に数分かかることがあります。大量のデータを抽出する場合は、利用の少ない時間帯に実行することをおすすめします。
データの粒度： スクリプトは経費オブジェクトとそのステータス履歴に基づいてイベントを抽出します。標準的なワークフローを前提としているため、独自の承認フローを使用している場合は、スクリプトの処理ロジックを調整する必要があります。

クエリの例 python

import requests
import pandas as pd
import os
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Brex User Token
API_TOKEN = class="hl-string">"[Your Brex API Token]"
class=class="hl-string">"hl-comment"># Set the desired date range for the extraction (YYYY-MM-DD)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"
OUTPUT_FILENAME = class="hl-string">"brex_expense_event_log.csv"

class=class="hl-string">"hl-comment"># --- API and Headers ---
API_URL = class="hl-string">"https://platform.brex.com/v2/expenses"
HEADERS = {
    class="hl-string">"Authorization": fclass="hl-string">"Bearer {API_TOKEN}",
    class="hl-string">"Content-Type": class="hl-string">"application/json",
}

def fetch_expenses(start_date, end_date):
    class="hl-string">"""Fetches all expenses within a date range, handling pagination."""
    all_expenses = []
    cursor = None
    print(fclass="hl-string">"Fetching expenses from {start_date} to {end_date}...")

    while True:
        params = {
            class="hl-string">"limit": 100,
            class="hl-string">"updated_at_start": fclass="hl-string">"{start_date}T00:00:00Z",
        }
        if cursor:
            params[class="hl-string">'cursor'] = cursor

        response = requests.get(API_URL, headers=HEADERS, params=params)
        response.raise_for_status()  class=class="hl-string">"hl-comment"># Will raise an exception for HTTP error codes
        data = response.json()
        
        expenses = data.get(class="hl-string">'items', [])
        if not expenses:
            break

        for expense in expenses:
            class=class="hl-string">"hl-comment"># Filter expenses to be within the specified end date
            updated_at = datetime.fromisoformat(expense[class="hl-string">'updated_at'].replace(class="hl-string">'Z', class="hl-string">'+00:00'))
            if updated_at.strftime(class="hl-string">'%Y-%m-%d') <= end_date:
                all_expenses.append(expense)
        
        class=class="hl-string">"hl-comment"># Stop if we've gone past our end date or there are no more pages
        last_expense_date = datetime.fromisoformat(expenses[-1][class="hl-string">'updated_at'].replace(class="hl-string">'Z', class="hl-string">'+00:00')).strftime(class="hl-string">'%Y-%m-%d')
        if last_expense_date > end_date or not data.get(class="hl-string">'next_cursor'):
            break

        cursor = data.get(class="hl-string">'next_cursor')
        print(fclass="hl-string">"Fetched {len(all_expenses)} expenses so far...")

    print(fclass="hl-string">"Total expenses fetched: {len(all_expenses)}")
    return all_expenses

def process_expenses_to_events(expenses):
    class="hl-string">"""Transforms raw expense data into a structured event log."""
    event_log = []

    for expense in expenses:
        report_id = expense[class="hl-string">'id']
        total_amount = expense.get(class="hl-string">'original_amount', {}).get(class="hl-string">'amount', 0) / 100.0
        employee_department = expense.get(class="hl-string">'user', {}).get(class="hl-string">'department', {}).get(class="hl-string">'name')
        submitter_user = expense.get(class="hl-string">'user', {}).get(class="hl-string">'name')

        common_attributes = {
            class="hl-string">'ExpenseReportId': report_id,
            class="hl-string">'TotalAmount': total_amount,
            class="hl-string">'EmployeeDepartment': employee_department,
            class="hl-string">'ReportStatus': expense.get(class="hl-string">'status'),
            class="hl-string">'PolicyViolationFlag': bool(expense.get(class="hl-string">'policy_violations'))
        }

        class=class="hl-string">"hl-comment"># 1. Expense Report Created
        event_log.append({
            **common_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Expense Report Created',
            class="hl-string">'EventTime': expense[class="hl-string">'created_at'],
            class="hl-string">'EventUser': submitter_user
        })

        class=class="hl-string">"hl-comment"># 2. Receipts Attached
        if expense.get(class="hl-string">'receipts'):
            class=class="hl-string">"hl-comment"># Use the memo_updated_at as a proxy for when receipts/memos were last touched
            event_time = expense.get(class="hl-string">'memo_updated_at') or expense[class="hl-string">'updated_at']
            event_log.append({
                **common_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Receipts Attached',
                class="hl-string">'EventTime': event_time,
                class="hl-string">'EventUser': submitter_user
            })

        class=class="hl-string">"hl-comment"># 3. Policy Violation Flagged
        if common_attributes[class="hl-string">'PolicyViolationFlag']:
            event_log.append({
                **common_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Policy Violation Flagged',
                class="hl-string">'EventTime': expense[class="hl-string">'updated_at'], class=class="hl-string">"hl-comment"># Inferred timestamp
                class="hl-string">'EventUser': class="hl-string">'System'
            })

        class=class="hl-string">"hl-comment"># Process status history for workflow events
        if expense.get(class="hl-string">'status_history'):
            for history_item in sorted(expense[class="hl-string">'status_history'], key=lambda x: x[class="hl-string">'commented_at']):
                activity_name = None
                status = history_item[class="hl-string">'status']
                event_time = history_item[class="hl-string">'commented_at']
                event_user = history_item.get(class="hl-string">'user', {}).get(class="hl-string">'name', class="hl-string">'System')

                if status == class="hl-string">'PENDING_APPROVAL':
                    event_log.append({**common_attributes, class="hl-string">'ActivityName': class="hl-string">'Expense Report Submitted', class="hl-string">'EventTime': event_time, class="hl-string">'EventUser': submitter_user})
                    event_log.append({**common_attributes, class="hl-string">'ActivityName': class="hl-string">'Manager Review Started', class="hl-string">'EventTime': event_time, class="hl-string">'EventUser': event_user})
                elif status == class="hl-string">'APPROVED':
                    class=class="hl-string">"hl-comment"># Differentiate Manager vs Finance approval by sequence, a common simplification
                    manager_approved_exists = any(e[class="hl-string">'ActivityName'] == class="hl-string">'Manager Approved' and e[class="hl-string">'ExpenseReportId'] == report_id for e in event_log)
                    if not manager_approved_exists:
                        event_log.append({**common_attributes, class="hl-string">'ActivityName': class="hl-string">'Manager Approved', class="hl-string">'EventTime': event_time, class="hl-string">'EventUser': event_user})
                        class=class="hl-string">"hl-comment"># Infer Finance Review Started right after manager approval
                        event_log.append({**common_attributes, class="hl-string">'ActivityName': class="hl-string">'Finance Review Started', class="hl-string">'EventTime': event_time, class="hl-string">'EventUser': None})
                    else:
                        event_log.append({**common_attributes, class="hl-string">'ActivityName': class="hl-string">'Finance Approved', class="hl-string">'EventTime': event_time, class="hl-string">'EventUser': event_user})
                elif status == class="hl-string">'REJECTED':
                    class=class="hl-string">"hl-comment"># Differentiate Manager vs Finance rejection by sequence
                    manager_approved_exists = any(e[class="hl-string">'ActivityName'] == class="hl-string">'Manager Approved' and e[class="hl-string">'ExpenseReportId'] == report_id for e in event_log)
                    if not manager_approved_exists:
                        event_log.append({**common_attributes, class="hl-string">'ActivityName': class="hl-string">'Manager Rejected', class="hl-string">'EventTime': event_time, class="hl-string">'EventUser': event_user})
                    else:
                        event_log.append({**common_attributes, class="hl-string">'ActivityName': class="hl-string">'Finance Rejected', class="hl-string">'EventTime': event_time, class="hl-string">'EventUser': event_user})
                elif status == class="hl-string">'NEEDS_REVIEW':
                    event_log.append({**common_attributes, class="hl-string">'ActivityName': class="hl-string">'Report Sent For Revision', class="hl-string">'EventTime': event_time, class="hl-string">'EventUser': event_user})
        
        class=class="hl-string">"hl-comment"># Reimbursement and Accounting Events
        payment_status = expense.get(class="hl-string">'payment_status')
        if payment_status in [class="hl-string">'PROCESSING', class="hl-string">'PAID']:
             event_log.append({**common_attributes, class="hl-string">'ActivityName': class="hl-string">'Reimbursement Scheduled', class="hl-string">'EventTime': expense[class="hl-string">'updated_at'], class="hl-string">'EventUser': class="hl-string">'System'})
        if payment_status == class="hl-string">'PAID':
             event_log.append({**common_attributes, class="hl-string">'ActivityName': class="hl-string">'Reimbursement Executed', class="hl-string">'EventTime': expense.get(class="hl-string">'payment_details',{}).get(class="hl-string">'paid_at') or expense[class="hl-string">'updated_at'], class="hl-string">'EventUser': class="hl-string">'System'})

        if expense.get(class="hl-string">'accounting_sync_status') == class="hl-string">'SYNCED':
            event_log.append({**common_attributes, class="hl-string">'ActivityName': class="hl-string">'Accounting Posted', class="hl-string">'EventTime': expense.get(class="hl-string">'synced_at') or expense[class="hl-string">'updated_at'], class="hl-string">'EventUser': class="hl-string">'System'})

    return event_log

if __name__ == class="hl-string">"__main__":
    try:
        raw_expenses = fetch_expenses(START_DATE, END_DATE)
        if raw_expenses:
            event_data = process_expenses_to_events(raw_expenses)
            df = pd.DataFrame(event_data)
            class=class="hl-string">"hl-comment"># Ensure required columns are present and ordered correctly
            df = df[[class="hl-string">'ExpenseReportId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'TotalAmount', class="hl-string">'EmployeeDepartment', class="hl-string">'EventUser', class="hl-string">'ReportStatus', class="hl-string">'PolicyViolationFlag']]
            df.sort_values(by=[class="hl-string">'ExpenseReportId', class="hl-string">'EventTime'], inplace=True)
            df.to_csv(OUTPUT_FILENAME, index=False)
            print(fclass="hl-string">"Successfully created event log: {OUTPUT_FILENAME}")
        else:
            print(class="hl-string">"No expenses found for the given date range.")
    except requests.exceptions.HTTPError as e:
        print(fclass="hl-string">"An HTTP error occurred: {e}")
        print(fclass="hl-string">"Response body: {e.response.text}")
    except Exception as e:
        print(fclass="hl-string">"An unexpected error occurred: {e}")

始める準備はできましたか？

このテンプレートを使ってデータ収集を効率化し、経費管理の最適化に向けて進めましょう。インサイトを見つけ、今日から業務効率の向上に取り組めます。

改善ガイドに戻る

テンプレートをダウンロード

Brexの経費管理を今すぐ改善

承認サイクルタイムを30％短縮し、従業員満足度を高めます。

無料トライアルを開始しましょう

クレジットカードは不要です。数分で設定できます。

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

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

経費管理の属性

経費管理のアクティビティ

データ抽出ガイド

Brexダッシュボードから取引データをCSVでエクスポート

ステップ

設定

クエリの例 sql

Brex Team REST APIを使ったPythonスクリプト

ステップ

設定

クエリの例 python

始める準備はできましたか？

Brexの経費管理を今すぐ改善