Yesterday, we received an email requesting help with an employee expense reimbursement tracking tool. The company has a cap on expense reimbursements (by reimbursement period as defined by their shift type), but had not been accurately tracking which receipts were within the cap or exceeded the cap for any particular period. One of the problems they had was that, while they wanted their employees to be able to submit receipts at any time, they had not been able to keep proper track of how much of their monthly cap had been reimbursed already. In this clutter, it was likely that they’d exceeded the cap, yet continued to honor reimbursement requests.
The person who sent the email had begun to set up a spreadsheet, but ran into difficulty keeping up with the workload because figuring out the monthly reimbursement period for each request was being done manually, which was both time-consuming and inaccurate.
We took a quick overview of the scope of the data, guessed that they’d likely overpaid approximately 30%, and said we’d need a couple of hours to massage the spreadsheet into shape so that the data could tell us what was really happening.
Each row record includes a receipt date, which compares against the start date and shift type for the employee to determine the reimbursement period. That was being done manually for each record, and that was the first thing to fix.
On a Control sheet, there is an employee list; to it we appended the start date and shift type for each employee. Now, as a receipt record is entered, the start date and a reimbursement period are assigned automatically with formulas.
The Summary sheet lays out the total number of reimbursement periods for a year, and displays the reimbursement amount for each period, for each employee; it also applies the cap to the reimbursement amount, and tallies the difference between the amount claimed and the amount paid.
All in real time as data is entered on the main sheet. All with formulas.
For the historic data, all claims were paid. This tool at least clearly shows what they had paid, what they should have paid, and the difference, which is cost to the company in excess of their policy.
How much extra did they pay, you ask? (wait for it…)
But wait, it gets better. That roughly 33% over the five months the data covers amounts to pacing the company towards paying over $80,000 extra – remarkably consistent with my hypothesis.
Going forward, the tool makes it clear what should be paid and gives the company the opportunity to decide whether to pay out the entire claim or just pay up to the cap, as per company policy; doing the latter would save the company ~$80,000 each year minimum, and is an accessible cost saving opportunity because the investment in a tool that provides this for them came with a cost that, in comparison, was negligible.
Each company has its own culture, its own way of doing things. It is difficult to grab a product off the shelf to deploy for each process that is created uniquely at the department level. But at the department level, there are still lots of dollars being managed and – dare we assert – not being managed well, data-wise.
We specialize in assessing a unique process, understanding the nature of the data flowing through that process, and optimizing the tool’s functionalities to allow the data to speak, and tell the company where costs can be saved, savings which provide an exponential return on their investment in our service to them.
This was just one tool. Imagine how many other processes this company has that could benefit from this approach? What about your company? If you're suspicious that you could be handling a data process better (which means faster/more accurately/at less cost), invite us to assess it at no charge to you - if we get to work for you, our reasonable fee ranges from an hourly rate to a percentage of costs saved, plus any necessary substantial travel expenses (although travel isn't always necessary; we’ve served many of our clients remotely, as was the case in the case study above).