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

Brex

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

このテンプレートは、経費管理プロセスを分析するために不可欠なデータを収集するための明確なロードマップを提供します。重要な属性や主要なアクティビティを概説し、ソースシステムからこれらの情報を抽出するためのガイダンスも含まれています。効果的なプロセスマイニングに必要なすべてのデータを確実に収集するために、ぜひこのリソースをご活用ください。

分析推奨属性
プロセス全体で追跡すべき主要なアクティビティ
データ抽出のガイダンス

イベントログについて初めての方へ：プロセスマイニングのイベントログ作成方法.

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

経費精算属性

これらは、包括的な経費管理分析のためにイベントログに含めることを推奨するデータフィールドです。

3 必須 5 推奨 15 任意

	名前	説明
	アクティビティ名 ActivityName	経費レポートのライフサイクル内で発生した特定のイベントまたはタスクの名称です。
説明アクティビティ名とは、「経費レポート提出済み」、「マネージャー承認済み」、「精算実行済み」など、プロセスにおける各ステップを示すものです。これらのイベントが連なることで、プロセスフローが形成されます。これらのアクティビティを分析することで、プロセスマップの可視化、ステップ間のボトルネックの特定、そして承認や却下といった様々な結果の発生頻度を計算できます。これらは、経費管理プロセス中に何が起こっているかを理解するための基本的な情報となります。その重要性この属性は、プロセスマップを構築し、各経費レポートがどのようなイベントの順序をたどるかを理解するために極めて重要です。取得元この情報は、Brexシステム内のイベントログまたはトランザクションステータスから取得されます。ステータスコードやイベントタイプから、ユーザーにとって分かりやすい名称へのマッピングが必要になる場合があります。例経費精算書作成済みマネージャー承認財務却下済み精算実行済み
	イベント日時 EventTime	特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプ。
説明イベント_タイムは、プロセス内の各アクティビティの正確な日付と時刻を提供します。この時間情報は、イベントの時系列順序を確立するため、プロセス_マイニングにとって根本的です。このタイムスタンプは、アクティビティ間のサイクル_タイムの計算、待機時間や遅延の特定、および異なる期間におけるプロセス_パフォーマンスの分析に使用されます。これにより、「平均マネージャーレビュー時間」や「払い戻し実行ラグ」といった主要なメトリクスが強化され、ボトルネック_分析とパフォーマンス_モニタリングを直接サポートします。その重要性タイムスタンプは、サイクルタイムや待機時間といった時間ベースのあらゆるメトリクスを算出するために不可欠であり、これらは遅延を特定する上で非常に重要です。取得元 Brexにおけるすべてのイベントまたは取引記録には、関連するタイムスタンプが必要です。これは、APIレスポンスまたは経費精算書のデータ_エクスポートで見つけることができます。例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
	経費精算書ID ExpenseReportId	経費レポートの一意の識別子であり、そのライフサイクルを追跡するための主要なケース識別子として機能します。
説明経費レポートIDは、経費管理プロセスの基礎となる重要な要素です。作成、提出から承認、精算に至るまで、関連するすべてのアクティビティを単一のケースとしてまとめます。プロセスマイニングでは、このIDを用いることで各経費レポートのライフサイクルをエンドツーエンドで分析できます。レポートがたどった正確な経路を再構築し、総サイクル時間を測定したり、レポートが修正のために差し戻された場合の再作業ループを特定したり、一般的なフローや例外的なフローを理解するためにプロセスバリアントを分析したりするために活用されます。その重要性このIDは、経費レポートの完全なライフサイクルを追跡するために不可欠であり、サイクルタイム、ボトルネック、プロセス逸脱の分析を可能にします。取得元これはBrexの経費管理モジュールにおける主要な識別子であり、通常、経費レポート関連のすべてのデータエクスポートおよびAPIエンドポイントで利用可能です。例 ER-2023-08-1012ER-2023-09-2345ER-2023-10-5567
	イベント_ユーザー EventUser	アクティビティを実行したユーザー（例：レポートを承認したマネージャー）を指します。
説明イベントユーザー属性は、特定のアクティビティを担当する個人を識別します。これは、レポートを提出する従業員、それをレビューするマネージャー、または精算を処理する財務チームのメンバーである可能性があります。この属性は、「承認者パフォーマンス＆ワークロード」ダッシュボードで示されるように、ワークロード分析とパフォーマンス追跡に不可欠です。どの承認者が最も多くのレポートを処理しているか、誰が最も迅速に承認しているか、そしてプロセスにおいてボトルネックとなっている可能性のある個人がいるかどうかを特定するのに役立ちます。これにより、よりバランスの取れた作業配分と、必要な場所への的を絞ったサポートが可能になります。その重要性アクションの責任者を特定し、個々のレベルでのワークロード_分析、パフォーマンス_追跡、およびボトルネックの特定を可能にします。取得元このデータは通常、Brexの経費レポートの監査証跡またはイベント履歴に記録されます。例 john.smith@example.comjane.doe@example.comfinance-bot
	ポリシー違反フラグ PolicyViolationFlag	経費精算書がポリシー違反のフラグを付けられたかどうかを示すブール_フラグです。
説明この属性は、Brexの自動ポリシーエンジンがカテゴリ制限超過や領収書不足といった潜在的な違反を検出した際に設定される、シンプルな真偽値インジケーターです。このフラグはコンプライアンス分析の基礎であり、「ポリシー違反率」KPIの算出根拠となります。これにより、ポリシー違反のレポートを迅速にフィルタリングし、それが処理時間や却下率に与える影響を理解することができます。フラグ付きレポートを分析することで、会社ポリシーの改善や、従業員へのさらなるガイダンスが必要な領域を特定するのに役立ちます。その重要性コンプライアンス_モニタリングを直接サポートし、ポリシー違反がプロセス_効率と手戻り作業に与える影響を定量化するのに役立ちます。取得元これはBrexの経費レポートデータ内のブールフィールドまたはステータスインジケーターである可能性が高く、多くの場合、そのポリシーエンジンによって管理されます。例 truefalse
	レポートステータス ReportStatus	経費レポートのライフサイクルにおける現在のステータスを指します。
説明レポートステータスは、経費レポートがプロセス内で現在どの段階にあるか（例：「マネージャー承認待ち」、「承認済み」、「支払い済み」、「却下済み」など）のスナップショットを提供します。この属性は、特に「未処理経費レポートステータスモニター」ダッシュボードのような運用監視において極めて重要です。マネージャーや財務チームは、現在の作業負荷を迅速に把握し、特定のステータスで滞留しているレポートを特定し、アクションの優先順位付けを行うことができます。各ステータスで費やされた時間を分析することで、プロセスの遅延や非効率性を正確に特定するのに役立ちます。その重要性経費レポートがワークフローのどこにあるかの現在のスナップショットを提供します。これは、運用ダッシュボードやステータスモニタリングにとって極めて重要です。取得元これはBrex内の経費レポートオブジェクトにおける主要なステータスフィールドです。例 PENDING_APPROVALAPPROVED却下済み支払完了
	合計金額 TotalAmount	経費レポートの総金額を示します。
説明この属性は、経費レポートで請求される総額を示します。これは、支出パターンと経費プロセスの財務的影響を理解するための重要な財務指標です。分析において、総額は経費レポートを異なる金額帯（例：高額レポートと低額レポートなど）に分類するために使用でき、それぞれ異なる承認経路や精査レベルを持つ場合があります。また、財務報告、予算分析、部門別またはカテゴリ別の支出傾向の特定にも不可欠です。その重要性この属性により、より厳格な精査や長い承認時間を要する可能性のある高額な経費レポートを特定するなど、財務分析が可能になります。取得元これはBrex内のすべての経費レポートに関連付けられた標準フィールドです。API応答またはエクスポートにおける主要な経費レポートオブジェクト内で確認できます。例 150.752500.0079.99
	従業員部署 EmployeeDepartment	経費レポートを提出した従業員の部署です。
説明この属性は、申請した従業員が所属する事業部門（例：営業、エンジニアリング、マーケティングなど）を特定します。これは分析における重要な組織的側面です。部門別にデータを分析することで、組織の特定の部門に固有のプロセスバリエーション、ボトルネック、またはコンプライアンス問題を特定するのに役立ちます。例えば、ある部門が他の部門よりも著しく高い却下率や長い承認時間を有している場合、それは的を絞ったトレーニングやプロセス調整の必要性を示唆します。また、部門予算の追跡やコスト配分にとっても不可欠です。その重要性異なる事業部門間でのプロセス_パフォーマンスのフィルタリングと比較を可能にし、部門固有の問題や傾向の特定に役立ちます。取得元この情報は通常、Brex内の従業員プロファイルから取得され、多くの場合、人事情報システム（HRIS）から同期されています。例営業エンジニアリングマーケティング財務
	サイクルタイム CycleTime	経費レポートの作成から最終完了までに経過した時間の合計です。
説明サイクル_タイムは、各経費精算書のエンドツーエンドの期間を測定する計算メトリクスです。通常、最初のイベント（例：「経費精算書作成」）のタイムスタンプと最後のイベント（例：「払い戻し実行済み」または「会計記帳済み」）のタイムスタンプの差として計算されます。これは、プロセス全体の効率を測定するための最も基本的なKPIの一つであり、「経費精算書のエンドツーエンド_サイクル_タイム」ダッシュボードを直接サポートします。サイクル_タイムを分析することで、長期化しているケースを特定し、プロセス_パフォーマンスの傾向を理解し、プロセス改善イニシアチブの影響を測定するのに役立ちます。その重要性これは、経費管理プロセス全体（開始から終了まで）の速度と効率を測定する主要業績評価指標（KPI）です。取得元これは、各ケースの最新のイベントタイムスタンプから最も古いイベントタイムスタンプを差し引くことで、プロセスマイニングツール内で計算されます。例 3日4時間10日1時間22時間30分
	ソースシステム 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	マネージャーまたは財務担当者が経費レポートを却下した際に提示する理由です。
説明この属性は、経費レポートが却下された際に記載される自由記述または事前に定義された却下理由を記録します。これは自動ポリシーフラグとは異なり、承認者による手動の判断を示します。却下理由を分析することは、プロセス障害や再作業の根本原因を理解する上で鍵となります。これにより、よくある提出エラー、不明確なポリシー、または従業員やマネージャーによる誤解を特定するのに役立ちます。この情報は、トレーニング資料やFAQの改善に活用でき、最終的に却下率と再作業率の削減につながります。その重要性手動による却下が発生する理由を説明し、ユーザー_トレーニングの改善と将来のエラー削減に利用できる直接的なフィードバックを提供します。取得元これは通常、Brex UIで承認者が「却下」アクションを実行する際に記入できるコメントフィールドです。例誤った経費カテゴリが選択されました。より詳細な事業上の根拠をご提示ください。この購入は事前承認されていませんでした。
	国 Country	従業員または経費取引に関連する国を示します。
説明この属性は、従業員の主要なオフィスまたはコストセンターの国を示します。グローバル企業にとって、これは比較分析のための不可欠な要素です。国別にプロセスを分析することで、プロセスパフォーマンス、コンプライアンス率、または支出行動における地域差を明確にできます。例えば、現地の規制や異なる管理体制が原因で、ある国では承認時間が長くなる可能性がある、といった洞察が得られます。この情報は、現地のニーズに対応しながらプロセスをグローバルに標準化する上で貴重です。その重要性多国籍企業にとって重要な、異なる地理的地域間でのプロセス_パフォーマンスとコンプライアンスの分析を可能にします。取得元 Brex内の従業員プロファイル情報から取得され、多くの場合、中央のHRシステムから同期されています。例米国CANGBRDEU
	従業員名 EmployeeName	経費レポートを作成し提出した従業員の氏名です。
説明この属性は、経費レポートが提出された従業員の名前を示します。イベントユーザーがアクションを実行した人物を特定するのに対し、従業員名は経費レポートケースの対象を識別します。分析では、これにより従業員ごとの経費追跡が可能になります。ポリシー違反のあるレポートを頻繁に提出する個人や、常にレポートが却下される個人を特定するのに役立ち、追加トレーニングの必要性を示唆します。また、組織内の異なる従業員や役割ごとの支出パターンを理解するのにも役立ちます。その重要性経費精算書の所有者を特定し、個々の従業員レベルでの提出品質とコンプライアンスの分析を可能にします。取得元これは、Brexにおける作成者のユーザープロファイルからリンクされている、すべての経費レポートに関する基本的な情報です。例 Alice Johnsonロバート・ウィリアムズMaria Garcia
	手戻り IsRework	レポートが少なくとも一度修正のために差し戻された場合に「真」となる計算済みのフラグです。
説明このブール属性は、プロセスフローから派生します。履歴に「レポート差し戻し」アクティビティが含まれる経費レポートに対して「true」に設定されます。これにより、再作業が行われたケースを簡単にタグ付けし、分析することが可能になります。このフラグは、「経費レポート再作業率」KPIの算出や、「ポリシー違反＆再作業分析」ダッシュボードの機能強化に利用されます。プロセスをスムーズに流れるケースと差し戻されるケースを容易に比較でき、再作業に伴う時間とコストを定量化するのに役立ちます。その重要性追加作業と修正が必要だった経費精算書を特定し、手戻りの原因とコストの分析を可能にします。取得元この属性はソースシステムにはなく、ケースのアクティビティシーケンスに「レポート差し戻し」またはそれに類似する再作業アクティビティが含まれているかどうかを確認することで計算されます。例 truefalse
	支払方法 PaymentMethod	経費がどのように支払われたかを示します（例：法人カードまたは個人資金）。
説明この属性は、会社発行のBrexカードで支払われた経費と、従業員が立て替えて精算を必要とする経費とを区別します。この区分は、支払い方法によってプロセスが大きく異なるため重要です。法人カードによる取引は検証と照合のプロセスを経るのに対し、立て替え精算は申請と支払いのプロセスに従います。支払い方法別に分析することで、それぞれのフローに固有の問題を特定し、独立して最適化することが可能になります。その重要性法人カード経費と立替経費（自己負担による精算）では、プロセスフローや必要なステップが異なることが多いため、これはバリアント分析の重要な属性となります。取得元この情報は、Brex内のトランザクションデータに本来的に含まれています。例 Brex法人カード精算請求書払い
	期限内の領収書添付 ReceiptsAttachedOnTime	レポートが提出される前に領収書が添付されたかどうかを示すフラグです。
説明この計算されたブール属性は、一般的なプロセスベストプラクティス、すなわち「レビューのために経費レポートを提出する前に、必要なすべての領収書を添付すること」への順守度を測定するために設計されています。特定のケースにおいて「領収書添付済み」アクティビティが「経費レポート提出済み」アクティビティよりも前に発生した場合に「true」に設定されます。このフラグは、「領収書順守と影響」ダッシュボードおよび「領収書添付順守」KPIを直接サポートします。この属性を分析することで、領収書の遅延や不足がどのくらいの頻度で発生するかを定量化し、この行動が遅延、却下、再作業といったプロセス結果とどのように関連しているかを把握するのに役立ちます。その重要性領収書提出ポリシーへのコンプライアンスを測定し、プロセス遅延と却下の一般的な根本原因を特定するのに役立ちます。取得元これは、各ケース内の「領収書添付済み」アクティビティと「経費レポート提出済み」アクティビティのタイムスタンプを比較することで、プロセスマイニングツール内で計算されます。例 truefalse
	終了日時 EndTime	アクティビティの完了時刻を示すタイムスタンプ。
説明開始時刻（イベント時刻）がアクティビティの開始を示すのに対し、終了時刻はその完了を示します。これは、「マネージャーレビュー開始」と「マネージャー承認済み」のように、期間を伴うアクティビティに最も関連性が高いです。アクティビティの開始時刻と終了時刻の両方があることで、それに先行する待機時間と区別し、処理時間を正確に計算できます。これは、作業自体に要する時間を正確に測定するのに役立ち、ボトルネック分析の重要な要素となります。その重要性待ち時間とは区別される、アクティビティの正確な処理時間の計算を可能にし、より正確なボトルネック_分析につながります。取得元 EndTimeは、多くの場合、シーケンス内の次のアクティビティのStartTimeです。また、期間が定義されたアクティビティのソース_データにおける専用フィールドである場合もあります。例 2023-10-26T10:05:12Z2023-10-26T14:40:00Z2023-10-27T09:15:25Z
	経費カテゴリ ExpenseCategory	出張費、食費、ソフトウェアなどの経費に割り当てられたカテゴリです。
説明経費カテゴリとは、従業員が経費の性質を説明するために選択する分類です。これは、会計処理、予算編成、およびポリシー施行のために使用されます。プロセスマイニングにおいて、経費をカテゴリ別に分類することで、プロセスのより詳細な分析が可能になります。例えば、国際出張のような特定の経費カテゴリが、より長い承認サイクルや高い却下率を持つかどうかを判断するのに役立ちます。この分析は、特定の種類の支出に対するポリシーとプロセスの改善をサポートします。その重要性支出の種類に基づいてプロセス_分析を可能にし、異なる経費タイプにおける異なる行動やボトルネックを明らかにすることができます。取得元これは経費明細項目上の標準フィールドであり、レポートが複数のカテゴリを含む場合、経費レポートレベルに集約する必要があります。例航空運賃会食・娯楽費ソフトウェアサブスクリプションオフィス用品
	自動化 IsAutomated	システムユーザーまたはボットによってアクティビティが実行されたかどうかを示すブール_フラグです。
説明この属性は、アクティビティが自動ポリシーチェックのようにシステムによって自動的に実行されたのか、それとも手動承認のように人間によって実行されたのかを識別します。自動アクティビティと手動アクティビティを区別することは、プロセスにおける自動化のレベルを理解するために不可欠です。これは、ルールベースシステムの有効性を評価し、さらなる自動化の機会を特定するのに役立ちます。例えば、自動的に承認されたレポートの数と手動での介入が必要なレポートの数を示すことができ、タッチレス処理を増やすための取り組みを導きます。その重要性プロセスにおける自動化レベルを測定し、どのステップが人間によって実行され、どのステップがシステムによって実行されるかを特定するのに役立ちます。取得元これは通常、イベントに関連付けられたユーザーを確認することで特定されます。システムが生成するイベントは、多くの場合、汎用的な「システム」または「ボット」ユーザーに関連付けられています。例 truefalse
	通貨 Currency	経費レポートの総額を示す通貨コードです。
説明通貨属性は、総額の単位（USD、EUR、GBPなど）を指定します。これは、特に複数の通貨を扱う多国籍企業にとって、正確な財務分析に不可欠です。この属性により、財務データが正しく解釈されることが保証されます。経費金額の適切な集計と比較が可能になり、多くの場合、共通の報告通貨への換算が必要となります。異なる通貨の金額を合算するという分析上の誤りを防ぐ上で重要です。その重要性多通貨環境における財務の正確性を確保し、経費値の正しい集計と報告を可能にします。取得元このフィールドは通常、Brexの経費レポートデータにおいて、金額フィールドと合わせて利用可能です。例 USDEURGBP

必須推奨任意

経費精算アクティビティ

これらは、経費管理における正確なプロセスの発見のために、イベントログに記録すべき主要なプロセスステップとマイルストーンです。

7 推奨 7 任意

	アクティビティ	説明
	マネージャー承認	一次マネージャーが経費レポートをレビューし、次の処理のために承認しました。これは、レポートを次の段階（通常は財務レビューまたは自動承認）に進める重要な決定点です。
その重要性このマイルストーンは、最初の承認ステップの完了を示します。承認サイクル時間、マネージャーのワークロード、および「初回承認率」を追跡するために不可欠です。取得元このイベントは、承認者のIDとタイムスタンプを含み、承認履歴テーブルまたは監査証跡に明示的に記録される可能性が高いです。取得イベントログまたは「マネージャー承認済み」へのステータス変更と関連するタイムスタンプから取得されます。イベントタイプ explicit
	レポート差し戻し	承認者（マネージャーまたは経理担当者）がレポートを従業員に差し戻し、修正を依頼します。これは厳密な却下とは異なり、手戻りのループを開始します。
その重要性このアクティビティは、再作業の主要な指標です。その頻度を追跡することは、「経費レポート再作業率」KPIと「ポリシー違反＆再作業分析」ダッシュボードにとって不可欠です。取得元これは、「修正が必要」または「差し戻し」へのステータス変更から推測される可能性が高いです。システムはこのステータス更新のタイムスタンプを記録すべきです。取得「修正が必要」のような状態へのステータス変更から推測され、しばしばコメントを伴います。イベントタイプ inferred
	会計計上済み	経費データが企業の総勘定元帳やERPシステムに正常に転記される最終ステップを示します。これにより、経費レポートの財務照合が完了します。
その重要性このアクティビティは、財務会計の観点からプロセスが完了したことを確認します。精算と転記の間の遅延は、システム連携や会計ワークフローに問題がある可能性を示唆します。取得元これは、API確認または会計システムとの同期成功後のステータス更新を介して取得される可能性が高いです。イベントのタイムスタンプは転記された時間を示します。取得統合されたERPまたは会計ソフトウェアからのAPIコールバック成功時、またはステータス更新時に記録されます。イベントタイプ explicit
	精算実行済み	このアクティビティは、実際に支払いが従業員に実行された瞬間を示します。これは従業員の視点から見ると最終ステップであり、プロセスの成功裏の完了を意味します。
その重要性これはプロセスの主要な成功終点です。「平均エンドツーエンドサイクルタイム」と「精算実行遅延」KPIの算出に必要であり、従業員満足度に直接影響を与えます。取得元このイベントは、支払トランザクションログ、または銀行や決済処理業者からのAPI確認から取得されるべきです。実際の支払実行日に対応します。取得実行タイムスタンプを含む支払い取引ログから取得されます。イベントタイプ explicit
	経費精算書作成済み	このアクティビティは、従業員による経費レポートの開始を示します。システムは、新しい経費レポートが下書きとして、または初期の経費項目が追加された状態で生成された際に、このイベントを記録します。
その重要性これはプロセスの主要な開始イベントです。この時点から提出までの時間を分析することで、従業員の行動や経費報告における潜在的な遅延を理解するのに役立ちます。取得元このイベントは、Brexデータベース内の経費レポートオブジェクトまたはレコードの作成タイムスタンプから取得される可能性が高いです。これは経費レポートIDに関連する最も古いタイムスタンプと一致するはずです。取得経費精算書のヘッダーレコードの作成日によって識別されます。イベントタイプ explicit
	経費精算書提出済み	このアクティビティは、従業員が完成した経費レポートを正式に承認のために提出した際に発生します。これは、レポートのステータスを「下書き」または「オープン」から「承認待ち」に移行させる、重要なユーザー主導のアクションです。
その重要性これは、承認ワークフローを正式に開始する主要なマイルストーンです。提出から最終承認までの時間は、全体のサイクルタイムを構成する重要な要素です。取得元これは通常、監査ログに明示的に記録されるイベント、または「提出済み」や「マネージャー承認待ち」へのステータス変更とそれに対応するタイムスタンプから推測されるものです。取得イベントログ、または経費精算書のレコードにある`submission_timestamp`フィールドから取得されます。イベントタイプ explicit
	財務承認済み	財務部門はレビューを完了し、経費レポートに最終承認を与えました。これは、精算処理に進む前の最後の承認段階です。
その重要性これは支払いを承認する重要なマイルストーンです。完全な承認サイクルを測定するための終点であり、「精算実行遅延」KPIを測定するための始点となります。取得元このイベントは、最終承認者のIDとタイムスタンプを含め、承認履歴または監査証跡に明示的に記録されるべきです。取得イベントログまたは「財務承認済み」もしくは「支払い承認済み」へのステータス変更から取得されます。イベントタイプ explicit
	ポリシー違反としてフラグ付けされました	レポート内の1つ以上の経費項目が会社の方針に違反していることを示す自動または手動のイベントです。これは、システム_ルールがトリガーされた場合、またはレビュー担当者が手動で問題をフラグ付けした場合に捕捉できます。
その重要性このアクティビティは、「ポリシー違反＆再作業分析」ダッシュボードおよび「ポリシー違反率」KPIにとって極めて重要です。これにより、一般的なコンプライアンス問題やポリシー明確化が必要な領域を特定するのに役立ちます。取得元「ポリシー違反フラグ」属性が真に設定されたことから派生します。タイムスタンプはフラグのステータスが最後に更新された時になります。取得ポリシー違反を示すブール_フラグまたはステータス_フィールドの変更から推測されます。イベントタイプ inferred
	マネージャーレビュー開始	このアクティビティは、経費レポートがマネージャーの承認キューに入った時点を示します。通常、提出直後にレポートのステータスが「マネージャー承認待ち」に変更されたことから推測されます。
その重要性これは最初の承認段階の開始を示します。この時点から「マネージャー承認済み」または「マネージャー却下済み」までの期間を測定することは、「平均マネージャーレビュー時間」KPIにとって重要です。取得元これは、経費レポートのステータスが「マネージャー承認待ち」または類似の状態に移行した際のタイムスタンプから推測されます。多くの場合、「経費レポート提出済み」イベントと同時期に発生します。取得「マネージャー承認待ち」へのステータス変更のタイムスタンプから推測されます。イベントタイプ inferred
	マネージャー却下済み	一次マネージャーは経費レポートをレビューし、却下しました。このアクションは通常、プロセスを停止させるか、修正のためにレポートを従業員に差し戻すことになります。
その重要性このアクティビティは、否定的な結果でありプロセス上の例外を示します。「経費レポート却下率」の算出や、最初の承認段階での失敗原因を特定するために極めて重要です。取得元これは、承認と同様に、タイムスタンプと理由コードを伴って承認履歴テーブルまたは監査証跡に明示的に記録されるべきです。取得イベントログまたは「マネージャー却下済み」へのステータス変更と関連するタイムスタンプから取得されます。イベントタイプ explicit
	精算予定	最終承認後、経費精算書は次回の払い戻しバッチで支払いのためにキューに入れられます。このアクティビティは、承認から支払いシステムへの引き渡しを表します。
その重要性このステップは、最終承認と実際の支払い処理の間に発生する遅延を明らかにできます。これにより、承認のボトルネックと支払いシステムの非効率性を区別するのに役立ちます。取得元これは、「支払い準備完了」または「予定済み」へのステータス変更から推測される可能性があります。また、システムが別の支払いシステムやERPシステムと連携している場合は、明示的なイベントとして記録されることもあります。取得「支払い保留中」へのステータス変更、または支払いバッチ_レコードの作成から推測されます。イベントタイプ inferred
	財務レビュー開始	経費精算書が最終レビューのために経理部門または会計部門のキューに入った時点を示します。これは通常、マネージャー承認後のステータス変更から推測されます。
その重要性これは最終的で、しばしば最も重要な承認段階の開始を知らせます。その期間を分析することは、財務部門のボトルネックを特定するのに役立ちます。取得元これは、マネージャー承認後、レポートのステータスが「財務承認待ち」または類似の状態に変わった際のタイムスタンプから推測されます。取得「財務レビュー待ち」へのステータス変更のタイムスタンプから推測されます。イベントタイプ inferred
	財務却下済み	財務部門は経費レポートを却下しました。これは通常、ポリシー、コンプライアンス、または書類上の理由によるものです。この却下は最終的なものであり、プロセスを停止させます。
その重要性これは主要な例外イベントです。その発生頻度と原因を分析することは、コンプライアンス違反の状況を理解し、全体的な「経費レポート却下率」を算出するために極めて重要です。取得元他の承認決定と同様に、これは承認者のID、タイムスタンプ、および理由とともに監査ログに明示的に記録されるべきです。取得イベントログまたは「財務却下済み」へのステータス変更から取得されます。イベントタイプ explicit
	領収書添付済み	ユーザーが領収書の画像や文書を経費明細にアップロードまたは添付するアクションを指します。これは通常、各添付にタイムスタンプが付与された明示的なイベントとして記録されます。
その重要性このアクティビティの追跡は、「領収書順守と影響」ダッシュボードにとって極めて重要です。遅延や却下が、領収書の不足または提出遅れと相関しているかどうかを判断するのに役立ちます。取得元これは、添付ファイルを経費明細項目にリンクする関連テーブルに記録される可能性が高いです。各添付レコードは独自の作成タイムスタンプを持つべきです。取得ユーザーが経費明細に関連付けられたファイルを正常にアップロードしたときに記録されます。イベントタイプ explicit

推奨任意

抽出ガイド

Brexからのデータ取得方法

ステップ

Brexにログイン: Brexダッシュボードに、管理者または経理担当者の権限を持つアカウントでアクセスしてください。これらのロールは、会社全体の経費データを表示およびエクスポートするために必要です。
経費に移動: 左側のナビゲーションメニューから「経費」セクションを選択し、経費精算ダッシュボードにアクセスします。
会社経費にアクセス: 「経費」セクション内で、すべての会社経費が表示されるビューに移動します。「会社経費」または類似の名称である場合があります。
フィルターを適用: 目的のデータセットを取得するためにフィルターを設定します。例えば、関連性の高いプロセスビューを得るために、過去6ヶ月間の特定の日付範囲を設定します。各レポートの全ライフサイクルを把握するために、すべての経費ステータス（例：下書き、承認待ち、承認済み、却下済み、支払い済み）を含めるようにしてください。
エクスポートを開始: 「エクスポート」ボタンを見つけてクリックします。これにより、エクスポート設定オプションを含むダイアログまたは新しいページが開きます。
エクスポート設定を構成: エクスポート形式として「CSV」を選択します。列選択オプションでは、ID、金額、ユーザー、部署、ステータス、そして特に利用可能なすべてのタイムスタンプ（例：作成日、申請日、承認日、支払日、エクスポート日）に関連するすべての利用可能なフィールドを含めるようにしてください。すべてのタイムスタンプをキャプチャすることは、イベントログの構築に不可欠です。
CSVファイルをダウンロード: 選択内容を確認し、生成されたCSVファイルをローカルマシンにダウンロードします。このファイルには、生データが含まれています。
データ形式を理解: エクスポートされたファイルは、経費またはレポートごとに1行、複数の日付列を含む状態ベースのログです。プロセス_マイニングに適したものにするには、各行が1つのアクティビティを表すイベントログに変換する必要があります。
データを変換: CSVをMicrosoft Excel、Google スプレッドシートなどのスプレッドシートプログラムで開くか、Pythonのようなスクリプト言語を使用します。元のエクスポートの各行について、最終イベントログに複数の新しい行を作成する必要があります。これは、各関連アクティビティのタイムスタンプごとに1行です。例えば、申請、マネージャー承認、支払いに関するタイムスタンプを含む単一の経費精算書行は、新しいファイルでは3つの異なる行になります。
列をイベントログ_スキーマにマッピング: データを変換する際に、Brexエクスポートからの列を必要なイベントログ_構造にマッピングします。Expense IDはExpenseReportIdになり、各タイムスタンプ列は対応するアクティビティのEventTimeになり、アクティビティ名（例：「Expense Report Submitted」）はActivityNameとして設定されます。
最終イベントログを保存: 変換が完了し、ExpenseReportId、ActivityName、EventTimeの列を持つ縦長形式のテーブルが作成されたら、ファイルを新しいCSVとして保存します。このファイルは、プロセス_マイニング_ツールへのアップロード用に正しくフォーマットされています。

設定

ユーザー権限: 全従業員の経費データにアクセスしてエクスポートするには、Brexの管理者または経理担当者のロールが必要です。
日付範囲: 意味のある分析のために、3〜6ヶ月分のデータをエクスポートすることをお勧めします。1年以上のデータをエクスポートすると、処理が遅くなり、非常に大きなファイルになる可能性があります。
ステータスフィルター: プロセス全体を最初から最後まで把握するには、ステータスフィルターが下書き、承認待ち、承認済み、却下済み、支払い済みなど、すべてのステータスを含むように設定されていることを確認してください。
エクスポート列: エクスポート時には、利用可能なすべての列を選択してください。これは、EmployeeDepartmentやTotalAmountといった属性をキャプチャするため、特にプロセス_タイムラインを正確に再構築するために必要なすべてのタイムスタンプを取得するために不可欠です。

a クエリ例 config

/*
 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ダッシュボードにログインします。開発者セクションに移動し、新しいユーザー_トークンを生成します。トークン作成時には、必要なデータにアクセスするために、team:read、transactions:read、expenses:readのスコープを付与する必要があります。生成されたトークンを安全にコピーしてください。
Pythonスクリプトのセットアップ: extract_brex_expenses.pyという名前の新しいファイルを作成します。「クエリ」セクションで提供されている完全な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開発者ダッシュボードからのユーザー_トークンが必要です。このトークンには、team:read、transactions:read、expenses:readのスコープが有効になっている必要があります。
日付範囲: スクリプトにはSTART_DATEとEND_DATEの変数が含まれています。初期分析では、代表的なデータセットを確保しつつ、過度な負荷をかけないよう、3〜6ヶ月分のデータを抽出することをお勧めします。
ページネーション制限: スクリプトは、API呼び出しごとに最大100件の経費（limit=100）を要求するようにハードコードされており、APIから提供されるnext_cursorを使用して指定された日付範囲内のすべてのレコードを自動的に取得します。
パフォーマンスに関する考慮事項: 1年を超えるデータを抽出する場合、APIレート制限と処理するデータ量のため、スクリプトの実行に数分かかることがあります。大規模な抽出は、オフピーク時に実行することをお勧めします。
データ粒度: スクリプトは、経費オブジェクトとそのステータス履歴に基づいてイベントを抽出します。これは標準的なワークフローを前提としており、カスタム承認フローの場合はスクリプトの処理ロジックの調整が必要になる場合があります。

a クエリ例 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ダッシュボードCSV取引エクスポート

ステップ

設定

a クエリ例 config

Brexチーム向けREST APIを利用したPythonスクリプト

ステップ

設定

a クエリ例 python

今すぐ始めますか？

今すぐBrexの経費管理を最適化しましょう

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

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

経費精算属性

経費精算アクティビティ

抽出ガイド

BrexダッシュボードCSV取引エクスポート

ステップ

設定

a クエリ例 config

Brexチーム向けREST APIを利用したPythonスクリプト

ステップ

設定

a クエリ例 python

お客様のプライバシーを大切にしています

今すぐ始めますか？

今すぐBrexの経費管理を最適化しましょう