> 持续流程改进 > 费用管理 > Brex > 数据模板

您的费用管理数据模板

Brex

← 返回改进指南

费用管理属性 (23) 费用管理活动 (14) 提取指南 (2)

您的费用管理数据模板

此模板为收集分析报销管理流程所需的 data 提供了清晰的路线图。它概述了关键属性、核心活动，并为从源系统中提取信息提供了指导。使用此资源可确保您为有效的 Process Mining 收集到所有必要 data。

建议分析的属性
流程中需追踪的关键活动
数据提取指南

不熟悉事件日志？了解如何创建流程挖掘事件日志.

下载模板

费用管理属性

这些是建议包含在 event log 中的 data 字段，以便进行全面的报销管理分析。

3 必填 5 推荐 15 可选

	名称	描述
	Event 时间 EventTime	指示特定活动或事件发生时间的时间戳。
描述 Event Time 提供了流程中每个活动的精确日期和时间。这种时间信息是 Process Mining 的基础，因为它确立了 event 的先后顺序。此 timestamp 用于计算活动间的周期时间，识别等待时间和延迟，并分析不同时间段的流程绩效。它驱动了诸如“平均经理审核时间”和“报销执行滞后时间”等核心指标，直接为瓶颈分析和绩效监控提供支持。为何重要 Timestamp 对于计算所有基于时间的指标（如周期时间和等待时间）至关重要，而这些指标是识别延迟的关键。获取方式 Brex 中的每个 event 或交易记录都应该有一个相关的 timestamp。这可以在 API 响应或报销单的 data 导出中找到。示例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
	报销单 ID ExpenseReportId	报销报告的唯一标识符，作为跟踪其生命周期的主要 case 标识符。
描述 “报销报告 ID”是报销管理流程的核心。它将从创建、提交到批准、报销的所有相关活动整合为一个 case。在 Process Mining 中，该 ID 支持对每份报销报告的旅程进行端到端分析。它被用于重建报告走过的准确路径、测量总周期时间、识别报告退回修改时的返工循环，并分析流程变体以理解常见流向和异常流向。为何重要此 ID 对于跟踪报销报告的完整生命周期至关重要，支持对周期时间、瓶颈和流程偏差进行分析。获取方式这是 Brex 报销管理模块中的主要标识符，通常存在于所有报销报告相关的 data 导出和 API 端点中。示例 ER-2023-08-1012ER-2023-09-2345ER-2023-10-5567
	活动名称 ActivityName	在报销报告生命周期中发生的特定 event 或任务名称。
描述 “活动名称”描述了流程中的一个步骤，例如“报销报告已提交”、“经理已批准”或“报销已执行”。这些 event 构成了流程流转的动作序列。分析这些活动可以实现流程图的可视化，识别步骤间的瓶颈，并计算批准或驳回等不同结果的发生频率。这是理解报销管理过程中实际情况的基础。为何重要该属性对于构建流程图以及理解每份报销报告所经历的 event 序列至关重要。获取方式此信息派生自 Brex 系统内的 event log 或交易状态。可能需要将状态代码或 event 类型映射为易于理解的名称。示例报销单已创建经理已审批财务已拒绝报销已执行
	Event User EventUser	执行该活动的用户，例如批准报告的经理。
描述 “Event 用户”属性标识了负责某项活动的特定个人。这可能是提交报告的员工、审核报告的经理，或是处理报销的财务人员。如“审批人绩效与工作量”dashboard 所示，该属性对于工作量分析和绩效跟踪至关重要。它有助于识别哪些审批人处理的报告最多、谁的审批速度最快，以及流程中是否存在可能成为瓶颈的个人。这实现了更平衡的工作分配，并在需要时提供针对性支持。为何重要识别负责某项操作的具体人员，从而在个人层面实现工作量分析、绩效跟踪和瓶颈识别。获取方式此 data 通常在 Brex 报销报告的审计追踪或 event 历史记录中捕获。示例 john.smith@example.comjane.doe@example.comfinance-bot
	员工部门 EmployeeDepartment	提交报销报告的员工所属部门。
描述该属性标识了提交报销的员工所属的业务部门，如销售部、工程部或市场部。它是分析的关键组织维度。按部门分析 data 有助于识别特定组织部门特有的流程变体、瓶颈或合规问题。例如，它可以揭示某个部门的驳回率是否显著高于其他部门，或者审批时间是否更长，从而指向对针对性培训或流程调整的需求。这对于部门预算跟踪和成本分配也至关重要。为何重要允许跨不同业务部门过滤和比较流程绩效，有助于识别特定部门的问题或趋势。获取方式此信息通常来源于 Brex 中的员工个人资料，通常从 HR 信息系统同步。示例销售工程部市场营销财务
	总金额 TotalAmount	报销报告的货币总值。
描述此属性代表报销报告中申请的总金额。它是理解支出模式和报销流程财务影响的关键财务指标。在分析中，总金额可用于将报销报告细分为不同的价值区间（如高额报告与低额报告），这些报告可能具有不同的审批路径或审查力度。这对于财务报告、预算分析以及按部门或类别识别支出趋势也必不可少。为何重要此属性支持财务分析，例如识别可能需要更多审查或审批时间更长的高额报销报告。获取方式这是与 Brex 中每份报销报告关联的标准字段。可以在 API 响应或导出的主报销报告对象中找到。示例 150.752500.0079.99
	报告状态 ReportStatus	报销报告在其生命周期中的当前状态。
描述 “报告状态”提供了报销报告在流程中当前位置的快照，例如“等待经理审批”、“已批准”、“已支付”或“已驳回”。该属性对于运营监控至关重要，特别是对于“未结报销报告状态监控”dashboard。它允许经理和财务团队快速查看当前工作量，识别停留在特定状态的报告，并确定行动优先级。分析在每个状态下停留的时间有助于精准定位流程延迟和低效环节。为何重要提供报销报告在 Workflow 中位置的实时快照，这对于运营 dashboard 和状态监控至关重要。获取方式这是 Brex 内报销报告对象上的一个关键状态字段。示例 PENDING_APPROVALAPPROVEDREJECTED已支付
	违规标记 PolicyViolationFlag	一个布尔标志，指示报销单是否因违反政策而被标记。
描述此属性是一个简单的 true/false 指示器，当 Brex 的自动政策引擎检测到潜在违规（如报销超过类别限制或缺失发票）时会进行设置。此标记是合规分析的基础，也是“政策违规率”KPI 的依据。它支持快速过滤不合规报告，以了解其对处理时间和驳回率的影响。分析这些标记的报告有助于完善公司政策，并识别员工需要更多指导的领域。为何重要直接支持合规性监控，并有助于量化政策违规对流程效率和返工的影响。获取方式这可能是 Brex 报销报告 data 中的一个布尔字段或状态指示器，通常由其政策引擎管理。示例 truefalse
	付款方式 PaymentMethod	指示费用的支付方式，例如：企业卡或个人资金。
描述此属性区分了使用公司发放的 Brex 卡支付的支出与员工自行垫付并需要报销的支出。这种区分非常重要，因为流程会根据支付方式而发生显著变化。公司卡交易可能遵循验证和对账流程，而垫付报销则遵循申请和打款流程。按支付方式分析有助于隔离每种流向特有的问题并分别进行优化。为何重要公司卡支出与垫付报销的流程流向及所需步骤通常不同，因此这是变体分析的关键属性。获取方式此信息是 Brex 内部交易 data 所固有的。示例 Brex 企业卡报销账单支付
	最后数据更新 LastDataUpdate	数据从源系统最后一次刷新的时间戳。
描述该属性指示正在分析的 data 的新鲜度。它记录了上一次从 Brex 成功提取 data 的日期和时间。了解最近一次 data 更新时间对于用户理解分析洞察的时效性至关重要。它有助于用户判断 dashboard 反映的是最新运营状态还是基于旧数据，从而合理管理对分析实时准确性的预期。为何重要告知用户 data 的及时性，这对于做出准确、最新的运营决策至关重要。获取方式此 timestamp 是在从 Brex 成功拉取 data 后，由 data 提取工具或程序生成的。示例 2023-11-20T02:00:00Z2023-11-21T02:00:00Z
	发票及时附上 ReceiptsAttachedOnTime	一个标志，指示在提交报销单之前是否已附上收据。
描述此计算得出的布尔属性旨在衡量对一项通用流程最佳实践的遵循情况：在提交报销报告审核前附上所有必要发票。如果在给定 case 中，“已附发票”活动发生在“报销报告已提交”活动之前，则设为 true。此标记直接支持“单据合规性与影响”dashboard 和“发票附件合规率”KPI。分析此属性有助于量化发票延迟或缺失发生的频率，并将此行为与延迟、驳回和返工等流程结果关联起来。为何重要衡量对收据提交政策的遵守情况，有助于识别流程延迟和拒绝的常见根源。获取方式这是在 Process Mining 工具内通过比较每个 case 中“已附发票”和“报销报告已提交”活动的 timestamp 计算得出的。示例 truefalse
	员工姓名 EmployeeName	创建并提交报销报告的员工姓名。
描述此属性指定了代表其提交报销报告的员工姓名。虽然“Event 用户”识别了谁执行了操作，但“员工姓名”识别了报销报告 case 的主体。在分析中，这支持按员工跟踪报销情况。它有助于识别经常提交违规报告或报告持续被驳回的个人，从而提示针对性培训的需求。它还有助于了解组织内不同员工或角色的支出模式。为何重要识别报销单的所有者，以便在个人员工层面分析提交质量和合规性。获取方式这是每份报销报告中的基础信息，链接自 Brex 中的创建者用户个人资料。示例爱丽丝·约翰逊Robert WilliamsMaria Garcia
	周期时间 CycleTime	从创建报销报告到最终完成所经过的总时长。
描述 Cycle Time 是一个计算指标，用于衡量每个报销单 case 的端到端持续时间。它通常计算第一个 event（例如 “Expense Report Created”）和最后一个 event（例如 “Reimbursement Executed” 或 “Accounting Posted”）的 timestamp 之间的差值。这是衡量流程整体效率最基础的 KPI 之一，直接支持“报销单端到端周期时间”仪表板。分析周期时间有助于识别耗时较长的 case，了解流程绩效趋势，并衡量流程改进计划的影响。为何重要这是一个关键绩效指标，用于衡量报销管理流程从开始到结束的整体速度和效率。获取方式这是在 Process Mining 工具内通过从每个 case 的最后一次 event timestamp 中减去最早一次 event timestamp 计算得出的。示例 3 days 4 hours10 天 1 小时22 hours 30 minutes
	国家/地区 Country	与员工或报销交易关联的国家/地区。
描述该属性指示员工主要办公室或成本中心所在的国家/地区。对于全球化公司，这是对比分析的必备维度。按国家分析流程可以突出流程绩效、合规率或支出行为的地域差异。例如，由于当地法规或不同的管理结构，某个国家的审批时间可能会更长。这种洞察对于在全球范围内标准化流程同时兼顾当地需求非常有价值。为何重要允许分析不同地理区域的流程绩效和合规性，这对于跨国组织至关重要。获取方式来源于 Brex 内部的员工档案信息，通常从中央 HR 系统同步。示例美国CANGBRDEU
	拒绝原因 RejectionReason	经理或财务用户驳回报销报告时提供的理由。
描述此属性捕获报销报告被驳回时给出的自由文本或预定义理由。这不同于自动政策标记，代表审批人的手动决策。分析驳回理由是理解流程失败和返工原因的关键。它有助于识别常见的提交错误、不清晰的政策，或员工与经理之间的误解。这些信息可用于改进培训材料和常见问题解答 (FAQ)，从而最终降低驳回率和返工率。为何重要解释人工拒绝发生的原因，提供可用于改进用户培训并减少未来错误的直接反馈。获取方式这通常是一个备注字段，审批人在 Brex UI 中执行“驳回”操作时可以填写。示例选择了错误的费用类别。请提供更详细的业务说明。此采购未经预先批准。
	是否已自动化 IsAutomated	一个布尔标志，指示该活动是由系统用户还是机器人执行的。
描述此属性标识活动是由系统自动执行（如自动化政策检查），还是由人工用户执行（如手动审批）。区分自动和手动活动对于了解流程的自动化水平至关重要。它有助于评估基于规则的系统的有效性，并识别进一步自动化的机会。例如，它可以显示有多少报告是自动批准的，有多少需要人工干预，从而指导提高“无接触处理”比例的努力。为何重要有助于衡量流程的自动化水平，并识别哪些步骤是由人工执行，哪些是由系统执行。获取方式这通常是通过检查与 event 关联的用户来派生的。系统生成的 event 通常链接到通用的“系统”或“机器人”用户。示例 truefalse
	是否返工 IsRework	一个计算出的标志，如果报告至少被退回修订过一次，则为 true。
描述此布尔属性派生自流程流向。对于其历史记录中包含“报告已发回修改”活动的任何报销报告，该值均设为 true。这提供了一种标记和分析返工 case 的简便方法。此标记用于计算“报销报告返工率”KPI，并为“政策违规与返工分析”dashboard 提供支持。它实现了流畅处理的 case 与被退回 case 之间的轻松对比，有助于量化与返工相关的的时间和成本。为何重要识别需要额外工作和更正的报销单，以便分析返工的原因和成本。获取方式该属性不在源系统中。它是通过检查一个 case 的活动序列是否包含“报告已发回修改”或类似的返工活动计算得出的。示例 truefalse
	源系统 SourceSystem	数据提取来源系统。
描述该属性标识了流程 data 的来源，在此语境下为“Brex”。这对于 data 治理和可追溯性非常重要，尤其是在可能合并多个系统 data 以获得整体流程视图的环境中。在分析中，当涉及多个源系统时，它有助于过滤和细分 data，确保根据来源正确解析指标和流程图。对于单一系统视图，它可作为对 data 来源的持续验证。为何重要提供关于 data 来源的关键上下文，确保可追溯性，并在多系统环境中实现正确的 data 过滤。获取方式这是一个静态值“Brex”，通常在 data 提取和转换阶段添加。示例 BrexBrex-API-v2.1
	结束时间 EndTime	指示活动完成时的时间戳。
描述 StartTime (EventTime) 标记活动的开始，而 EndTime 标记活动的结束。这对于具有持续时间的活动最为相关，例如“经理审核开始”和“经理已批准”。活动同时具备开始和结束时间，支持精确计算其处理时间，并将其与之前的等待时间分开。这有助于准确衡量执行工作本身所需的时间，而这正是瓶颈分析的关键组成部分。为何重要能够计算各项活动的精确处理时间（与等待时间区分开），从而实现更准确的瓶颈分析。获取方式 EndTime 通常是序列中下一个活动的 StartTime。对于具有明确持续时间的活动，它也可以是源 data 中的专用字段。示例 2023-10-26T10:05:12Z2023-10-26T14:40:00Z2023-10-27T09:15:25Z
	货币 Currency	报销报告总金额的货币代码。
描述 “货币”属性指定了总金额的单位，如 USD、EUR 或 GBP。这对于准确的财务分析至关重要，特别是对于处理多种货币跨国组织而言。该属性确保了财务 data 得到正确解析。它支持对报销金额进行适当的汇总和比较（通常需要转换为统一的报告货币），从而避免将不同货币的金额直接相加而导致的分析错误。为何重要确保多币种环境下的财务准确性，并允许对费用值进行正确的汇总和报告。获取方式此字段通常与 Brex 报销报告 data 中的金额字段并列显示。示例美元EURGBP
	费用类别 ExpenseCategory	分配给该笔报销的类别，例如差旅、餐饮或软件。
描述 “报销类别”是员工选择的分类，用于描述报销的性质。它被用于会计核算、预算编制和政策执行。在 Process Mining 中，对报销进行分类可以提供更细致的流程视角。它有助于确定某些特定类别的报销（如国际差旅）是否具有更长的审批周期或更高的驳回率。这种分析支持针对特定支出类型完善政策和流程。为何重要允许基于支出类型分析流程，从而揭示不同费用类型表现出的不同行为或瓶颈。获取方式这是报销明细项上的标准字段，如果一份报告包含多个类别，则需要汇总到报销报告级别。示例机票餐饮与娱乐软件订阅办公用品
	违规详情 PolicyViolationDetails	对所违反的具体政策的文本描述。
描述虽然“政策违规标记”指示发生了违规，但此属性提供了“原因”。它包含有关违反的具体规则详情，例如“超过 50 美元的用餐限制”或“超过 25 美元的报销需要发票”。这种详尽程度对于“政策违规与返工分析”dashboard 极具价值。它通过识别最常见的违规类型来支持根本原因分析。这些洞察可以驱动针对性行动，例如澄清特定政策、向员工发送提醒或调整自动系统规则。为何重要提供政策违规的根本原因，从而能够针对性地改进政策、加强用户培训和优化系统配置。获取方式此信息可在 Brex 中与标记报销关联的合规或审核备注部分找到。示例费用超过类别限制。缺少发票。检测到重复费用。
	首检通过 FirstPassApproval	一个标志，指示报销单是否在没有任何拒绝或修订的情况下获得批准。
描述此计算得出的布尔属性用于识别最高效的流程实例。仅当报销报告从提交到最终批准走完整个流程，且从未被驳回或退回修改时，才设为 true。这是“一次性审批通过率”KPI 的基础，该指标是衡量流程质量和效率的关键。高通过率表明员工提交的是高质量、合规的报告，且审批流程顺畅。分析未通过一次性审批的报告特征，有助于精准定位流程中的摩擦点和错误源。为何重要通过识别无阻碍流转的报告，衡量初始提交的质量和核心工作流的效率。获取方式该属性在 Process Mining 平台内通过分析每个 case 的活动序列来计算，以检查是否存在驳回或修改活动。示例 truefalse

必填推荐可选

费用管理活动

这些是需要在 event log 中捕获的关键流程步骤和里程碑，以便在报销管理中实现准确的流程发现。

7 推荐 7 可选

	活动	描述
	会计已入账	代表报销 data 成功过账到公司总账或 ERP 系统的最后一步。这标志着报销报告财务对账的完成。
为何重要此活动从财务会计角度确认流程已完成。报销支付与过账之间的延迟可能预示着系统集成或会计 Workflow 存在问题。获取方式这可能是通过 API 确认或与会计系统成功同步后的状态更新捕获的。event timestamp 反映了过账时间。捕获在集成 ERP 或会计软件成功回传 API 或更新状态时记录。事件类型 explicit
	报告已发回修改	审批人（经理或财务）将报告退回给员工进行更正。这与直接拒绝不同，它会启动一个返工循环。
为何重要此活动是返工的主要指标。跟踪其频率对于“报销报告返工率”KPI 和“政策违规与返工分析”dashboard 必不可少。获取方式这可能是根据状态更改为“需要修改”或“已退回”推断出来的。系统应捕获此状态更新的 timestamp。捕获根据状态变更为“需要修订”等推断，通常附带注释。事件类型 inferred
	报销单已创建	此活动标志着员工开始发起报销报告。当生成新的报销报告记录（无论是草稿还是已添加初始报销项）时，系统会捕获此 event。
为何重要这是流程的主要开始 event。分析从此时点到提交的时间有助于了解员工行为以及在报销报告提交过程中可能存在的延迟。获取方式此 event 可能捕获自 Brex 数据库中报销报告对象或记录的创建 timestamp。它应对应于与报销报告 ID 关联的最早 timestamp。捕获由报销单主记录的创建日期识别。事件类型 explicit
	报销单已提交	当员工正式提交已完成的报销报告以供审批时，会发生此活动。这是一个关键的用户驱动操作，使报告状态从“草稿”或“待定”转变为“等待审批”。
为何重要这是一个重大里程碑，标志着审批 workflow 正式开始。提交与最终批准之间的时间是总周期时间的关键组成部分。获取方式这通常是审计日志中记录的显式 event，也可以根据状态更改为“已提交”或“等待经理审批”及相应的 timestamp 来推断。捕获从事件日志或报销单记录上的“submission_timestamp”字段中捕获。事件类型 explicit
	报销已执行	此活动标志着款项实际支付给员工的时刻。从员工的角度来看，这是最后一步，也是流程的成功终点。
为何重要这是流程的主要成功终点。它是计算“平均端到端周期时间”和“报销执行滞后”KPI 的必需项，直接影响员工满意度。获取方式此 event 应从支付交易日志或来自银行/支付处理器的 API 确认中捕获。它对应于实际的支付执行日期。捕获从包含执行 timestamp 的支付交易日志中捕获。事件类型 explicit
	经理已审批	一级经理已审核报销报告并批准进入下一步处理。这是一个关键决策点，将报告推向下一阶段，通常是财务审核或自动批准。
为何重要此里程碑标志着初始审批步骤的完成。它对于跟踪审批周期、经理工作量以及“一次性审批通过率”至关重要。获取方式此 event 可能在审批历史表或审计追踪中显式记录，包含审批人的 ID 和 timestamp。捕获从带有相关 timestamp 的事件日志或状态变更为“经理已批准”中捕获。事件类型 explicit
	财务已批准	财务部门已完成审核并给予报销报告最终批准。这是处理报销款项前的最后一个审批关口。
为何重要这是一个授权支付的关键里程碑。它是衡量完整审批周期的终点，也是衡量“报销执行滞后”KPI 的起点。获取方式此 event 应在审批历史或审计追踪中显式记录，包含最终审批人的 ID 和 timestamp。捕获从事件日志或状态变更为“财务已批准”或“已批准支付”中捕获。事件类型 explicit
	已安排报销	最终批准后，报销单将进入下一次报销批次的付款队列。该活动代表了从审批系统到支付系统的移交。
为何重要此步骤可以揭示最终批准与实际支付处理之间的延迟。它有助于区分审批瓶颈与支付系统的低效问题。获取方式这可以根据状态更改为“待支付”或“已安排”来推断。如果系统与独立的支付或 ERP 系统对接，它也可以是一个显式 event。捕获根据状态变更为“等待支付”或支付批次记录的创建推断。事件类型 inferred
	已标记违规	一个自动或手动的 event，指示报告中的一个或多个费用项目违反了公司政策。这可以在触发系统规则或审核人员手动标记问题时捕获。
为何重要此活动对于“政策违规与返工分析”dashboard 以及“政策违规率”KPI 至关重要。它有助于识别常见的合规问题和需要澄清的政策领域。获取方式源自设置为 true 的“Policy Violation Flag”属性。timestamp 为该标志状态最后更新的时间。捕获根据指示政策违规的布尔标志或状态字段的变化推断。事件类型 inferred
	已附发票	代表用户向报销明细项 upload 或附加发票图像/文件的操作。这通常被捕获为一个带有每个附件 timestamp 的显式 event。
为何重要跟踪此活动对于“单据合规性与影响”dashboard 至关重要。它有助于确定延迟或驳回是否与发票提交缺失或延迟相关。获取方式这可能记录在将附件与报销明细项关联的相关表中。每个附件记录应具有自己的创建 timestamp。捕获在用户成功上传与费用明细相关的项时记录。事件类型 explicit
	经理审核开始	此活动标志着报销报告进入经理审批队列的时间点。通常通过提交后报告状态立即变为“等待经理审批”来推断。
为何重要这标志着第一审批阶段的开始。衡量从此时点到“经理已批准”或“经理已驳回”的时长，是“平均经理审核时间”KPI 的关键。获取方式这是根据报销报告状态转变为“等待经理审批”或类似状态时的 timestamp 推断出来的。它通常与“报销报告已提交”event 同时发生。捕获根据状态变更为“等待经理审批”的 timestamp 推断。事件类型 inferred
	经理已拒绝	一级经理审核了报销报告并予以驳回。此操作通常会终止流程或将报告退回给员工进行更正。
为何重要此活动代表负面结果和流程异常。它对于计算“报销报告驳回率”以及识别一级审批失败的原因至关重要。获取方式这应显式记录在审批历史表或审计追踪中（类似于批准操作），并带有 timestamp 和原因代码。捕获从带有相关 timestamp 的事件日志或状态变更为“经理已拒绝”中捕获。事件类型 explicit
	财务审核开始	标记报销单进入财务或会计部门队列进行最终审核的时间。通常根据经理批准后的状态变化推断。
为何重要这标志着最后一个（通常也是最关键的）审批阶段的开始。分析其持续时间有助于识别财务部门中的瓶颈。获取方式这是根据经理批准后，报告状态更改为“等待财务审批”或类似状态时的 timestamp 推断出来的。捕获根据状态变更为“等待财务审核”的 timestamp 推断。事件类型 inferred
	财务已拒绝	财务部门驳回了报销报告，通常是由于政策、合规或材料问题。这是一次最终驳回，流程随之终止。
为何重要这是一个关键的异常 event。分析其频率和原因是理解合规失效以及计算整体“报销报告驳回率”的关键。获取方式与其他审批决策一样，这应显式记录在审计线索中，并包含审批人 ID、timestamp 和原因。捕获从事件日志或状态变更为“财务已拒绝”中捕获。事件类型 explicit

推荐可选

提取指南

如何从 Brex 获取您的数据

步骤

登录 Brex： 使用具有管理员 (Administrator) 或账簿管理员 (Bookkeeper) 权限的账号访问 Brex 仪表板，因为这些角色才有权限查看和导出公司范围的费用 data。
导航至 Expenses： 从左侧导航菜单中选择“Expenses”部分，进入费用管理仪表板。
访问公司费用： 在 Expenses 部分中，导航至显示所有公司费用的视图。这可能被标记为“Company expenses”或类似名称。
应用筛选： 配置筛选器以获取所需的数据集。设置特定的日期范围（例如过去 6 个月），以获得相关的流程视图。确保包含所有费用状态（如：草稿、待处理、已批准、已拒绝、已支付），以捕获每份报销单的完整生命周期。
开始导出： 找到并点击“Export”按钮。这将打开一个对话框或包含导出配置选项的新页面。
配置导出设置： 选择“CSV”作为导出格式。在列选择选项中，确保包含所有与 ID、金额、用户、部门、状态相关的可用字段，尤其是所有可用的 timestamp（如：创建、提交、批准、支付、导出日期）。捕获所有 timestamp 对于构建事件日志至关重要。
下载 CSV 文件： 确认选择并下载生成的 CSV 文件到本地。该文件包含原始交易 data。
了解数据格式： 导出的文件是一个基于状态的日志，每行代表一笔费用或报销单，并包含多个日期列。为了使其适用于 Process Mining，您必须将其转换为事件日志，其中每行代表一个单一活动。
转换 data： 在 Microsoft Excel、Google Sheets 等电子表格程序中打开 CSV，或使用 Python 等脚本语言。对于原始导出文件中的每一行，您必须在最终事件日志中创建多个新行，每一行对应一个相关的活动 timestamp。例如，包含提交、经理批准和支付 timestamp 的单行报销单记录，在新文件中将变为三个独立的行。
将列映射到事件日志模式： 在转换 data 时，将 Brex 导出文件的列映射到所需的事件日志结构。Expense ID 变为 ExpenseReportId，每个 timestamp 列变为其对应活动的 EventTime，活动名称（如：“Expense Report Submitted”）设置为 ActivityName。
保存最终事件日志： 转换完成后，如果您已经拥有一个包含 ExpenseReportId、ActivityName 和 EventTime 列的“长格式”表格，请将该文件保存为新的 CSV。现在，该文件的格式已正确，可以上传到 Process Mining 工具中。

配置

用户权限： 需要 Brex 中的管理员 (Administrator) 或账簿管理员 (Bookkeeper) 角色，才能访问并导出所有员工的费用 data。
日期范围： 建议导出 3 到 6 个月的 data 以进行有意义的分析。导出超过一年的 data 可能会很慢，且文件体积巨大。
状态筛选： 为捕获从开始到结束的完整流程，请确保状态筛选器设置为包含所有状态，例如草稿 (Draft)、待审批 (Pending Approval)、已批准 (Approved)、已拒绝 (Rejected) 和已支付 (Paid)。
导出列： 导出时请选择所有可用列。这对于捕获 EmployeeDepartment 和 TotalAmount 等属性至关重要，特别是为了获取准确重建流程时间线所需的所有 timestamp。

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 Token：登录您的 Brex 仪表板。导航至“Developer”部分并生成一个新的 User Token。创建 Token 时，您必须授予其以下权限范围以访问必要 data：team:read、transactions:read 和 expenses:read。安全地复制生成的 Token。
设置 Python 脚本：创建一个名为 extract_brex_expenses.py 的新文件。将“Query”部分提供的完整 Python 脚本复制到此文件中。
配置脚本参数：打开 extract_brex_expenses.py 文件并更新顶部的占位符变量。将 API_TOKEN 变量设置为您在第 2 步中生成的 Token。调整 START_DATE 和 END_DATE 变量（格式为 'YYYY-MM-DD'）以定义提取周期。
执行脚本：在终端中使用以下命令运行脚本：python extract_brex_expenses.py。脚本将连接到 Brex API，获取指定日期范围内的费用 data，并自动处理分页。
数据处理与转换：脚本处理来自 API 的原始 JSON data。它会迭代每个报销单及其状态历史记录，为从创建到会计同步的 14 个所需流程活动分别生成独立的行。
生成事件日志：脚本运行结束后，将在同一目录下创建一个名为 brex_expense_event_log.csv 的 CSV 文件。该文件即为事件日志，结构为每行一个活动。
准备上传：生成的 CSV 文件格式符合 ProcessMind 要求。无需进一步的 data 转换。您现在可以将此文件直接上传到您的 ProcessMind 项目中。

配置

API Token：需要 Brex Developer 仪表板提供的 User Token。该 Token 必须启用 team:read、transactions:read 和 expenses:read 权限范围。
日期范围：脚本包含 START_DATE 和 END_DATE 变量。建议提取 3 到 6 个月的 data 进行初步分析，以确保数据具有代表性，且不会产生过大负载。
分页限制：脚本硬编码为每次 API 调用请求最多 100 笔费用（limit=100），并自动利用 API 提供的 next_cursor 处理分页，从而检索指定日期范围内的所有记录。
性能考量：对于超过一年的 data 提取，受 API 速率限制和处理数据量的影响，脚本可能需要运行几分钟。建议在非高峰时段进行大规模数据提取。
数据粒度：脚本根据费用对象及其状态历史记录提取 event。它假定流程为标准工作流。自定义审批流可能需要调整脚本的处理逻辑。

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 Team REST API 的 Python 脚本

步骤

配置

a 查询示例 python

准备好开始了吗？

立即优化您的 Brex 报销管理

您的费用管理数据模板

您的费用管理数据模板

费用管理属性

费用管理活动

提取指南

Brex 仪表板 CSV 交易导出

步骤

配置

a 查询示例 config

使用 Brex Team REST API 的 Python 脚本

步骤

配置

a 查询示例 python

我们重视您的隐私

准备好开始了吗？

立即优化您的 Brex 报销管理