Your Expense Management Data Template

The Activity Name describes a step in the process, such as 'Expense Report Submitted', 'Manager Approved', or 'Reimbursement Executed'. These events form the sequence of actions that constitute the process flow.

Analyzing these activities allows for the visualization of the process map, identification of bottlenecks between steps, and calculation of frequencies for different outcomes like approvals or rejections. It is the basis for understanding what happens during the expense management process.

This attribute is critical for building the process map and understanding the sequence of events that each expense report goes through.

This information is derived from event logs or transaction statuses within the Brex system. It may require mapping from status codes or event types to user-friendly names.

Event Time provides the precise date and time for each activity in the process. This temporal information is fundamental to process mining, as it establishes the chronological order of events.

This timestamp is used to calculate cycle times between activities, identify waiting times and delays, and analyze process performance over different time periods. It powers key metrics like 'Average Manager Review Time' and 'Reimbursement Execution Lag', directly supporting bottleneck analysis and performance monitoring.

The timestamp is essential for calculating all time-based metrics, such as cycle times and waiting times, which are crucial for identifying delays.

Every event or transaction record in Brex should have an associated timestamp. This can be found in API responses or data exports for expense reports.

The Expense Report ID is the cornerstone of the expense management process. It groups all related activities, from creation and submission to approval and reimbursement, into a single case.

In process mining, this ID allows for the end-to-end analysis of each expense report's journey. It is used to reconstruct the exact path a report has taken, measure total cycle times, identify rework loops when reports are sent back for revision, and analyze process variants to understand common and exceptional flows.

This ID is essential for tracking the complete lifecycle of an expense report, enabling analysis of cycle times, bottlenecks, and process deviations.

This is a primary identifier in Brex's expense management module, typically available in all expense report-related data exports and API endpoints.

This attribute identifies the business department, such as Sales, Engineering, or Marketing, to which the submitting employee belongs. It is a key organizational dimension for analysis.

Analyzing data by department helps identify process variations, bottlenecks, or compliance issues specific to certain parts of the organization. For example, it can reveal if one department has a significantly higher rejection rate or longer approval times than others, pointing to a need for targeted training or process adjustments. It is also vital for departmental budget tracking and cost allocation.

Allows for filtering and comparing process performance across different business units, helping to identify department-specific issues or trends.

This information is usually sourced from the employee's profile in Brex, which is often synced from an HR information system.

The Event User attribute identifies the specific individual responsible for an activity. This could be the employee submitting the report, the manager reviewing it, or the finance team member processing the reimbursement.

This attribute is essential for workload analysis and performance tracking, as seen in the 'Approver Performance & Workload' dashboard. It helps identify which approvers are handling the most reports, who has the fastest approval times, and if there are any individuals who may be a bottleneck in the process. This enables a more balanced distribution of work and targeted support where needed.

Identifies the specific person responsible for an action, enabling workload analysis, performance tracking, and bottleneck identification at the individual level.

This data is typically captured in the audit trail or event history of an expense report in Brex.

This attribute is a simple true or false indicator that is set when Brex's automated policy engine detects a potential violation, such as an expense exceeding a category limit or a missing receipt.

This flag is fundamental for compliance analysis and is the basis for the 'Policy Violation Rate' KPI. It allows for quick filtering of non-compliant reports to understand their impact on processing times and rejection rates. Analyzing these flagged reports helps refine company policies and identify areas where employees need more guidance.

Directly supports compliance monitoring and helps quantify the impact of policy violations on process efficiency and rework.

This is likely a boolean field or a status indicator within the expense report data in Brex, often managed by its policy engine.

Report Status provides a snapshot of where the expense report currently stands in the process, for example, 'Pending Manager Approval', 'Approved', 'Paid', or 'Rejected'.

This attribute is crucial for operational monitoring, particularly for the 'Open Expense Reports Status Monitor' dashboard. It allows managers and finance teams to quickly see the current workload, identify reports that are stuck in a particular state, and prioritize their actions. Analyzing the time spent in each status helps pinpoint process delays and inefficiencies.

Provides a current snapshot of an expense report's position in the workflow, which is vital for operational dashboards and status monitoring.

This is a key status field on the expense report object within Brex.

This attribute represents the total amount being claimed in the expense report. It is a critical financial metric for understanding spending patterns and the financial impact of the expense process.

In analysis, the total amount can be used to segment expense reports into different value bands, such as high-value versus low-value reports, which may have different approval paths or scrutiny levels. It is also essential for financial reporting, budgeting analysis, and identifying spending trends by department or category.

This attribute allows for financial analysis, such as identifying high-value expense reports that may require more scrutiny or have longer approval times.

This is a standard field associated with every expense report in Brex. It can be found in the main expense report object in API responses or exports.

This attribute indicates the country of the employee's primary office or cost center. For global companies, this is an essential dimension for comparative analysis.

Analyzing the process by country can highlight regional differences in process performance, compliance rates, or spending behavior. For example, approval times might be longer in one country due to local regulations or different management structures. This insight is valuable for standardizing processes globally while accommodating local needs.

Allows for analysis of process performance and compliance across different geographic regions, which is critical for multinational organizations.

Sourced from the employee's profile information within Brex, which is often synced from a central HR system.

The Currency attribute specifies the unit of the Total Amount, such as USD, EUR, or GBP. This is crucial for accurate financial analysis, especially for multinational organizations dealing with multiple currencies.

This attribute ensures that financial data is interpreted correctly. It allows for proper aggregation and comparison of expense amounts, often requiring conversion to a common reporting currency. It prevents the analytical error of summing up monetary values from different currencies.

Ensures financial accuracy in a multi-currency environment and allows for correct aggregation and reporting of expense values.

This field is typically available alongside the amount field in Brex's expense report data.

Cycle Time is a calculated metric that measures the end-to-end duration for each expense report case. It is typically calculated as the difference between the timestamp of the first event (e.g., 'Expense Report Created') and the last event (e.g., 'Reimbursement Executed' or 'Accounting Posted').

This is one of the most fundamental KPIs for measuring overall process efficiency, directly supporting the 'Expense Report End-to-End Cycle Time' dashboard. Analyzing cycle time helps to identify long-running cases, understand trends in process performance, and measure the impact of process improvement initiatives.

This is a key performance indicator that measures the overall speed and efficiency of the expense management process from start to finish.

This is calculated within the process mining tool by subtracting the earliest event timestamp from the latest event timestamp for each case.

This attribute specifies the name of the employee on whose behalf the expense report was filed. While Event User identifies who performed an action, Employee Name identifies the subject of the expense report case.

In analysis, this allows for tracking expenses on a per-employee basis. It can help identify individuals who frequently submit reports with policy violations or those who consistently have reports rejected, indicating a need for additional training. It also helps in understanding spending patterns for different employees or roles within the organization.

Identifies the owner of the expense report, allowing for analysis of submission quality and compliance at the individual employee level.

This is a fundamental piece of information on every expense report, linked from the creator's user profile in Brex.

While StartTime (EventTime) marks the beginning of an activity, EndTime marks its conclusion. This is most relevant for activities that have a duration, such as 'Manager Review Started' and 'Manager Approved'.

The presence of both a start and end time for an activity allows for the precise calculation of its processing time, separating it from the waiting time that precedes it. This helps in accurately measuring how long it takes to perform the work itself, which is a key component of bottleneck analysis.

Enables the calculation of precise processing times for activities, distinct from waiting times, leading to more accurate bottleneck analysis.

EndTime is often the StartTime of the next activity in sequence. It can also be a dedicated field in the source data for activities with a defined duration.

The Expense Category is a classification chosen by the employee to describe the nature of the expense. This is used for accounting, budgeting, and policy enforcement.

In process mining, categorizing expenses allows for a more granular view of the process. It can help determine if certain categories of expenses, like international travel, have longer approval cycles or higher rejection rates. This analysis supports the refinement of policies and processes for specific types of spending.

Enables analysis of the process based on the type of spending, which can reveal different behaviors or bottlenecks for different expense types.

This is a standard field on expense line items, which would need to be aggregated to the expense report level if a report contains multiple categories.

This calculated boolean attribute identifies the most efficient process instances. It is set to 'true' only if an expense report navigates the entire process from submission to final approval without ever being rejected or sent back for revision.

This is the basis for the 'First-Pass Approval Rate' KPI, a key measure of process quality and efficiency. A high rate indicates that employees are submitting high-quality, compliant reports and that the approval process is straightforward. Analyzing the characteristics of reports that fail first-pass approval helps pinpoint sources of friction and error in the process.

Measures the quality of initial submissions and the efficiency of the core workflow by identifying reports that flow through without any friction.

This attribute is calculated within the process mining platform by analyzing the activity sequence for each case to check for the absence of rejection or revision activities.

This attribute identifies whether an activity was executed automatically by the system, like an automated policy check, or by a human user, like a manual approval.

Distinguishing between automated and manual activities is crucial for understanding the level of automation in the process. It helps in evaluating the effectiveness of rules-based systems and identifying opportunities for further automation. For instance, it can show how many reports are approved automatically versus how many require manual intervention, guiding efforts to increase touchless processing.

Helps measure the level of automation in the process and identifies which steps are performed by humans versus the system.

This is typically derived by checking the user associated with an event. System-generated events are often linked to a generic 'system' or 'bot' user.

This boolean attribute is derived from the process flow. It is set to 'true' for any expense report that includes the 'Report Sent For Revision' activity in its history. This provides a simple way to tag and analyze cases that have undergone rework.

This flag is used to calculate the 'Expense Report Rework Rate' KPI and power the 'Policy Violation & Rework Analysis' dashboard. It allows for easy comparison between cases that flow through the process smoothly and those that are sent back, helping to quantify the time and cost associated with rework.

Identifies expense reports that required extra work and correction, allowing for an analysis of the causes and costs of rework.

This attribute is not in the source system. It is calculated by checking if the sequence of activities for a case contains 'Report Sent For Revision' or similar rework activities.

This attribute indicates the freshness of the data being analyzed. It records the date and time of the last successful data extraction from Brex.

Knowing the last data update time is crucial for users to understand the timeliness of the insights. It helps them determine if the dashboards reflect the most current state of operations or if they are based on older data, managing expectations about the real-time accuracy of the analysis.

Informs users about the timeliness of the data, which is critical for making accurate, up-to-date operational decisions.

This timestamp is generated by the data extraction tool or process at the end of a successful data pull from Brex.

This attribute distinguishes between expenses charged to a company-issued Brex card and those paid for out-of-pocket by an employee that require reimbursement.

This distinction is important because the process can vary significantly based on the payment method. Corporate card transactions may follow a verification and reconciliation process, while reimbursements follow a claim and payout process. Analyzing by payment method can help isolate issues unique to each flow and optimize them independently.

The process flow and required steps often differ for corporate card expenses versus out-of-pocket reimbursements, making this a key attribute for variant analysis.

This information is inherent to the transaction data within Brex.

While the Policy Violation Flag indicates that a violation occurred, this attribute provides the 'why'. It contains details about the specific rule that was broken, such as 'Exceeded meal limit of $50' or 'Receipt required for expenses over $25'.

This level of detail is invaluable for the 'Policy Violation & Rework Analysis' dashboard. It allows for root cause analysis by identifying the most common types of violations. This insight can drive targeted actions, such as clarifying a specific policy, sending reminders to employees, or adjusting automated system rules.

Provides the root cause for policy violations, enabling targeted improvements to policies, user training, and system configurations.

This information would be available in the compliance or review notes section associated with a flagged expense in Brex.

This calculated boolean attribute is designed to measure adherence to a common process best practice: attaching all necessary receipts before submitting an expense report for review. It is set to 'true' if the 'Receipts Attached' activity occurs before the 'Expense Report Submitted' activity for a given case.

This flag directly supports the 'Receipt Adherence & Impact' dashboard and the 'Receipt Attachment Adherence' KPI. Analyzing this attribute helps to quantify how often late or missing receipts occur and to correlate this behavior with process outcomes like delays, rejections, and rework.

Measures compliance with receipt submission policies, helping to identify a common root cause of process delays and rejections.

This is calculated within the process mining tool by comparing the timestamps of the 'Receipts Attached' and 'Expense Report Submitted' activities within each case.

This attribute captures the free-text or pre-defined reason given when an expense report is rejected. This is distinct from an automated policy flag and represents a manual decision by an approver.

Analyzing rejection reasons is key to understanding the causes of process failures and rework. It helps identify common submission errors, unclear policies, or misunderstandings by employees or managers. This information can be used to improve training materials and FAQs, ultimately reducing the rejection and rework rates.

Explains why manual rejections occur, providing direct feedback that can be used to improve user training and reduce future errors.

This is typically a comment field that approvers can fill out when they take the 'Reject' action in the Brex UI.

This attribute identifies the origin of the process data, which is 'Brex' in this context. It's important for data governance and traceability, especially in environments where data from multiple systems might be combined for a holistic process view.

In analysis, it helps filter and segment data when multiple source systems are involved, ensuring that metrics and process maps are interpreted correctly based on their origin. For a single-system view, it serves as a constant validation of the data's source.

Provides essential context about data origin, ensuring traceability and enabling correct data filtering in multi-system environments.

This is a static value, 'Brex', that is typically added during the data extraction and transformation phase.