Expense Report Workflow Modernization

Expense reporting originally depended on a physical packet. An employee completed a paper form, attached receipts, and passed the packet through multiple approval stages before it reached Accounting. Accounting then scanned the completed documentation so it could be retained in the accounting system.

I replaced that process in two production iterations. The first used an Excel template and Microsoft Forms for employee intake. Power Automate created the SharePoint record, retained the files, routed approvals, sent reminders and employee notifications, and gave Accounting a place to record its disposition and check number.

That first iteration removed the paper handoff, but production use exposed a remaining design problem. On iOS, employees had to locate the Excel file, rename it, edit it, save it, and upload it again. The downstream workflow worked; the employee intake did not work well enough. I replaced only that layer with a custom Power App and retained the functioning SharePoint, approval, reminder, notification, and Accounting backbone. Approximately 100 employees are in organizational scope, although that is not a verified active-user count.

The original workflow required a physical packet to move from the employee through approval and into Accounting. That created natural opportunities for delay, limited status visibility, misplaced documentation, and duplicated scanning and filing work.

The first digital iteration solved the paper problem. Reports, receipts, decisions, reminders, and payment documentation became part of one governed digital record. But digitizing a process does not automatically make it usable. Employees on iOS still had to manage a downloaded Excel file through several file-system steps before they could submit it.

The actual second-iteration problem was therefore narrower than “replace expense reporting.” The approval and Accounting process was already functioning. The weak layer was the employee intake experience.

Approval authority did not map cleanly to the employee’s immediate supervisor. The organization includes team leads and supervisors, but expense reports require approval by an authorized manager. The workflow therefore had to traverse the reporting hierarchy until it reached someone with the correct authority. It also had to support controlled delegates without converting every supervisory relationship into financial approval authority.

Expense data is confidential, so ordinary broad SharePoint access was not sufficient. Employees, authorized approvers, delegates, and Accounting needed different views and permissions.

The employee experience also involved more than a simple form. One report can contain multiple expense lines, mileage, meals, miscellaneous expenses, receipts, historical report periods, and year-specific mileage rates. The application needed to validate report dates, required reference data, file types, file sizes, receipt counts, calculations, and submission state.

Failure handling mattered as well. If a SharePoint record was created but a later submission step failed, the system could not leave a misleading partial financial record behind.

I owned both iterations end to end.

My responsibilities included process discovery and redesign; the original Excel and Forms intake; SharePoint lists and documentation structure; Power Automate flows; approval routing; hierarchy traversal; delegated approval; aging reminders; approval and rejection notifications; Accounting disposition and check-number tracking; the later Power App; expense-line calculations; report-period validation; receipt handling; mileage-rate reference data; application-version enforcement; failure cleanup; custom SharePoint pages and views; granular permissions; testing; demonstrations; rollout; support; and continuing improvement.

The Power App repository contains detailed implementation artifacts for formulas, validations, data sources, and connected flows. Production deployment and continuing ownership are supported by contemporaneous project records and firsthand operating context.

The first design decision was to model the actual operating process rather than simply reproduce the paper form online. The digital workflow needed to retain the report, receipts, decisions, reminders, approval history, Accounting outcome, and payment reference as one coherent record.

The second was to model real financial authority. Immediate supervision and expense approval are not always the same responsibility, so the automation traverses the reporting hierarchy until it reaches an authorized manager. Controlled delegate information is maintained separately rather than inferred casually.

The most important decision came after the first iteration entered use. I did not rebuild the entire workflow because one layer was inconvenient. The SharePoint recordkeeping, approvals, reminders, employee notifications, and Accounting stages were already functioning. I isolated the intake problem and replaced Excel and Forms with a Power App.

That reduced implementation risk, preserved controls employees and Accounting already understood, and focused the second iteration on the part that was actually failing users.

I also treated incomplete submissions as a data-integrity problem. Required reference information is checked before submission, and if a downstream operation fails after record creation, the application invokes cleanup rather than leaving an incomplete report that appears valid.

The current employee intake is a custom Power App. Employees create one report containing multiple structured expense lines. The application calculates mileage, meals, miscellaneous expenses, and the consolidated report total.

Report dates are validated against the selected month and year. Mileage rates are maintained by year so current and historical reports use the appropriate reference value. Receipt uploads are checked for supported file types, file sizes, counts, and partial failures.

The application checks its loaded version against centrally maintained reference data and tells users when a refresh is required. It also makes clear that submission begins the approval process and that the submitter cannot casually edit the report afterward.

SharePoint remains the documentation hub. Role-specific pages, views, and granular permissions protect confidential information while giving employees, approvers, delegates, and Accounting the access appropriate to their responsibilities.

Power Automate continues to manage hierarchy-aware approval, controlled delegation, reminders for aging approvals, employee approval or rejection notifications, downstream workflow stages, Accounting disposition, and check-number tracking.

The first iteration eliminated the physical approval packet, removed the employee-to-approval-to-Accounting paper handoff, centralized reports and receipts, automated approval routing and reminders, and eliminated Accounting’s need to scan the completed packet for digital retention.

The second iteration eliminated the Excel download, rename, edit, save, and upload sequence. It resolved the principal iOS usability problem, introduced structured expense-line entry, standardized calculations and validation, and strengthened controls around mileage rates, receipts, application versions, and incomplete submissions.

The workflow is live as the company-wide expense-report intake experience. Approximately 100 employees are in organizational scope, but the number of active submitters, report volume, approval time, reimbursement time, rejection rate, and missing-receipt rate have not been formally verified.

The strongest result is architectural and operational: the second iteration improved the weak user-facing layer without destabilizing the approval, security, audit, and Accounting controls already working in production.

I continue to support and improve the Power App, SharePoint structure, approval automation, permissions, reference data, validations, and downstream Accounting workflow as new operating needs emerge.

Microsoft Power Apps, SharePoint, Power Automate, Microsoft Approvals, Microsoft Forms in the first iteration, Excel in the first iteration, and governed Microsoft 365 reference data. The value of the project lies in the workflow and control decisions rather than the product names.