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

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.comfinance-bot
	ポリシー違反フラグ PolicyViolationFlag	経費報告書がポリシー違反としてフラグ設定されたかどうかを示すブール型フラグです。
説明 Brexの自動ポリシーエンジンが、カテゴリ上限を超える経費や領収書の不足など、違反の可能性を検出した際に設定されるtrueまたはfalseの指標です。コンプライアンス分析の基礎となり、「ポリシー違反率」KPIの算出に使います。非準拠の報告書をすばやく絞り込み、処理時間や却下率への影響を把握できます。フラグが設定された報告書を分析すると、会社のポリシーを見直し、従業員への案内が必要な領域を特定できます。重要な理由コンプライアンス監視を直接支援し、ポリシー違反がプロセス効率や手戻りに与える影響を定量化できます。入手先通常は、Brexの経費報告書データ内にあるブール型フィールドまたはステータス指標です。多くの場合、ポリシーエンジンによって管理されます。例 truefalse
	合計金額 TotalAmount	経費報告書の金銭的な合計額です。
説明経費報告書で申請される合計金額を示す属性です。支出パターンと経費プロセスの財務的な影響を把握するための重要な財務指標です。分析では、経費報告書を高額・低額などの金額帯に分けられます。金額帯によって承認経路や確認の厳しさが異なる場合があります。また、財務報告、予算分析、部門別・カテゴリ別の支出傾向の把握にも欠かせません。重要な理由高額な経費報告書を特定するなどの財務分析に利用できます。高額な報告書は、より詳細な確認や、より長い承認時間を必要とする場合があります。入手先 Brexのすべての経費報告書に関連付けられた標準フィールドです。APIレスポンスまたはエクスポートの主要な経費報告書オブジェクトで確認できます。例 150.752500.0079.99
	報告書ステータス ReportStatus	ライフサイクルにおける経費報告書の現在のステータスです。
説明報告書ステータスは、経費報告書がプロセスのどの位置にあるかを示します。たとえば、「マネージャー承認待ち」「承認済み」「支払い済み」「却下」などです。「未完了経費報告書ステータスモニター」ダッシュボードなど、業務の監視に欠かせない属性です。マネージャーや財務チームは、現在の処理量をすばやく把握し、特定の状態で滞留している報告書を特定して、対応の優先順位を付けられます。各ステータスに費やされた時間を分析すると、プロセスの遅延や非効率を特定できます。重要な理由ワークフローにおける経費報告書の現在位置を示します。業務用ダッシュボードやステータス監視に欠かせない情報です。入手先 Brexの経費報告書オブジェクトに含まれる主要なステータスフィールドです。例承認待ち承認済み却下済み支払い済み
	従業員の所属部門 EmployeeDepartment	経費報告書を提出した従業員の所属部門です。
説明提出者が所属する営業、エンジニアリング、マーケティングなどの事業部門を示す属性です。分析における重要な組織軸となります。部門別にデータを分析すると、組織内の特定の部門に固有のプロセス差異、ボトルネック、コンプライアンス上の問題を特定できます。たとえば、ある部門だけ却下率や承認時間が大幅に高いことが分かれば、対象を絞ったトレーニングやプロセスの見直しにつなげられます。部門別の予算管理やコスト配賦にも重要です。重要な理由異なる事業部門間でプロセスパフォーマンスを絞り込み、比較できます。部門固有の問題や傾向の特定に役立ちます。入手先通常はBrex内の従業員プロフィールから取得します。多くの場合、人事情報システムと同期されています。例営業エンジニアリングマーケティング財務
	ソースシステム 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のユーザーインターフェースで承認者が「却下」アクションを実行する際に入力できるコメントフィールドです。例誤った経費カテゴリが選択されています。業務上の理由をより詳しく記載してください。この購入は事前承認されていません。
	国 Country	従業員または経費取引に関連付けられた国です。
説明従業員の主な勤務拠点またはコストセンターの所在国を示す属性です。グローバル企業にとって、比較分析に欠かせない軸となります。国別にプロセスを分析すると、プロセスパフォーマンス、コンプライアンス率、支出行動における地域差を明らかにできます。たとえば、現地の規制や異なる管理体制により、ある国で承認時間が長くなる場合があります。この情報は、地域ごとの要件に対応しながら、グローバルでプロセスを標準化する際に役立ちます。重要な理由異なる地域間でプロセスパフォーマンスとコンプライアンスを分析できます。多国籍組織にとって重要な情報です。入手先 Brex内の従業員プロフィール情報から取得します。多くの場合、中央人事システムと同期されています。例 USACANGBRDEU
	従業員名 EmployeeName	経費報告書を作成して提出した従業員の名前です。
説明経費報告書が提出された対象従業員の名前を示す属性です。イベントユーザーがアクションを実行した人物を示すのに対し、従業員名は経費報告書ケースの対象者を示します。分析では、従業員単位で経費を追跡できます。ポリシー違反を含む報告書を頻繁に提出する従業員や、継続的に報告書を却下されている従業員を特定し、追加トレーニングの必要性を判断できます。また、組織内の従業員や役割ごとの支出パターンの把握にも役立ちます。重要な理由経費報告書の所有者を特定し、従業員単位で提出品質とコンプライアンスを分析できます。入手先すべての経費報告書に含まれる基本情報であり、Brexの作成者ユーザープロフィールから関連付けられます。例 Alice JohnsonRobert WilliamsMaria Garcia
	手戻りかどうか IsRework	報告書が少なくとも1回、修正のために差し戻された場合にtrueとなる計算フラグです。
説明プロセスフローから算出されるブール型属性です。履歴に「報告書を修正のため差し戻し」アクティビティが含まれる経費報告書には「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	旅費、食費、ソフトウェアなど、経費に割り当てられたカテゴリです。
説明経費カテゴリは、経費の内容を示すために従業員が選択する分類です。会計、予算管理、ポリシー適用に使われます。プロセスマイニングでは、経費をカテゴリ分けすることで、プロセスをより詳細に把握できます。海外出張など特定のカテゴリで、承認サイクルが長い、または却下率が高いかどうかを確認できます。この分析は、支出の種類に応じたポリシーやプロセスの見直しに役立ちます。重要な理由支出の種類に基づいてプロセスを分析できます。経費の種類ごとに異なる行動やボトルネックを明らかにできます。入手先経費明細に含まれる標準フィールドです。1つの報告書に複数のカテゴリが含まれる場合は、経費報告書単位に集計する必要があります。例航空運賃食事・接待ソフトウェアサブスクリプション事務用品
	自動処理かどうか IsAutomated	アクティビティがシステムユーザーまたはボットによって実行されたかどうかを示すブール型フラグです。
説明自動ポリシーチェックのようにシステムが自動実行したアクティビティか、手動承認のように人が実行したアクティビティかを識別します。自動処理と手動処理を区別すると、プロセスの自動化レベルを把握できます。ルールベースのシステムの効果を評価し、さらなる自動化の機会を特定する際にも役立ちます。たとえば、自動承認された報告書と手動対応が必要な報告書の件数を比較し、人手を介さない処理を増やす取り組みにつなげられます。重要な理由プロセスの自動化レベルを測定し、人とシステムのどちらが各ステップを実行したかを特定できます。入手先通常は、イベントに関連付けられたユーザーを確認して判定します。システムが生成したイベントには、「system」や「bot」などの汎用ユーザーが関連付けられていることが多いです。例 truefalse
	通貨 Currency	経費報告書の合計金額に使用される通貨コードです。
説明通貨属性は、合計金額の単位を示します。USD、EUR、GBPなどが該当します。複数の通貨を扱うグローバルな組織では、正確な財務分析のために欠かせません。この属性により、財務データを正しく解釈できます。経費額を適切に集計・比較するには、共通の報告通貨への換算が必要になる場合があります。異なる通貨の金額を合算することによる分析上の誤りも防げます。重要な理由複数通貨の環境で財務上の正確性を確保し、経費額の正しい集計と報告を可能にします。入手先通常、Brexの経費報告書データでは金額フィールドとともに利用できます。例 USDEURGBP
	領収書を期限内に添付 ReceiptsAttachedOnTime	報告書の提出前に領収書が添付されたかどうかを示すフラグです。
説明経費報告書を確認に回す前に必要な領収書をすべて添付するという、一般的なベストプラクティスの遵守状況を測定する計算済みのブール型属性です。ケース内で「領収書添付」アクティビティが「経費報告書提出」アクティビティより前に発生した場合に「true」となります。「領収書遵守状況と影響」ダッシュボードと「領収書添付遵守率」KPIを直接支援します。この属性を分析すると、領収書の遅延や不足がどの程度発生しているかを定量化し、遅延、却下、手戻りなどのプロセス結果との相関を確認できます。重要な理由領収書提出ポリシーの遵守状況を測定し、プロセスの遅延や却下につながる一般的な根本原因を特定できます。入手先各ケース内の「領収書添付」と「経費報告書提出」アクティビティのタイムスタンプを比較し、プロセスマイニングツールで算出します。例 truefalse

必須推奨任意

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

経費管理におけるプロセスを正確に発見するため、イベントログに記録する主要なプロセス手順とマイルストーンです。

7 推奨 7 任意

	アクティビティ	説明
	上司が承認	第1段階のマネージャーが経費レポートを確認し、次の処理に進めることを承認した状態です。この重要な判断により、レポートは通常、財務確認または自動承認という次の段階へ進みます。
重要な理由この節目により、初回の承認手順が完了します。承認サイクルタイム、マネージャーの業務量、「First-Pass Approval Rate」を追跡するうえで重要です。入手先通常は、承認者のIDとタイムスタンプを含む承認履歴テーブルまたは監査証跡に明示的に記録されます。取得イベントログ、または対応するタイムスタンプを伴う「Manager Approved」へのステータス変更から取得します。イベントタイプ explicit
	会計計上完了	経費データが会社の総勘定元帳またはERPシステムに正常に計上される最終ステップを表します。これにより、経費精算の財務照合が完了します。
重要な理由このアクティビティは、財務会計の観点でプロセスが完了したことを確認します。払い戻しから計上までの遅延は、システム連携や会計ワークフローの問題を示している可能性があります。入手先通常は、会計システムとの同期が正常に完了した後のAPI確認、またはステータス更新を通じて取得します。イベントのタイムスタンプは計上時刻を示します。取得連携されたERPまたは会計ソフトウェアからのAPIコールバック、またはステータス更新が正常に完了した際に記録されます。イベントタイプ explicit
	払い戻し実行	このアクティビティは、従業員への支払いが実際に実行された時点を示します。従業員の視点では最終ステップにあたり、プロセスが正常に完了したことを表します。
重要な理由プロセスにおける主要な正常終了地点です。「エンドツーエンド平均サイクルタイム」と「払い戻し実行遅延」のKPIを算出するために必要であり、従業員満足度に直接影響します。入手先このイベントは、支払い取引ログ、または銀行や決済処理業者からのAPI確認を通じて取得します。実際に支払いが実行された日付に対応します。取得実行タイムスタンプを含む支払い取引ログから取得します。イベントタイプ explicit
	経費精算書を作成	このアクティビティは、従業員が経費レポートを開始したことを示します。新しい経費レポートのレコードが、下書きとして、または初期の経費項目が追加された状態で生成された際に、システムがこのイベントを記録します。
重要な理由このイベントは、プロセスの主な開始イベントです。ここから提出までの時間を分析すると、従業員の行動や、経費報告までに時間がかかる原因を把握できます。入手先このイベントは、Brexデータベース内の経費レポートオブジェクトまたはレコードの作成タイムスタンプから取得される可能性があります。Expense Report IDに関連付けられた最も早いタイムスタンプに対応する必要があります。取得経費レポートのヘッダーレコードの作成日に基づいて特定します。イベントタイプ explicit
	経費精算書を修正依頼として返却	マネージャーまたは財務部門の承認者が、修正のためにレポートを従業員へ差し戻す操作です。完全な却下とは異なり、手戻りのループが始まります。
重要な理由このアクティビティは、手戻りを示す主な指標です。発生頻度を追跡することは、「Expense Report Rework Rate」KPIと「Policy Violation & Rework Analysis」ダッシュボードに欠かせません。入手先通常は、「Needs Revision」または「Sent Back」へのステータス変更から推定します。このステータス更新のタイムスタンプを記録する必要があります。取得「Needs Revision」のような状態へのステータス変更から推定します。コメントを伴うこともよくあります。イベントタイプ inferred
	経費精算書を提出	従業員が完成した経費レポートを正式に承認へ提出した際に発生するアクティビティです。レポートのステータスを「Draft」または「Open」から「Pending Approval」へ移行させる、ユーザー主導の重要な操作です。
重要な理由これは、承認ワークフローを正式に開始する重要な節目です。提出から最終承認までの時間は、全体のサイクルタイムを構成する重要な要素です。入手先通常は監査ログに明示的なイベントとして記録されます。または、対応するタイムスタンプを伴う「Submitted」や「Pending Manager Approval」へのステータス変更から推定できます。取得イベントログ、または経費レポートレコードの「submission_timestamp」フィールドから取得します。イベントタイプ explicit
	財務部が承認	財務部門が経費レポートの確認を完了し、最終承認した状態です。払い戻し処理の前にある最後の承認ゲートです。
重要な理由支払いを承認する重要な節目です。承認サイクル全体の測定が終了する地点であり、「Reimbursement Execution Lag」KPIの測定開始地点でもあります。入手先最終承認者のIDとタイムスタンプを含め、承認履歴または監査証跡に明示的に記録する必要があります。取得イベントログ、または「Finance Approved」や「Approved for Payment」へのステータス変更から取得します。イベントタイプ explicit
	ポリシー違反を検出	レポート内の1つ以上の経費項目が会社のポリシーに違反していることを示す、自動または手動のイベントです。システムルールが発動した時点や、確認担当者が手動で問題を指摘した時点で記録できます。
重要な理由このアクティビティは、「Policy Violation & Rework Analysis」ダッシュボードと「Policy Violation Rate」KPIに欠かせません。よくあるコンプライアンス上の問題や、ポリシーを明確にすべき領域の特定に役立ちます。入手先「Policy Violation Flag」属性がtrueに設定されたことから導出します。タイムスタンプには、フラグのステータスが最後に更新された時刻を使用します。取得ポリシー違反を示すブール型フラグまたはステータスフィールドの変更から推定します。イベントタイプ inferred
	上司が却下	第1段階のマネージャーが経費レポートを確認し、却下した状態です。通常はプロセスを停止するか、修正のためにレポートを従業員へ差し戻します。
重要な理由このアクティビティは、否定的な結果とプロセス上の例外を示します。「Expense Report Rejection Rate」の算出や、最初の承認段階で失敗する理由の特定に欠かせません。入手先承認の場合と同様に、タイムスタンプと理由コードを含め、承認履歴テーブルまたは監査証跡に明示的に記録する必要があります。取得イベントログ、または対応するタイムスタンプを伴う「Manager Rejected」へのステータス変更から取得します。イベントタイプ explicit
	上司による確認を開始	経費レポートがマネージャーの承認キューに入った時点を示します。通常は、提出直後にレポートのステータスが「Pending Manager Approval」へ変更されたことから推定します。
重要な理由最初の承認段階の開始を示します。ここから「Manager Approved」または「Manager Rejected」までの所要時間を測定することは、「Average Manager Review Time」KPIにとって重要です。入手先経費レポートのステータスが「Pending Manager Approval」または同様の状態に移行した時刻から推定します。「Expense Report Submitted」イベントと同時に発生することもよくあります。取得「Pending Manager Approval」へのステータス変更時刻から推定します。イベントタイプ inferred
	払い戻しを予定	最終承認後、経費レポートは次回の払い戻しバッチで支払うためのキューに入ります。このアクティビティは、承認から支払いシステムへの引き継ぎを示します。
重要な理由この手順により、最終承認から実際の支払い処理までの遅延を明らかにできます。承認のボトルネックと支払いシステムの非効率を切り分けるのに役立ちます。入手先「Ready for Payment」または「Scheduled」へのステータス変更から推定できます。支払いシステムやERPシステムと連携している場合は、明示的なイベントとして記録されることもあります。取得「支払い待ち」へのステータス変更、または支払いバッチレコードの作成から推定されます。イベントタイプ inferred
	財務部が却下	財務部門が経費レポートを却下した状態です。通常は、ポリシー、コンプライアンス、書類上の理由によるもので、最終的な却下としてプロセスを停止します。
重要な理由これは重要な例外イベントです。発生頻度と原因を分析することは、コンプライアンス上の問題を理解し、全体の「Expense Report Rejection Rate」を算出するうえで欠かせません。入手先他の承認判断と同様に、承認者のID、タイムスタンプ、理由を含め、監査証跡に明示的に記録する必要があります。取得イベントログ、または「Finance Rejected」へのステータス変更から取得します。イベントタイプ explicit
	財務部による確認を開始	経費レポートが最終確認のために財務部門または経理部門のキューに入った時点を示します。通常は、マネージャーの承認後に発生するステータス変更から推定します。
重要な理由最終承認段階、そして多くの場合で最も重要な承認段階の開始を示します。所要時間を分析することで、財務部門のボトルネックを特定できます。入手先マネージャーの承認後、レポートのステータスが「Pending Finance Approval」または同様の状態に変更された時刻から推定します。取得「Pending Finance Review」へのステータス変更時刻から推定します。イベントタイプ inferred
	領収書を添付	ユーザーが経費明細に領収書の画像または書類をアップロード、あるいは添付する操作を示します。通常は、添付ごとにタイムスタンプを持つ明示的なイベントとして記録されます。
重要な理由このアクティビティの追跡は、「Receipt Adherence & Impact」ダッシュボードに欠かせません。遅延や却下が、領収書の不足または提出の遅れと関連しているかを確認できます。入手先通常は、添付ファイルと経費明細を関連付けるテーブルに記録されます。各添付レコードには、独自の作成タイムスタンプが設定されます。取得ユーザーが経費明細に関連付けられたファイルのアップロードを正常に完了した時点で記録されます。イベントタイプ explicit

推奨任意

抽出ガイド

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

ステップ

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

設定

**ユーザー権限：**全従業員の経費データにアクセスしてエクスポートするには、Brexで管理者または経理担当者のロールが必要です。
**対象期間：**意味のある分析を行うには、3～6か月分のデータをエクスポートすることを推奨します。1年を超えるデータをエクスポートすると、処理に時間がかかり、ファイルサイズが非常に大きくなる場合があります。
**ステータスフィルター：**プロセスの開始から完了までを記録するため、Draft、Pending Approval、Approved、Rejected、Paidなど、すべてのステータスを含むように設定してください。
**エクスポート列：**エクスポート時には、利用可能なすべての列を選択してください。EmployeeDepartmentやTotalAmountなどの属性に加え、プロセスの時系列を正確に再構成するために必要なすべてのタイムスタンプを取得するうえで重要です。

a サンプルクエリ 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セクションに移動し、新しいUser Tokenを生成します。必要なデータにアクセスするには、トークン作成時に次のスコープを付与する必要があります：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ダッシュボードのUser Tokenが必要です。トークンではteam:read、transactions:read、expenses:readのスコープを有効にしてください。
**対象期間：**スクリプトにはSTART_DATEとEND_DATE変数があります。初回分析では、代表性のあるデータセットを確保しつつ負荷を抑えるため、3～6か月分のデータを抽出することを推奨します。
**ページネーションの上限：**スクリプトはAPI呼び出し1回あたり最大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の経費管理を今すぐ最適化

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

無料トライアルを開始

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

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

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

経費管理の属性

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

抽出ガイド

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

ステップ

設定

a サンプルクエリ sql

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

ステップ

設定

a サンプルクエリ python

始める準備はできていますか？

Brexの経費管理を今すぐ最適化

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

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

経費管理の属性

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

抽出ガイド

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

ステップ

設定

a サンプルクエリ sql

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

ステップ

設定

a サンプルクエリ python

始める準備はできていますか？

Brexの経費管理を今すぐ最適化

プライバシーを大切にしています