您的费用管理数据模板
您的费用管理数据模板
- 建议收集的属性
- 需要跟踪的关键活动
- Ramp数据提取指南
费用管理属性
| 名称 | 说明 | ||
|---|---|---|---|
|
事件时间戳
EventTimestamp
|
活动发生的准确日期和时间。 | ||
|
说明
流程中的每项活动都有对应时间戳,用于记录其发生时间。这些时间数据用于按时间顺序排列事件,也是所有时间相关分析的基础。 在流程挖掘中,时间戳用于计算活动之间的周期时间、衡量案例总时长和识别延迟。这些信息对于绩效监控和发现流程改进机会至关重要。
为什么重要
该属性提供事件的时间顺序,是所有时长计算和绩效分析不可或缺的依据。
获取位置
通常可在Ramp的事件日志或交易数据中,与活动记录或状态记录一同找到。
示例
2023-10-26T10:00:00Z2023-10-26T14:30:00Z2023-10-27T09:00:00Z
|
|||
|
活动名称
ActivityName
|
费用管理流程中某个时间点发生的具体事件或任务的名称。 | ||
|
说明
此属性描述费用报告生命周期中的单个步骤,例如'Expense Submitted'、'Manager Approved'或'Reimbursement Executed'。这些活动构成流程图中的节点,可用于可视化和分析流程顺序。 分析活动有助于识别最常发生的步骤、瓶颈出现的位置,以及不同工作流之间的差异。它是理解操作顺序并衡量各阶段绩效的核心组成部分。
为什么重要
它定义流程图中的步骤,使您能够可视化和分析从开始到结束的流程顺序。
获取位置
通常从Ramp中与每份费用报告关联的事件日志或状态变更记录中提取。
示例
已提交费用经理已批准待财务审核已执行报销
|
|||
|
费用报告ID
ExpenseReportId
|
每份费用报告的唯一标识,是该流程的主要案例标识。 | ||
|
说明
Expense Report ID会将单次费用提交相关的所有事件和活动归为一组,从费用最初录入到最终付款,完整、按时间顺序跟踪费用申报过程。 在流程挖掘中,该属性对于重建每份费用报告的端到端历程至关重要。将其用作案例ID后,分析可以准确计算周期时间、识别瓶颈,并可视化报告在审批流程中经过的不同路径。
为什么重要
这是将所有相关活动关联到单个流程实例的基础属性,使端到端分析成为可能。
获取位置
该标识应位于Ramp中的主费用报告表或交易表内。
示例
ER-2023-08-1123ER-2023-09-4591ER-2023-10-0024
|
|||
|
修订原因
RevisionReason
|
费用报告退回员工修改时提供的原因。 | ||
|
说明
审批人拒绝或退回费用报告时,通常需要提供原因。此属性记录具体原因,例如“缺少收据”“类别错误”或“不符合政策”。 这些信息对“费用修订率及原因”仪表板非常有价值。通过分析最常见的返工原因,组织可以发现提交流程中的系统性问题,并实施针对性的培训或系统改进,减少错误。
为什么重要
它直接揭示返工的根本原因,支持采取针对性措施,提高首次提交质量。
获取位置
当Ramp中发生“费用退回修改”活动时,这些数据会记录在评论或拒绝详情中。
示例
缺少分项收据费用超过政策限额选择了错误的费用类别重复交易
|
|||
|
员工部门
EmployeeDepartment
|
提交费用报告的员工所属部门。 | ||
|
说明
该属性表示提交费用的员工所属业务单元或部门,例如“Sales”“Engineering”或“Marketing”。 这是分析中的关键维度,可用于筛选和比较组织不同部门的流程绩效。它能够揭示各部门在审批时间、退回修改率和政策合规性方面的差异,为有针对性的改进提供支持。
为什么重要
它支持跨不同业务单元比较流程指标,突出效率、合规性和支出方面的差异。
获取位置
该信息可能关联于Ramp中的员工用户档案,或集成的人力资源系统。
示例
销售市场营销工程财务
|
|||
|
报告总金额
ReportTotalAmount
|
费用报告的货币总金额。 | ||
|
说明
此属性表示单份报告中所有费用的总和,是了解支出模式的重要财务指标。 在流程分析中,报告金额可用于划分案例,并调查高价值报告是否采用不同的审批路径,或需要更长处理时间。它是支出分析仪表板和发现节省成本机会的基础。
为什么重要
它为分析提供关键的财务维度,支持按金额划分报告并跟踪总体支出。
获取位置
这是Ramp费用报告对象中的主要字段。
示例
150.752500.0089.99
|
|||
|
政策违规标记
PolicyViolationFlag
|
用于表示费用报告是否因违反政策而被标记。 | ||
|
说明
如果系统的自动检查发现可能违反公司费用政策的情况,例如超出支出限额或提交重复费用,此布尔属性将设为true。 此标记对“政策违规检测”仪表板及相关KPI至关重要。它有助于衡量政策控制的有效性,发现常见的不合规领域,为政策更新或员工培训提供依据。
为什么重要
它直接衡量政策合规情况,帮助发现并减少不合规支出及相关风险。
获取位置
这可能是Ramp中的系统生成标记,由提交或审批过程中的自动政策检查触发。
示例
truefalse
|
|||
|
用户名
UserName
|
执行活动的用户姓名或ID,包括提交费用的员工或审批人。 | ||
|
说明
该属性标识流程中某个事件的负责人,例如提交、批准或审核费用报告的人员。它可以是员工姓名或唯一用户ID。 按用户分析有助于了解工作量分配、识别高绩效人员,并定位可能需要额外培训的人员。它也是审批绩效和资源管理相关仪表板的关键属性。
为什么重要
它将流程活动归属到具体人员,从而支持资源层面的绩效分析并识别培训需求。
获取位置
用户信息通常记录在Ramp中每份费用报告的审计轨迹或交易历史里。
示例
Alice JohnsonBob SmithCharlie Brown系统自动化
|
|||
|
费用类别
ExpenseCategory
|
为费用分配的类别,例如“差旅”“软件”或“餐饮”。 | ||
|
说明
此属性将费用归入预定义类别,有助于跟踪和控制公司支出。一份费用报告可能包含多个类别的项目。 按费用类别分析是“支出类别分析”仪表板的基础。它帮助财务团队了解资金流向、监控预算执行情况,并发现支出随时间变化的趋势或异常。
为什么重要
它支持详细的支出分析,帮助发现主要成本驱动因素和优化预算的机会。
获取位置
这通常是Ramp费用报告中的明细行级数据。对于某些分析,可能需要将数据汇总到报告级别。
示例
机票餐饮和娱乐软件订阅办公用品
|
|||
|
事件结束时间
EventEndTime
|
表示具有持续时间的活动结束时间的时间戳。 | ||
|
说明
许多活动是瞬时完成的,但“已执行政策检查”等活动可能具有可测量的持续时间。此属性记录这类活动的结束时间,与StartTime配合使用。 同时记录开始和结束时间,才能准确计算活动处理时长。这对于“平均政策检查时长”等KPI至关重要,也有助于准确了解整体流程中具体自动化或人工任务的完成时间。
为什么重要
它支持准确计算各项活动的持续时间,这对于发现低效流程步骤至关重要。
获取位置
对于具有持续时间的活动,该值会记录在Ramp的事件数据中。对于瞬时事件,它可以与StartTime相同。
示例
2023-10-26T10:00:05Z2023-10-26T14:35:10Z2023-10-27T09:10:00Z
|
|||
|
最近数据更新时间
LastDataUpdate
|
表示数据最近一次从源系统刷新的时间戳。 | ||
|
说明
该属性记录最近一次数据提取的日期和时间,说明当前分析数据的新鲜度。 在任何分析中,了解数据的时效性对于正确解读结果都至关重要。该属性可帮助用户判断所查看的信息是否为最新。
为什么重要
它告知用户数据的时效性,确保分析基于当前且相关的信息。
获取位置
该时间戳在数据提取过程中生成并添加。
示例
2023-11-01T06:00:00Z
|
|||
|
审批步骤数
ApprovalStepCount
|
费用报告经过的正式审批步骤总数。 | ||
|
说明
此计算指标统计单份费用报告中发生的不同审批活动数量,例如“经理已批准”和“财务已批准”,用于量化审批工作流的复杂度。 此属性用于“每份报告的平均审批步骤数”KPI和“简单费用审批路径”仪表板。结合报告金额或类别分析该数量,组织可以发现简单、低金额费用是否经历了过于复杂的审批流程。
为什么重要
它量化工作流复杂度,帮助发现简化机会,尤其适用于低风险报告。
获取位置
该值通过统计事件日志中每个案例内特定审批活动的发生次数计算得出。
示例
123
|
|||
|
审批经理
ApprovingManager
|
执行审批步骤的经理姓名。 | ||
|
说明
此属性用于识别负责审核和批准员工费用报告的经理,与提交报告的用户不同。 跟踪审批经理是“经理审批周期时间”仪表板的基础。它支持分析审批工作量和绩效,突出审批速度较快的经理以及成为瓶颈的经理,从而帮助平衡工作量或提供额外支持。
为什么重要
它支持分析各审批人的绩效,帮助发现并解决审批工作流中的瓶颈。
获取位置
这部分信息属于Ramp中的审批工作流数据,在经理处理报告时记录。
示例
Jane DoeJohn MillerSusan Chen
|
|||
|
审计结果
AuditOutcome
|
对费用报告进行内部或外部审计后得到的结果。 | ||
|
说明
对于接受正式审计的费用报告,此属性记录最终结果,例如“批准”“部分拒付”或“需要补充信息”。 这些数据是“费用审计绩效”仪表板的核心。它有助于评估审计流程的有效性,跟踪不同结果的发生频率,并了解审计发现带来的财务影响。
为什么重要
它衡量审计流程的有效性和结果,帮助发现合规情况及控制薄弱点。
获取位置
如果使用Ramp的审计模块或集成系统进行详细费用审计,结果会记录在那里。
示例
通过通过,但有备注已拒绝已升级处理
|
|||
|
报销方式
ReimbursementMethod
|
执行报销付款所采用的方式,例如ACH或电汇。 | ||
|
说明
此属性指定员工获得报销所使用的付款渠道。不同方式的处理时间和相关成本可能不同。 按报销方式分析绩效,有助于发现最高效的付款渠道。“报销方式绩效”仪表板利用这些数据比较周期时间和可靠性,为优化付款策略提供依据。
为什么重要
它支持比较不同付款渠道的绩效,帮助优化付款速度和可靠性。
获取位置
这部分信息应记录在Ramp的付款或报销记录中。
示例
ACH转账公司卡入账直接存款
|
|||
|
提交方式
SubmissionMethod
|
提交费用报告所使用的渠道,例如移动应用或Web门户。 | ||
|
说明
此属性表示员工提交费用报告的方式。常见方式包括使用移动应用、桌面浏览器或通过邮件转发。 分析提交方式可以了解用户行为和技术采用情况。例如,通过某一渠道提交的报告修订率较高,可能说明该渠道的界面存在易用性问题。
为什么重要
它提供用户行为背景,帮助判断某些提交渠道是否与较高错误率或延迟相关。
获取位置
这部分信息可能记录在Ramp系统日志中提交事件的元数据里。
示例
移动应用Web门户电子邮件
|
|||
|
是否返工
IsRework
|
用于表示费用报告是否至少被退回修改过一次的计算标记。 | ||
|
说明
此布尔属性通过检查指定案例中是否发生“费用退回修改”活动得出。凡经历过至少一轮修订的报告,该值均设为true。 此标记简化了“费用报告修订率”KPI的计算,并支持轻松筛选和比较首次通过审批的报告与需要返工的报告。分析这两个群组,可以揭示修订带来的时间和成本影响。
为什么重要
它可以快速划分流程,支持返工分析,帮助量化报告被退回修改的频率及影响。
获取位置
这是一个计算字段,在数据转换过程中通过检查案例内是否存在修订活动得出。
示例
truefalse
|
|||
|
源系统
SourceSystem
|
标识数据提取来源的应用程序。 | ||
|
说明
该属性指定流程数据的记录系统,本例中为Ramp。在数据可能来自多个系统的环境中,它有助于明确数据血缘。 在分析中,它可用于筛选特定来源的数据,也可用于数据验证和治理。
为什么重要
它提供数据来源的背景信息,对于数据治理以及整合多个系统的数据至关重要。
获取位置
通常是在数据提取和转换过程中添加的静态值(“Ramp”)。
示例
Ramp
|
|||
|
财务审批人
FinanceApprover
|
批准费用报告的财务团队用户。 | ||
|
说明
对于包含财务审核步骤的工作流,此属性用于识别财务部门中执行最终审批的具体人员或团队。 此属性支持“财务审核效率”仪表板,便于按个人或团队分析绩效。它有助于发现瓶颈、评估工作量分配,并衡量财务审核阶段的有效性。
为什么重要
它支持对财务审核步骤进行详细绩效分析,帮助优化流程中的关键控制点。
获取位置
这部分信息会在Ramp费用报告的审批历史中,于财务审核阶段记录。
示例
财务团队ADavid Lee财务自动化机器人
|
|||
费用管理活动
| 活动 | 说明 | ||
|---|---|---|---|
|
产生费用
|
表示费用创建的时刻。通常,当员工使用公司卡,或手动创建自付费用记录时,系统会自动触发该事件。该事件一般来自交易数据流或用户界面操作。 | ||
|
为什么重要
这是费用生命周期的主要开始事件。分析从该事件开始经过的时间,有助于了解提交延迟和整体流程速度。
获取位置
该事件来自Ramp卡交易日志,或手动录入费用对象的创建时间戳。请在费用表或交易表中查找初始记录创建事件。
采集
卡交易完成处理,或用户创建新的费用条目时,系统会直接记录该事件。
事件类型
explicit
|
|||
|
已与会计系统同步
|
费用交易数据已成功写入集成的会计系统,例如NetSuite、QuickBooks或Xero。该事件标志着流程中的财务记录处理完成。 | ||
|
为什么重要
这是端到端流程中的最后一个活动。此处延迟会影响财务报告的准确性和财务结账速度。
获取位置
该事件记录在集成日志中,或作为Ramp中费用对象的状态更新。请查找“Synced”“Posted”或“Exported”等状态。
采集
会计集成服务成功同步数据后,会创建一条日志记录。
事件类型
explicit
|
|||
|
已执行报销
|
报销款已成功处理并支付给员工。这通常是员工侧的最后一步,也标志着付款周期结束。 | ||
|
为什么重要
这是报销流程的主要结束事件。从提交到该事件的持续时间,是衡量员工满意度和流程效率的关键KPI。
获取位置
该事件来自付款处理日志或与支付服务商的集成。Ramp中的费用状态会更新为“Reimbursed”或“Paid”。
采集
付款系统确认转账成功后,系统会记录该事件。
事件类型
explicit
|
|||
|
已提交费用
|
员工确认费用所需信息已完整,并将其提交至审批流程。这是一次明确的用户操作,会将费用从“草稿”或“需要处理”状态转为“待审批”状态。 | ||
|
为什么重要
该活动是一个关键里程碑,标志着审批和报销周期正式开始,也是衡量审批及报销SLA的基准。
获取位置
该事件来自费用对象的状态历史,对应用户提交交易以供审核的操作。
采集
用户点击“Submit”按钮并触发状态变更时,系统会记录该事件。
事件类型
explicit
|
|||
|
经理已批准
|
经理已审核并批准该费用,费用可进入下一步,例如财务审核或报销。该事件通过明确的用户操作记录。 | ||
|
为什么重要
这是完成第一层审批的关键里程碑,对于分析审批工作流和识别瓶颈至关重要。
获取位置
经理点击“Approve”后,系统会在费用审批历史中记录该事件。事件日志应包含审批人的ID和时间戳。
采集
拥有经理权限的用户执行“Approve”操作后,系统会记录该事件。
事件类型
explicit
|
|||
|
已安排报销
|
对于自付费用,已批准金额进入付款处理队列。该事件表示费用已通过所有审批,准备付款。 | ||
|
为什么重要
该里程碑将审批流程与付款执行流程分开,有助于区分付款处理延迟和审批延迟。
获取位置
最终批准后,费用状态变为“Pending Reimbursement”或“Ready for Payment”时,通常可推断出该事件。如果付款采用批处理,也可能存在明确事件。
采集
根据状态变为“Ready for Payout”,或付款批次表中创建记录的时间确定。
事件类型
inferred
|
|||
|
已执行政策检查
|
系统会根据已配置的公司政策自动审核费用,并标记潜在违规。这通常是提交后不久发生的系统生成事件。 | ||
|
为什么重要
衡量自动化一致性检查的效率及其对流程的影响。帮助识别常见的政策违规和员工培训领域。
获取位置
该事件可能记录在与费用交易关联的审计轨迹或日志中。请查找与“policy_check”或“compliance_scan”相关的系统事件。
采集
自动政策引擎完成交易检查后,系统会创建一条日志记录。
事件类型
explicit
|
|||
|
已附加收据
|
表示收据与费用关联的时刻,可以通过OCR匹配自动完成,也可以由用户手动完成。当收据文件成功关联到交易记录时,系统会记录该事件。 | ||
|
为什么重要
跟踪此活动有助于识别因缺少凭证造成的延迟,也是确保合规和做好审计准备的关键步骤。
获取位置
收据上传或匹配后,系统会在费用或交易历史中记录该事件。请查找附件创建事件,或表示“receipt_attached”的标记。
采集
系统将收据图像或文件关联到费用记录时,会创建该事件。
事件类型
explicit
|
|||
|
待经理审核
|
费用已提交,正在等待员工直属经理审核。当费用提交后,状态变为“Pending Manager Approval”或类似值时,可推断出该状态。 | ||
|
为什么重要
标志着经理审批阶段开始。分析费用在此状态中停留的时间,是衡量和改进经理审批周期的关键。
获取位置
当费用对象状态变为“Pending Approval”等状态,并被分配到经理队列时,可推断出该事件。需要跟踪状态历史。
采集
根据费用状态变为“Pending Manager Approval”时的时间戳确定。
事件类型
inferred
|
|||
|
待财务审核
|
费用获批后已升级处理,目前正在等待财务或会计团队审核。高金额费用或存在政策标记的费用通常会进入此阶段。该活动可根据状态变更推断。 | ||
|
为什么重要
标志着财务审核周期开始。衡量该阶段的持续时间,有助于评估财务团队的工作量和效率,并识别自动化机会。
获取位置
经理批准后,费用对象状态变为“Pending Finance Approval”时,可推断出该事件。需要访问费用状态历史。
采集
根据费用状态更新为“Pending Finance Review”时的时间戳确定。
事件类型
inferred
|
|||
|
财务已批准
|
财务团队已完成审核并最终批准费用,费用可进入报销和会计同步环节。该事件由财务团队成员执行的明确用户操作记录。 | ||
|
为什么重要
表示付款前的最终审批关口。分析该活动有助于了解端到端审批周期和财务团队效率。
获取位置
该事件会记录在费用审批历史中。请查找与财务部门用户关联的审批事件。
采集
拥有财务权限的用户执行“Approve”操作后,系统会记录该事件。
事件类型
explicit
|
|||
|
费用退回修改
|
经理或财务审核人员拒绝了该费用,并将其退回员工修改。系统会将状态变更为“Needs Revision”或“Rejected”等状态。 | ||
|
为什么重要
该活动表示流程中的返工循环,会直接增加周期时间。跟踪这些事件有助于识别常见提交错误,并提升一次通过率。
获取位置
当费用对象状态变为“Needs Revision”或类似状态时,可推断出该事件。事件应关联发起该操作的审批人。
采集
根据费用状态变为“Needs Revision”或“Rejected”时的时间戳确定。
事件类型
inferred
|
|||
提取指南
释放效率:立即优化Ramp费用管理
准确定位低效环节,简化审批流程,将周期时间缩短30%。
无需信用卡,几分钟即可完成设置。