Your Expense Management Data Template
Your Expense Management Data Template
- Recommended attributes to collect for comprehensive analysis
- Key activities to track for accurate process discovery
- Practical guidance for data extraction
Expense Management Attributes
| Name | Description | ||
|---|---|---|---|
|
Activity Name
ActivityName
|
The name of the business event that occurred at a specific point in time for an expense report. | ||
|
Description
The Activity Name describes a specific step or milestone in the expense management process, such as 'Expense Report Submitted' or 'Manager Approved'. It forms the backbone of the process map, allowing analysts to visualize the flow of work, identify common pathways, and spot deviations or bottlenecks. Analyzing the sequence of activities is fundamental to understanding process efficiency and compliance.
Why it matters
This attribute defines the steps in the process map, making it possible to visualize and analyze the process flow, variations, and rework loops.
Where to get
This attribute is typically derived by mapping report status changes, comments, or history log entries from Expensify to a standardized list of activities.
Examples
Expense Report SubmittedManager ApprovedFinance RejectedReimbursement Executed
|
|||
|
Event Time
EventTime
|
The timestamp indicating when a specific activity or event occurred for an expense report. | ||
|
Description
Event Time provides the precise date and time for each activity in the process. This temporal information is essential for calculating cycle times, durations, and waiting times between different steps. It enables the analysis of bottlenecks, performance trends over time, and compliance with service level agreements. Without accurate timestamps, process mining analysis is limited to flow discovery.
Why it matters
Timestamps are essential for all time-based analysis, including calculating cycle times, identifying bottlenecks, and monitoring process performance.
Where to get
This is the creation timestamp associated with each history log entry or status change in the Expensify report data.
Examples
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-01T09:12:05Z
|
|||
|
Expense Report ID
ExpenseReportId
|
The unique identifier for an expense report, grouping all related activities from submission to reimbursement. | ||
|
Description
The Expense Report ID is the primary case identifier for the expense management process. Each ID represents a single collection of expenses submitted by an employee for approval and reimbursement. This attribute is crucial for tracking the end-to-end journey of an expense report, allowing for the reconstruction of its entire lifecycle, including all submissions, approvals, rejections, and payments.
Why it matters
It allows for the aggregation of all related events into a single process instance, which is the foundation of any process mining analysis.
Where to get
This is the primary key in the expense reports data object, often available via the Expensify API reports endpoint as 'reportID'.
Examples
RPT_84321RPT_99012RPT_10573
|
|||
|
Approver
Approver
|
The name or ID of the user responsible for approving or rejecting the expense report. | ||
|
Description
The Approver attribute identifies the manager or finance team member who takes action on a submitted expense report. This is essential for analyzing approver-specific behavior, such as approval times, rejection rates, and workload distribution. Understanding approver performance can help identify training needs, reallocate workloads, and streamline the approval process.
Why it matters
This attribute is key to analyzing approval bottlenecks, workload distribution, and approver-specific rejection rates.
Where to get
This information is found in the report's history or workflow log, often associated with approval or rejection events. The field may be labeled 'managerEmail' or similar.
Examples
jane.doe@example.comjohn.smith@example.comfinance.approver@example.com
|
|||
|
Employee Department
EmployeeDepartment
|
The business department or unit to which the submitter belongs. | ||
|
Description
This attribute indicates the organizational department of the employee submitting the expense report, such as 'Sales', 'Engineering', or 'Marketing'. It is a crucial dimension for analysis, allowing for comparisons of cycle times, rejection rates, and policy compliance across different parts of the business. This helps identify department-specific issues or training needs.
Why it matters
Enables powerful drill-down analysis to compare process performance and compliance across different business units.
Where to get
This information might be stored as a tag on the report or associated with the submitter's user profile in Expensify. It may require enrichment from an external HR system.
Examples
SalesMarketingEngineeringFinance
|
|||
|
Policy Violation Flag
PolicyViolationFlag
|
A boolean indicator that is true if the report has been flagged for a policy violation. | ||
|
Description
This flag indicates whether an expense report has triggered one or more policy violations, such as exceeding a spending limit or lacking a receipt. Expensify's automated system often flags these issues. This attribute is essential for the Policy Violation Overview dashboard, helping to quantify compliance issues and target areas for improvement.
Why it matters
Directly measures policy compliance and helps identify reports that require additional scrutiny, making it a key input for compliance dashboards.
Where to get
Expensify reports often contain a specific field or status indicating a violation, such as 'hasViolations' or a similar boolean flag.
Examples
truefalse
|
|||
|
Report Total Amount
ReportTotalAmount
|
The total monetary value of the expense report. | ||
|
Description
This attribute represents the sum of all expenses included in a single expense report. It is a critical financial metric used for various analyses, such as identifying high-value expenses that may require additional scrutiny or follow a different approval path. It is also used in financial reporting and for understanding spending patterns across the organization.
Why it matters
Enables analysis of high-value expense reports, helps identify spending trends, and is crucial for financial and compliance dashboards.
Where to get
Available in the Expensify reports object, often named 'total' or 'amount'.
Examples
150.752500.0089.50
|
|||
|
Submitter
Submitter
|
The employee who created and submitted the expense report. | ||
|
Description
The Submitter attribute identifies the employee who incurred the expenses and is seeking reimbursement. This information is used to analyze expense patterns by employee, department, or role. It helps answer questions about which employees or groups experience the most delays or have the highest policy violation rates, contributing to a better employee experience analysis.
Why it matters
Allows for analysis of process performance from the employee's view, helping to identify groups with frequent issues or delays.
Where to get
This is a primary field on the expense report object, typically labeled 'policyEmail', 'submitterEmail', or 'employeeEmail'.
Examples
sara.jones@example.comkevin.lee@example.commaria.garcia@example.com
|
|||
|
Audit Outcome
AuditOutcome
|
The result of a manual or automated audit performed on the expense report. | ||
|
Description
This attribute captures the outcome of an audit, which might be 'Passed', 'Failed', or 'Passed with Findings'. This is relevant for companies that have a formal audit step in their expense process, either for all reports or a sample. Analyzing audit outcomes helps in understanding compliance levels and the effectiveness of existing controls.
Why it matters
Directly measures the outcome of compliance checks and is essential for analyzing the effectiveness of the audit process.
Where to get
This is likely a conceptual attribute or might be stored as a tag or in a comment. Its existence depends on the company's specific process configuration within Expensify.
Examples
PassedFailed - Policy ViolationPassed with Remarks
|
|||
|
Currency
Currency
|
The currency code for the amounts in the expense report. | ||
|
Description
The Currency attribute specifies the currency of the Report Total Amount, such as USD, EUR, or GBP. This is crucial for organizations that operate in multiple countries to ensure that financial data is interpreted correctly. All monetary values should be analyzed in conjunction with this attribute to avoid incorrect aggregations.
Why it matters
Ensures accurate financial analysis and reporting by providing the necessary context for all monetary values.
Where to get
This is a standard field in the Expensify report object, often called 'currency'.
Examples
USDEURGBPCAD
|
|||
|
Event End Time
EventEndTime
|
The timestamp when a specific activity ended. Useful for activities with a measurable duration. | ||
|
Description
While many activities in expense management are instantaneous, some like 'Manager Review' can be modeled with a start and end time. The Event End Time marks the completion of such an activity. It is used in conjunction with the Start Time to calculate the precise processing time for individual steps, providing a more detailed view of where time is spent.
Why it matters
Allows for the calculation of activity processing times, which helps differentiate between active work time and idle waiting time.
Where to get
This is typically not a direct field. It is derived by taking the timestamp of the next event in the sequence for the same case.
Examples
2023-10-26T10:05:12Z2023-10-27T15:00:00Z
|
|||
|
Expense Category
ExpenseCategory
|
The category assigned to an individual expense line item within a report. | ||
|
Description
Expense Category classifies the type of spending, such as 'Travel', 'Meals & Entertainment', or 'Software'. While a report can have multiple categories, this attribute is often denormalized to the report level, for example by taking the most frequent category or the category with the highest amount. It is used to analyze spending trends and to check policy compliance for specific types of expenses.
Why it matters
Helps in analyzing spending patterns, policy violations, and approval times for different types of expenses.
Where to get
Found at the line-item level ('transactions') within a report. An aggregation or business rule is needed to assign it to the case level.
Examples
AirfareLodgingMealsOffice Supplies
|
|||
|
Is First Pass Approval
IsFirstPassApproval
|
A calculated flag that is true if the report was approved without any rejections or revisions. | ||
|
Description
This boolean flag is calculated for each expense report to determine if it went through the approval process without any negative outcomes, such as being rejected or sent back for revision. It is a direct measure of process quality and efficiency, feeding directly into the First-Pass Approval Rate KPI. A high rate indicates that submissions are of good quality and policies are well understood.
Why it matters
Directly measures the quality of initial submissions and the efficiency of the approval flow, highlighting the frequency of rework.
Where to get
This is calculated by checking the sequence of activities for a given ExpenseReportId. If the sequence does not contain 'Manager Rejected', 'Finance Rejected', or 'Report Sent Back For Revision', the flag is true.
Examples
truefalse
|
|||
|
Last Data Update
LastDataUpdate
|
The timestamp indicating when the data for this record was last refreshed from the source system. | ||
|
Description
This attribute records the date and time the data was last extracted and updated in the process mining tool. It provides transparency on data freshness and is crucial for understanding how current the analysis is. This helps users trust the insights and make informed decisions based on timely data.
Why it matters
Ensures users are aware of the data's freshness, which is critical for the relevance and accuracy of the process analysis.
Where to get
This is typically the timestamp of the data extraction job, added during the data transformation (ETL) process.
Examples
2023-11-20T08:00:00Z2023-11-21T08:00:00Z
|
|||
|
Payment Method
PaymentMethod
|
The method used for reimbursing the employee. | ||
|
Description
This attribute describes how the employee was reimbursed, such as 'Direct Deposit (ACH)', 'PayPal', or 'Company Credit Card'. Analyzing the payment method can help in understanding the reimbursement part of the process, especially if certain methods are associated with longer delays. It provides additional context for the final steps of the process.
Why it matters
Provides context for the reimbursement phase and can be used to analyze delays or costs associated with different payout methods.
Where to get
This information is typically available within the reimbursement details of a closed report.
Examples
ACHPayPalBill.com
|
|||
|
Policy Name
PolicyName
|
The name of the expense policy applied to the report. | ||
|
Description
In Expensify, different groups of employees can be subject to different expense policies. This attribute identifies the specific policy that governs the rules for the expense report. It is a critical dimension for analysis, as it allows for comparing compliance and efficiency across different policies, which may have different rules and approval workflows.
Why it matters
Allows for segmenting the process analysis by the set of rules applied, which is essential for understanding variations driven by different policies.
Where to get
This is a standard field on the report object in Expensify, often named 'policyID' or 'policyName'.
Examples
US Employee PolicyUK Sales Team PolicyExecutive Travel Policy
|
|||
|
Processing Time
ProcessingTime
|
The duration of time spent on a single activity. | ||
|
Description
Processing Time is a calculated metric that measures the time between an activity's start and end time. It represents the active time spent on a task. For example, it could measure how long a manager had a report open before approving it. This metric is used to distinguish between active work time and waiting time, providing deeper insight into process efficiency.
Why it matters
Helps distinguish between active processing time and passive waiting time, allowing for more precise identification of bottlenecks.
Where to get
This is calculated during data transformation by subtracting the EventTime from the EventEndTime.
Examples
864003600600
|
|||
|
Rejection Reason
RejectionReason
|
The reason provided by an approver when rejecting an expense report or sending it back for revision. | ||
|
Description
When an expense report is rejected, the approver can typically provide a reason. This text attribute captures that reason, providing invaluable qualitative insight into why reports fail approval. Analyzing rejection reasons helps identify common submission errors, unclear policies, or areas where employees need more training, directly supporting efforts to improve the first-pass approval rate.
Why it matters
Provides qualitative data that explains why rework occurs, which is crucial for root cause analysis of report rejections.
Where to get
This information is usually found in the comments or history log associated with a rejection event.
Examples
Missing receipt for item over $75Incorrect expense category selectedDuplicate expense submitted
|
|||
|
Report Status
ReportStatus
|
The current state of the expense report in its lifecycle. | ||
|
Description
The Report Status indicates the current position of the expense report in the process, such as 'OPEN', 'SUBMITTED', 'APPROVED', 'REIMBURSED', or 'CLOSED'. It provides a snapshot of the report's progress. In process mining, this attribute is often used to derive the Activity Name, but it can also be used as a dimension to analyze how much time reports spend in each state.
Why it matters
Indicates the current state of a case and is often the source for deriving the activity log for process mining.
Where to get
This is a standard field in the Expensify report object, often named 'status' or 'state'.
Examples
SUBMITTEDAPPROVEDREIMBURSEDCLOSED
|
|||
|
Source System
SourceSystem
|
The system from which the data was extracted. | ||
|
Description
This attribute identifies the origin of the process data, which is 'Expensify' in this case. It is important for data governance, especially in environments where data from multiple systems is combined. It helps in tracing data lineage and understanding the context of the process.
Why it matters
Provides crucial context for data lineage and helps differentiate processes when data from multiple source systems is loaded into the same environment.
Where to get
This is a static value ('Expensify') that should be added during the data transformation process.
Examples
ExpensifyExpensifyAPI-v2.0
|
|||
|
Total Cycle Time
TotalCycleTime
|
The total time elapsed from the creation of the first event to the completion of the last event for an expense report. | ||
|
Description
Total Cycle Time is a case-level calculation that measures the end-to-end duration of the expense management process for a single report. It is a key performance indicator (KPI) for overall process efficiency. This metric is calculated by taking the difference between the timestamp of the very first activity (e.g., 'Expense Report Created') and the very last activity (e.g., 'Reimbursement Executed').
Why it matters
This is a primary KPI for measuring overall process velocity and identifying long-running cases that may indicate systemic issues.
Where to get
This attribute is calculated by taking (MAX(EventTime) - MIN(EventTime)) for each ExpenseReportId.
Examples
6048001209600259200
|
|||
Expense Management Activities
| Activity | Description | ||
|---|---|---|---|
|
Expense Report Created
|
Marks the initiation of a new expense report by an employee. This is typically captured as an explicit event with a creation timestamp when the report is first saved in Expensify. | ||
|
Why it matters
This activity is the starting point for all process analysis and is crucial for measuring the total cycle time from creation to reimbursement.
Where to get
This event is captured from the report creation timestamp in Expensify's report history or audit logs. Every report object has a creation date.
Capture
Logged upon initial creation and saving of the expense report.
Event type
explicit
|
|||
|
Expense Report Submitted
|
The employee officially submits the completed expense report for the approval workflow to begin. This is a key transition from data entry to the review process, usually captured by a status change and a submission timestamp. | ||
|
Why it matters
This activity is a critical milestone that triggers the approval cycle. It serves as the starting point for measuring manager and finance review times.
Where to get
Inferred from the report's status changing from 'Open' or 'Draft' to 'Processing' or 'Submitted', along with the associated timestamp for this change.
Capture
Derived from the status change to 'Processing' and the associated submission timestamp.
Event type
inferred
|
|||
|
Finance Approved
|
The finance department or final approver has reviewed and given final approval for the expense report. This action is logged in the workflow history and typically changes the report status to 'Approved'. | ||
|
Why it matters
This is the final approval gate before reimbursement. The time taken for this step is critical for the overall cycle time and Average Reimbursement Lead Time KPI.
Where to get
Captured from the report's history or audit trail, which logs the final approval action, the approver from the finance team, and the timestamp.
Capture
Logged as a distinct final approval action in the report's workflow history.
Event type
explicit
|
|||
|
Manager Approved
|
The direct manager or first-level approver has reviewed and approved the expense report. This event is captured from the approval workflow log, which records the approver's action and timestamp. | ||
|
Why it matters
A critical milestone in the approval process. Analyzing the time from submission to this event helps identify manager related bottlenecks and measures the Manager Approval Cycle Time KPI.
Where to get
Captured from the report's history or audit trail, which explicitly logs the approval action, the approver's name, and the timestamp.
Capture
Logged as a distinct approval action in the report's workflow history.
Event type
explicit
|
|||
|
Reimbursement Executed
|
The payment has been successfully sent to the employee, completing the reimbursement part of the process. This is captured from payment processing logs or a final status update in Expensify. | ||
|
Why it matters
This is a key end-point for measuring employee facing cycle times. It is critical for the Average Expense Report Cycle Time and Average Reimbursement Lead Time KPIs.
Where to get
Inferred from the report status changing to 'Reimbursed'. Expensify's integration with payment systems provides a timestamp for this status change.
Capture
Derived from the report status changing to 'Reimbursed' and its associated timestamp.
Event type
inferred
|
|||
|
Report Closed
|
The expense report is formally closed in the system after all actions, including reimbursement and accounting sync, are complete. This event is typically inferred from a final, terminal status like 'Closed'. | ||
|
Why it matters
Provides a definitive end point for the process, distinct from reimbursement, which is useful for analyzing the final accounting and archival steps.
Where to get
Inferred from the report status changing to a terminal state like 'Closed'. This often happens after reimbursement and accounting export.
Capture
Derived from the report status changing to 'Closed' with its associated timestamp.
Event type
inferred
|
|||
|
Report Sent Back For Revision
|
An approver, either a manager or from finance, returns the report to the employee for correction or more information. This is typically inferred from a status change to 'Open' after it was 'Processing'. | ||
|
Why it matters
This activity represents rework, which is a major source of inefficiency. Tracking it helps quantify rework loops, measure the Rework Rate KPI, and identify root causes.
Where to get
Inferred from a report status change from 'Processing' or 'Submitted' back to 'Open'. The timestamp of this status change marks the event.
Capture
Derived from a report status change from 'Processing' back to 'Open'.
Event type
inferred
|
|||
|
Accounting Posted
|
The financial data from the expense report has been exported and posted to the company's accounting system or ERP. This is the final step, marking the process complete from a financial records perspective. | ||
|
Why it matters
Represents the final closure of the expense report in the financial system. It is important for measuring the full end to end process and ensuring data synchronization.
Where to get
Captured from integration logs between Expensify and the accounting software. This may require combining data from two systems.
Capture
Logged in the integration history when data is successfully synced to the accounting system.
Event type
explicit
|
|||
|
Expense Added To Report
|
Represents an employee adding a specific line item, such as a scanned receipt or a manually entered expense, to the report. This is captured as an entry in the report's detailed history log. | ||
|
Why it matters
Analyzing the time between report creation and when expenses are added can reveal delays in evidence gathering or submission preparation by employees.
Where to get
From the audit trail or history of the expense report, which logs actions like adding individual expense entries.
Capture
Logged in the report's history each time a new expense line is added.
Event type
explicit
|
|||
|
Finance Rejected
|
The finance department has reviewed and rejected the expense report, stopping the reimbursement process. This event is logged in the workflow history with a timestamp and rejection reason. | ||
|
Why it matters
Identifies bottlenecks and reasons for failure at the final review stage. It is essential for analyzing the overall rejection rate and compliance issues.
Where to get
Captured from the report's history, which records the rejection action by the finance team, along with a timestamp and user.
Capture
Logged as a distinct rejection action in the report's workflow history.
Event type
explicit
|
|||
|
Manager Rejected
|
The first-level approver has reviewed the expense report and rejected it, which typically stops the process. This is recorded as a rejection event in the workflow log, often with a reason provided. | ||
|
Why it matters
Analyzing rejection events is key to understanding the Expense Report Rejection Rate KPI. It helps identify common reasons for failure and areas needing process improvement.
Where to get
Captured from the report's history, which logs the rejection action, the rejector's identity, and the timestamp. The report status typically changes to 'Rejected'.
Capture
Logged as a distinct rejection action in the report's workflow history.
Event type
explicit
|
|||
|
Policy Violation Flagged
|
An automated check identifies an expense that violates company policy, such as being over budget or missing a receipt. This event is captured when a specific policy violation flag is set on the report or a line item. | ||
|
Why it matters
Highlights compliance issues and helps identify which policies are frequently violated, enabling targeted training or policy clarification. This is crucial for the Policy Violation Count KPI.
Where to get
Inferred from the 'Policy Violation' flag or attribute being set to true in the expense report data. The timestamp corresponds to when this flag was set.
Capture
Derived from the timestamp when the policy violation attribute for the report is updated.
Event type
inferred
|
|||
|
Reimbursement Scheduled
|
After final approval, the expense report is queued for payment processing. This event marks the transition from approval to the payment phase and is often captured when the report status changes to 'Reimbursing'. | ||
|
Why it matters
Marks the start of the reimbursement lead time. Analyzing the duration between this and the actual payment helps identify delays in the payout process.
Where to get
Inferred from a report status change to 'Reimbursing' or 'Processing Payment', with its associated timestamp.
Capture
Derived from a status change indicating the report is queued for payment.
Event type
inferred
|
|||