您的费用管理数据模板
您的费用管理数据模板
- 全面分析所需采集的推荐属性
- 准确发现流程所需跟踪的关键活动
- 数据提取实用指南
费用管理属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件时间
EventTime
|
表示费用报告中特定活动或事件发生时间的时间戳。 | ||
|
说明
Event Time提供流程中每项活动的准确日期和时间。此时间信息对于计算周期时间、持续时间以及不同步骤之间的等待时间至关重要。它支持分析瓶颈、随时间变化的绩效趋势,以及服务级别协议的一致性。没有准确的时间戳,流程挖掘分析将只能停留在流程顺序发现层面。
为什么重要
时间戳是所有基于时间的分析的基础,包括计算周期时间、识别瓶颈和监控流程绩效。
获取位置
这是Expensify报告数据中每条历史日志记录或状态变化对应的创建时间戳。
示例
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:12:05Z
|
|||
|
活动名称
ActivityName
|
费用报告在特定时间点发生的业务事件名称。 | ||
|
说明
活动名称描述费用管理流程中的具体步骤或里程碑,例如“费用报告已提交”或“经理已批准”。它构成流程图的基础,帮助分析人员可视化工作流、识别常见路径并发现偏差或瓶颈。分析活动序列是理解流程效率和合规性的基础。
为什么重要
此属性定义流程图中的步骤,从而可以可视化和分析流程顺序、变体及返工循环。
获取位置
该属性通常通过将Expensify中的报告状态变化、评论或历史日志条目映射到标准化活动列表来生成。
示例
提交费用报告经理已批准财务已拒绝已完成报销
|
|||
|
费用报告ID
ExpenseReportId
|
费用报告的唯一标识符,用于汇总从提交到报销的所有相关活动。 | ||
|
说明
费用报告ID是费用管理流程的主要案例标识符。每个ID代表员工提交审批和报销的一组费用。该属性对于跟踪费用报告的端到端历程至关重要,可重建其完整生命周期,包括所有提交、审批、拒绝和付款。
为什么重要
它可以将所有相关事件汇总到单个流程实例中,这是任何流程挖掘分析的基础。
获取位置
这是费用报告数据对象中的主键,通常可通过Expensify API的reports端点以“reportID”获取。
示例
RPT_84321RPT_99012RPT_10573
|
|||
|
员工部门
EmployeeDepartment
|
提交人所属的业务部门或组织单元。 | ||
|
说明
该属性表示提交费用报告的员工所属组织部门,例如“Sales”“Engineering”或“Marketing”。它是重要的分析维度,可用于比较不同业务部门的周期时间、拒绝率和政策合规性,帮助识别部门特有的问题或培训需求。
为什么重要
支持深入分析,比较不同业务单元的流程绩效和合规性。
获取位置
该信息可能以报告标签形式存储,或关联于Expensify中的提交人用户档案,可能需要从外部HR系统补充。
示例
销售市场营销工程财务
|
|||
|
审批人
Approver
|
负责批准或拒绝费用报告的用户姓名或ID。 | ||
|
说明
审批人属性标识对已提交费用报告采取操作的经理或财务团队成员。这对于分析审批人行为至关重要,例如审批耗时、拒绝率和工作量分布。了解审批人绩效有助于识别培训需求、重新分配工作量并简化审批流程。
为什么重要
该属性是分析审批瓶颈、工作量分布和特定审批人拒绝率的关键。
获取位置
该信息位于报告历史记录或工作流日志中,通常与审批或拒绝事件相关联。字段可能命名为“managerEmail”或类似名称。
示例
jane.doe@example.comjohn.smith@example.comfinance.approver@example.com
|
|||
|
报告总金额
ReportTotalAmount
|
费用报告的货币总金额。 | ||
|
说明
该属性表示单个费用报告中所有费用的总和,是一项重要的财务指标,可用于识别可能需要额外审查或适用不同审批路径的高金额费用,也用于财务报告和了解组织支出模式。
为什么重要
支持高金额费用报告分析,帮助识别支出趋势,也是财务和合规仪表板的重要数据。
获取位置
可在Expensify的reports对象中获取,通常命名为“total”或“amount”。
示例
150.752500.0089.50
|
|||
|
提交人
Submitter
|
创建并提交费用报告的员工。 | ||
|
说明
提交人属性标识产生费用并申请报销的员工。该信息可用于按员工、部门或角色分析费用模式,帮助回答哪些员工或群体经历的延迟最多、政策违规率最高,从而支持更好的员工体验分析。
为什么重要
支持从员工视角分析流程绩效,帮助识别经常遇到问题或延迟的群体。
获取位置
这是费用报告对象中的主要字段,通常命名为“policyEmail”“submitterEmail”或“employeeEmail”。
示例
sara.jones@example.comkevin.lee@example.commaria.garcia@example.com
|
|||
|
政策违规标记
PolicyViolationFlag
|
布尔指标;如果报告被标记为政策违规,则值为true。 | ||
|
说明
该标记表示费用报告是否触发了一项或多项政策违规,例如超出支出限额或缺少收据。Expensify的自动化系统通常会标记这些问题。该属性是“政策违规概览”仪表板的重要数据,有助于量化合规问题并确定改进重点。
为什么重要
直接衡量政策合规性,帮助识别需要额外审查的报告,是合规仪表板的关键输入。
获取位置
Expensify报告通常包含表示违规的特定字段或状态,例如“hasViolations”或类似的布尔标记。
示例
truefalse
|
|||
|
事件结束时间
EventEndTime
|
特定活动结束时的时间戳,适用于具有可衡量持续时间的活动。 | ||
|
说明
费用管理中的许多活动是瞬时完成的,但“经理审核”等活动可以用开始时间和结束时间建模。事件结束时间标志着此类活动的完成,并与开始时间结合使用,以计算单个步骤的准确处理时间,更细致地了解时间消耗所在。
为什么重要
支持计算活动处理时间,帮助区分实际工作时间和空闲等待时间。
获取位置
通常不是直接字段,而是根据同一案例中序列下一事件的时间戳推导。
示例
2023-10-26T10:05:12Z2023-10-27T15:00:00Z
|
|||
|
付款方式
PaymentMethod
|
用于向员工报销的方式。 | ||
|
说明
该属性描述员工获得报销的方式,例如“Direct Deposit (ACH)”“PayPal”或“Company Credit Card”。分析付款方式有助于了解报销环节,尤其是在某些方式可能导致更长延迟的情况下,也为流程最后步骤提供额外背景。
为什么重要
为报销阶段提供背景,可用于分析不同付款方式相关的延迟或成本。
获取位置
该信息通常可在已关闭报告的报销详情中获取。
示例
ACHPayPalBill.com
|
|||
|
最近数据更新时间
LastDataUpdate
|
表示该记录数据最近一次从源系统刷新时间的时间戳。 | ||
|
说明
该属性记录数据最近一次提取并更新至流程挖掘工具的日期和时间,体现数据的新鲜度,对了解分析结果的时效性至关重要。这有助于用户信任分析洞察,并基于及时数据做出明智决策。
为什么重要
确保用户了解数据的新鲜度,这对流程分析的相关性和准确性至关重要。
获取位置
通常为数据提取作业的时间戳,在数据转换(ETL)过程中添加。
示例
2023-11-20T08:00:00Z2023-11-21T08:00:00Z
|
|||
|
审计结果
AuditOutcome
|
对费用报告执行人工或自动审计后的结果。 | ||
|
说明
该属性记录审计结果,可能为“Passed”“Failed”或“Passed with Findings”。对于在费用流程中设置正式审计步骤的公司,无论是审计全部报告还是抽样审计,该属性都很有价值。分析审计结果有助于了解合规水平和现有控制措施的有效性。
为什么重要
直接衡量一致性检查的结果,对于分析审计流程的有效性至关重要。
获取位置
这可能是概念性属性,也可能以标签或评论形式存储。是否存在取决于公司在Expensify中的具体流程配置。
示例
通过未通过,违反政策通过,但有备注
|
|||
|
币种
Currency
|
费用报告金额所使用的币种代码。 | ||
|
说明
币种属性指定报告总金额所使用的币种,例如USD、EUR或GBP。对于在多个国家运营的组织,这对确保正确解读财务数据至关重要。所有货币金额都应结合该属性进行分析,以避免错误汇总。
为什么重要
为所有货币金额提供必要背景,确保财务分析和报告的准确性。
获取位置
这是Expensify报告对象中的标准字段,通常称为“currency”。
示例
USDEURGBPCAD
|
|||
|
总周期时间
TotalCycleTime
|
从费用报告第一个事件创建到最后一个事件完成所经过的总时间。 | ||
|
说明
总周期时间是在案例层级计算的指标,用于衡量单份报告费用管理流程的端到端时长,是评估整体流程效率的关键绩效指标(KPI)。该指标通过计算第一个活动(如“费用报告已创建”)与最后一个活动(如“已完成报销”)时间戳之差得出。
为什么重要
这是衡量整体流程速度和识别长周期案例的主要KPI,长周期案例可能表明存在系统性问题。
获取位置
该属性按每个ExpenseReportId计算,公式为(MAX(EventTime)-MIN(EventTime))。
示例
6048001209600259200
|
|||
|
报告状态
ReportStatus
|
费用报告在其生命周期中的当前状态。 | ||
|
说明
报告状态表示费用报告在流程中的当前位置,例如“OPEN”“SUBMITTED”“APPROVED”“REIMBURSED”或“CLOSED”,提供报告进度的快照。在流程挖掘中,该属性通常用于生成活动名称,也可以作为维度,分析报告在每种状态下停留的时间。
为什么重要
表示案例的当前状态,通常用于生成流程挖掘所需的活动日志。
获取位置
这是Expensify报告对象中的标准字段,通常命名为“status”或“state”。
示例
已提交已批准已报销已关闭
|
|||
|
拒绝原因
RejectionReason
|
审批人拒绝费用报告或将其退回修改时提供的原因。 | ||
|
说明
费用报告被拒绝时,审批人通常可以提供原因。该文本属性记录这一原因,为了解报告未通过审批的原因提供重要的定性洞察。分析拒绝原因有助于识别常见提交错误、政策不清晰之处或员工需要加强培训的领域,直接支持提高一次审批通过率。
为什么重要
提供解释返工原因的定性数据,对分析报告拒绝的根本原因至关重要。
获取位置
该信息通常位于与拒绝事件相关的评论或历史日志中。
示例
金额超过75美元的费用缺少收据选择了错误的费用类别提交了重复费用
|
|||
|
政策名称
PolicyName
|
应用于报告的费用政策名称。 | ||
|
说明
在Expensify中,不同员工群体可能适用不同的费用政策。该属性标识管理费用报告的具体政策,是重要的分析维度,可用于比较不同政策下的合规性和效率,因为不同政策可能包含不同规则和审批工作流。
为什么重要
支持按所应用的规则集细分流程分析,对于理解不同政策导致的流程差异至关重要。
获取位置
这是Expensify报告对象中的标准字段,通常命名为“policyID”或“policyName”。
示例
美国员工政策英国销售团队政策高管差旅政策
|
|||
|
是否一次审批通过
IsFirstPassApproval
|
计算得出的标记;如果报告未经拒绝或退回修改即获批准,则值为true。 | ||
|
说明
该布尔标记按每份费用报告计算,用于判断报告是否在没有被拒绝或退回修改等负面结果的情况下完成审批流程。它直接衡量流程质量和效率,并直接用于计算“一次审批通过率”KPI。较高的通过率表明提交质量较高且员工充分理解政策。
为什么重要
直接衡量初始提交质量和审批流程效率,突出返工发生的频率。
获取位置
通过检查指定ExpenseReportId的活动序列计算。如果序列不包含“Manager Rejected”“Finance Rejected”或“Report Sent Back For Revision”,则该标记为true。
示例
truefalse
|
|||
|
源系统
SourceSystem
|
提取数据的系统。 | ||
|
说明
该属性标识流程数据的来源,本例中为“Expensify”。在合并多个系统的数据时,它对数据治理尤为重要,有助于追踪数据血缘并理解流程背景。
为什么重要
为数据血缘提供重要背景,并帮助区分加载到同一环境中的多个源系统流程。
获取位置
这是一个静态值(“Expensify”),应在数据转换过程中添加。
示例
ExpensifyExpensifyAPI-v2.0
|
|||
|
费用类别
ExpenseCategory
|
报告中单项费用明细所属的类别。 | ||
|
说明
费用类别用于划分支出类型,例如“Travel”“Meals & Entertainment”或“Software”。一份报告可能包含多个类别,但该属性通常会被反规范化到报告层级,例如取出现频率最高或金额最高的类别。它用于分析支出趋势,并检查特定费用类型的政策合规性。
为什么重要
有助于分析支出模式、政策违规情况以及不同费用类型的审批耗时。
获取位置
位于报告内的明细项层级(“transactions”)。需要通过聚合或业务规则将其分配到案例层级。
示例
机票住宿餐饮办公用品
|
|||
费用管理活动
| 活动 | 说明 | ||
|---|---|---|---|
|
创建费用报告
|
表示员工发起新的费用报告。通常在报告首次保存到Expensify时,以带有创建时间戳的明确事件记录。 | ||
|
为什么重要
该活动是所有流程分析的起点,对于衡量从创建到报销的总周期时间至关重要。
获取位置
该事件取自Expensify报告历史或审计日志中的报告创建时间戳。每个报告对象都有创建日期。
采集
费用报告首次创建并保存时记录。
事件类型
explicit
|
|||
|
已完成报销
|
款项已成功支付给员工,报销流程随之完成。该事件从付款处理日志或Expensify中的最终状态更新中获取。 | ||
|
为什么重要
这是衡量面向员工的周期时间的关键终点,对“平均费用报告周期时间”和“平均报销周期时间”KPI至关重要。
获取位置
根据报告状态变为“Reimbursed”推断。Expensify与支付系统的集成会为该状态变化提供时间戳。
采集
根据报告状态变为“Reimbursed”及其相应时间戳推导。
事件类型
inferred
|
|||
|
报告已关闭
|
包括报销和会计同步在内的所有操作完成后,费用报告会在系统中正式关闭。该事件通常根据最终终止状态(如“Closed”)推断。 | ||
|
为什么重要
为流程提供明确的终点,与报销完成相区分,便于分析最终记账和归档步骤。
获取位置
根据报告状态变为“Closed”等终止状态推断。该变化通常发生在报销和会计数据导出之后。
采集
根据报告状态变为“Closed”及其相应时间戳推导。
事件类型
inferred
|
|||
|
报告退回修改
|
审批人可能是经理或财务人员,会将报告退回员工,要求其更正或补充信息。通常可根据报告从“Processing”变为“Open”的状态变化推断该事件。 | ||
|
为什么重要
该活动代表返工,是流程低效的主要来源之一。跟踪该活动有助于量化返工循环、衡量“返工率”KPI并识别根本原因。
获取位置
根据报告状态从“Processing”或“Submitted”变回“Open”推断。该状态变化的时间戳即为事件时间。
采集
根据报告状态从“Processing”变回“Open”推导。
事件类型
inferred
|
|||
|
提交费用报告
|
员工正式提交已完成的费用报告,启动审批工作流。这是从数据录入转入审核流程的关键节点,通常通过状态变更和提交时间戳记录。 | ||
|
为什么重要
该活动是触发审批周期的关键里程碑,也是衡量经理和财务审核时间的起点。
获取位置
根据报告状态从“Open”或“Draft”变更为“Processing”或“Submitted”推断,并结合该变更对应的时间戳。
采集
根据状态变更为“Processing”及对应的提交时间戳得出。
事件类型
inferred
|
|||
|
经理已批准
|
直属经理或一级审批人已审核并批准费用报告。该事件记录于审批工作流日志中,其中包含审批人的操作和时间戳。 | ||
|
为什么重要
审批流程中的关键里程碑。分析从提交到该事件的耗时,有助于识别与经理审批相关的瓶颈,并衡量“经理审批周期时间”KPI。
获取位置
从报告历史记录或审计轨迹中获取,其中明确记录了审批操作、审批人姓名和时间戳。
采集
作为独立的审批操作记录在报告工作流历史中。
事件类型
explicit
|
|||
|
财务已批准
|
财务部门或最终审批人已审核并最终批准费用报告。该操作记录在工作流历史中,报告状态通常会变为“Approved”。 | ||
|
为什么重要
这是报销前的最终审批关卡。该步骤的耗时对整体周期时间和“平均报销周期时间”KPI至关重要。
获取位置
从报告历史记录或审计轨迹中获取,其中记录了最终审批操作、财务团队审批人和时间戳。
采集
作为独立的最终审批操作记录在报告工作流历史中。
事件类型
explicit
|
|||
|
将费用添加到报告
|
表示员工向报告中添加具体明细项,例如扫描的收据或手动录入的费用。该事件会作为报告详细历史记录中的一条记录保存。 | ||
|
为什么重要
分析报告创建与添加费用之间的时间,可以发现员工收集凭证或准备提交材料时的延迟。
获取位置
取自费用报告的审计轨迹或历史记录,其中会记录添加单笔费用等操作。
采集
每次添加新的费用明细时,都会记录在报告历史中。
事件类型
explicit
|
|||
|
已安排报销
|
最终批准后,费用报告进入付款处理队列。该事件标志着流程从审批阶段转入付款阶段,通常可在报告状态变为“Reimbursing”时获取。 | ||
|
为什么重要
标志着报销周期时间的开始。分析该事件与实际付款之间的时长,有助于识别付款流程中的延迟。
获取位置
根据报告状态变为“Reimbursing”或“Processing Payment”推断,并使用相应的时间戳。
采集
根据表明报告已进入付款队列的状态变化推导。
事件类型
inferred
|
|||
|
已记账
|
费用报告中的财务数据已导出并记入公司的会计系统或ERP。这是流程的最后一步,标志着从财务记录角度看流程已完成。 | ||
|
为什么重要
代表费用报告在财务系统中的最终结案。该事件有助于衡量完整的端到端流程并确保数据同步。
获取位置
从Expensify与会计软件之间的集成日志中获取,可能需要合并两个系统的数据。
采集
数据成功同步至会计系统后,记录在集成历史中。
事件类型
explicit
|
|||
|
标记政策违规
|
自动检查发现某项费用违反公司政策,例如超出预算或缺少收据。当报告或明细项设置具体政策违规标记时,记录该事件。 | ||
|
为什么重要
突出显示合规问题,帮助识别最常被违反的政策,从而开展有针对性的培训或政策说明。这对Policy Violation Count KPI至关重要。
获取位置
根据费用报告数据中“Policy Violation”标记或属性被设置为true推断。时间戳对应于该标记被设置的时间。
采集
根据报告政策违规属性更新时的时间戳得出。
事件类型
inferred
|
|||
|
经理已拒绝
|
一级审批人已审核费用报告并予以拒绝,流程通常会因此停止。该事件会作为拒绝事件记录在工作流日志中,通常还会附带拒绝原因。 | ||
|
为什么重要
分析拒绝事件是了解“费用报告拒绝率”KPI的关键。这有助于识别常见失败原因和需要改进的流程环节。
获取位置
从报告历史记录中获取,其中记录了拒绝操作、拒绝人身份和时间戳。报告状态通常会变为“Rejected”。
采集
作为独立的拒绝操作记录在报告工作流历史中。
事件类型
explicit
|
|||
|
财务已拒绝
|
财务部门已审核并拒绝费用报告,报销流程因此停止。该事件记录在工作流历史中,并包含时间戳和拒绝原因。 | ||
|
为什么重要
用于识别最终审核阶段的瓶颈和失败原因,对分析整体拒绝率及合规问题至关重要。
获取位置
从报告历史记录中获取,其中记录了财务团队执行的拒绝操作,以及时间戳和用户信息。
采集
作为独立的拒绝操作记录在报告工作流历史中。
事件类型
explicit
|
|||
提取指南
优化费用管理:立即开始免费试用
简化Expensify费用流程,将周期时间缩短30%,提升满意度。
无需信用卡,立即开始优化。