Best way to prevent expense reimbursement errors with multiple receipts

[davea0511]

The current system seems to invite error: If there are multiple receipts for a reimbursement request coming out of one budget, the person doing the submission has to add those receipts by hand. As a clerk I'm not even allowed to insert multiple receipts (one line for each) ... ie. if I try to then errors with: "Duplicate Categories are Not Allowed" (see attached), which seems like an odd thing to not allow, but who cares what I think ... it's not likely to change soon (if ever).

System can't be used to add up receipts "...Not Allowed"

Instead, the submitter should add this up manually, and it's on the Clerk to validate this by adding them up manually too (wherein I can make the same mistake as the submitter).

In order to avoid errors from long addition by hand, I've started entering in the individually receipts into LCR one per line (entry errors still possible there - an acceptable risk) just like I did in the attached image, and since it sums them up for us at the bottom, after entering them all (I just did one with 7 receipts) I then write that Sum down, compare that to what was summitted presuming the submitter also summed it up (who sometimes don't). If it doesn't match then I screenshot what's on the screen so I can send that to the submitter who's expecting a different reimbursement, then delete all the but the top entry, and enter in there what the automatically calculated Sum was.

Any suggestions on a better way to do it?

[davea0511]

I think the biggest problem with the current system where individual receipts are not allowed to be saved one per line into the system, is that (and I suspect this is the rule rather than the exception), who ever is reviewing the data ... they end up adding up the receipts in their head and try to get "close enough" to the requested amount ... rather than the exact amount. Otherwise they also have to write each receipt value down by hand and add them up using long addition ... and even then they can make the same mistake as the submitter because you know ... human.

[jpjones~ogr]

Done a lot of batch processing, professionally and personally. I like temporary spreadsheets, so I can get tax and other category subtotals. Formulas for summing rows and columns are generally easy to generate, unless maybe you use Google Sheets. But then, I use laptop or PC for batches.

A permanent spreadsheet also works. I simply gave up storing them, or sharing them among devices.

Cheers.

[rknelson]

I would like to see a total for each attachment image the submitter enters. When I review payment requests with multiple images I usually toggle back and forth between images and a calculator on my screen. If each image had a total when it was entered it would simplify the process. Requests can be messy with several receipts and crossed out or circled items to show line items that were personal or returned. With paper receipts I always attached an adding machine tape showing the total so that when others review, they can just check the paper tape without doing the math in their head. For submissions that are more complex online, I sometimes add another image from Excel with the list of receipts and the total - this is a little problematic from an audit perspective because there is no way to verify the image has correct formulas, but they can always just run the numbers again. I would really like the programmers who do the submission and review applications to consider how they could improve handling complex payment requests (like a stake girls camp food request involving several thousand dollars and dozens of receipts). I often find complex requests are easier to do with paper receipts.

[BrianEdwards]

I would really like the programmers who do the submission and review applications to consider how they could improve handling complex payment requests

As this Tech Forum is primarily member-to-member discussion and self-help, it's unlikely that your request will reach the "programmers". Good suggestions like yours should be submitted via the Feedback functionality available at the bottom of most Church webpages, or via the Church apps. That will get your ideas in front of the Church decision-makers, who are the ones that then dictate priorities to the programmers.

[rknelson]

Good suggestions like yours should be submitted via the Feedback functionality available at the bottom of most Church webpages, or via the Church apps. That will get your ideas in front of the Church decision-makers, who are the ones that then dictate priorities to the programmers.

Seems not to be the case. After submitting feedback online I received this email:

ServiceNowGSC <ServiceNowGSC@churchofjesuschrist.org>

Hello Brother Nelson,

Thank you for your feedback. As this channel is to improve the site based on member feedback, we don't typically have all the answers to current issues in LCR. To better assist you with this issue we invite you to call the Global Service Department so that an agent may better assist you over the phone. The phone numbers for the GSD can be found at https://tech.churchofjesuschrist.org/wi ... Department

Thank you,

Response Team

FYI, I called the Support Line about this also. Seems like everyone points to somewhere else to provide input.

[davea0511]

That's unfortunate. It sure would be nice is the church's software engr dept exposed to us a trouble ticket system of some kind, but as consumers of their product we aren't given that opportunity to provide feedback that closes the loop on items like this.

[jpjones~ogr]

Hear Hear, to that idea. (Sorry if spelling is in error. Didn't bother to verify. Just seems relevant, or more appropo.)

Seeing resources change in negative ways is at least disheartening.

However, I can imagine that Church IT is getting more overwhelmed as resources become increasingly sophisticated/complicated, and staffing doesn't increase to match, or may even decrease. Been there, done that, in functions other than IT.

It's hard having a crucial resource, such as trouble reporting, become increasingly isolated from users. Other organizations do it as well, so some subset of managers in the related industry probably feel it's a best practice.

I'll go back to being quiet now.

[BrianEdwards]

We all have different perspectives and experiences. The only thing I'd add for now is that many of those inside "Church IT" also hold the same church callings that we do, and likewise suffer from these same limitations when they work in their callings as clerks, tech specialists, Bishoprics, and the like. So I wouldn't necessarily think that it's purely a matter of them being disconnected or unaware... but of course that may be the case. We're all guessing from the outside without any ability to ascertain to what extent user experience impacts their decision-making, compared to the priorities that the general church departments request, and the availability of resources made available to them.

[jdlessley]

... but as consumers of their product ...

While we use the tool we are not the customer. I know that sounds ludicrous but the customer is the sponsoring department, committee, or council. That is where the ICS department and developers get their business rules and their development priorities. As users we can provide trouble reports. But if the product is working as the sponsoring customer wants then we can only hope to influence the sponsoring customer through our feedback. Alternatively we can send feedback up the priesthood chain.