Best way to prevent expense reimbursement errors with multiple receipts

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). 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?

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.

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.

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.

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.

BrianEdwards wrote: Mon Jan 08, 2024 2:27 pm 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.

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.

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.

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.

davea0511 wrote: Tue Jan 16, 2024 8:57 am ... 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.

jdlessley wrote: Tue Jan 16, 2024 2:44 pm

davea0511 wrote: Tue Jan 16, 2024 8:57 am ... but as consumers of their product ...

While we use the tool we are not the customer...

Fwiw, I agree with you completely, which is why I did *not * say that we are the customer, but rather those who use the product (consumer).

On a related note, I also agree that not exposing us to a feedback mechanism may be by design. We should first try to resolve issues, and perhaps make recommendations, by working through our reporting structure to someonewho has access to a trouble ticket system.

Fwiw, just this week our super-detail-oriented Bishop (which is awesome by the way) noticed an expense mistake that was likely caused by this system wherein multiple receipts for the same expense category can't be saved within a single expense request, forcing the submitter to do math outside the app to calculate the sum.

And this error which I imagine occurs in EVERY ward in the church at least once annually on average... is likely not even caught during reviews because reviewers must also do math instead of just checking numbers displayed on a receipt vs what's displayed in the entry column. Same problem with audits (which are really just a second review).

And it could all be fixed by simply allowing multiple entries for the same category within an expense report.

I'm curious when/how the multiple receipts for one category breaks down.

I can attach multiple photos of receipts to a single Tools payment request. Granted I need to do my own addition to determine total tax and total for each other category. Then, as long as I don't duplicate categories I can assign values to multiple categories. Is the error when picking the same category more than once in a request, or later in the reimbursement process?

Regarding definition of customer, I learned that it includes consumers, bosses, coworkers, production staff, contractors, suppliers, etc., all with different needs. Non -paying end user needs can even drive product design more than organization owners or managers. Just 2 cents worth of musings.

jpjones~ogr wrote: Mon Jan 22, 2024 11:54 am I'm curious when/how the multiple receipts for one category breaks down.

I can attach multiple photos of receipts to a single Tools payment request. Granted I need to do my own addition to determine total tax and total for each other category. Then, as long as I don't duplicate categories I can assign values to multiple categories. Is the error when picking the same category more than once in a request, or later in the reimbursement process?

Regarding definition of customer, I learned that it includes consumers, bosses, coworkers, production staff, contractors, suppliers, etc., all with different needs. Non -paying end user needs can even drive product design more than organization owners or managers. Just 2 cents worth of musings.

yeah, the error happens when you submit a request if you have multiple entries for a given category.

If you haven't already, sending feedback through the app about this might get the right folks thinking about a fix.

A subroutine that recognizes and resolves category duplications before passing requests to main finance systems (LCR) might be reasonable. LCR finance routines also dislike duplicate categories in individual requests.

Until then, training individuals members as needed, or taking on the process for them, is effective. Though I've seen persistent ward member confusion about multiple receipts for single categories, as well as single receipts for multiple categories, since well before LCR, I've only helped 2 folks with this Tools limitation.

Yes, you should have to ability to add multiple line items for the same category for each receipt.
It makes no sense to have the ability to only allow a user to add unique categories.
How often dose someone need different budget categories. Typically it is one and there is often multiple receipts.

I see errors quite often because people adding up multiple receipts to for one line item.

The mobile app allows it, although when submitted it combines them into one and you lose the itemized line items.