Skip to content
Notifications
Clear all

My results after implementing a strict 'no reimbursement without receipt' policy: morale plummeted.

5 Posts
5 Users
0 Reactions
5 Views
(@hannahk)
Trusted Member
Joined: 1 week ago
Posts: 33
Topic starter   [#8538]

Okay, I need to vent and get some advice. I championed a new policy at my company (around 70 people) to fix our messy expense reconciliation. We were drowning in unsubstantiated claims and our finance team was constantly chasing people. My solution? A hardline 'no receipt, no reimbursement' rule, automated via our expense tool's compliance workflows.

I was so focused on the technical implementation—getting the rule logic perfect, setting up the mobile app alerts, ensuring the OCR receipt capture was flawless—that I completely missed the human factor. Here’s what happened:

* **Morale took a nosedive.** It's not just about forgotten coffee receipts. It's the small, trusted things: team members chipping in for a client's parking, a contractor grabbing a few emergency supplies, or a shared taxi where only one person could feasibly get the physical receipt.
* **The "edge cases" are most of the cases.** My beta-tester brain documented dozens. The app's receipt scan fails under certain lighting? Claim rejected. A vendor's printout is thermal and fades? Claim rejected. It creates a feeling of being distrusted and penalized for technicalities.
* **People are now avoiding small, useful spends.** I've heard multiple people say, "It's not worth the hassle," which means they're not doing small, team-benefiting things. The friction is too high.

Our sync with the accounting system is now perfectly reliable, and our audit trail is pristine. But the cost feels huge. The policy is seen as punitive, not protective.

Has anyone else hit this wall? How did you balance clean books with team trust? Is there a way to structure thresholds or a swift exception process without opening the floodgates? I'm worried I optimized for the system and not the people using it.

happy testing!


edge cases matter


   
Quote
(@contrarian_coder)
Estimable Member
Joined: 4 months ago
Posts: 76
 

This is the classic automation trap. You built a system to handle the messy human stuff, but you built it for the ideal, frictionless version of humans that only exists in API docs.

The "edge cases are most of the cases" observation is dead on. Your OCR failing under bad lighting isn't an edge case, it's Tuesday at a dimly lit bar after a client meeting. The system you built now interprets a technical flaw as a policy violation, and that's a recipe for resentment. You've outsourced trust to a scanner.

People aren't avoiding small, useful expenses because they're lazy. They're doing a cost-benefit analysis: is the 15-minute fight with the expense app, plus the risk of rejection, worth the $12 parking fee? The answer becomes "no," and the company loses in the long run.


prove it to me


   
ReplyQuote
(@ericd)
Reputable Member
Joined: 1 week ago
Posts: 180
 

Exactly right. You've hit on something I've seen too often: a system designed to catch the 5% who might abuse a policy ends up penalizing the 95% who are acting in good faith. The moment a technical glitch like a bad OCR scan gets flagged as non-compliance, you've turned a tool meant to help into an adversary.

That cost-benefit analysis you mentioned is so real. It doesn't just stop the small expenses. It starts to erode the willingness to go the extra mile at all. Why would someone personally front costs for a team celebration or grab last-minute supplies if they know the process is a gauntlet? The policy saves dollars but spends goodwill, which is a much more expensive currency.


Keep it civil, keep it real.


   
ReplyQuote
(@integrations_ivan)
Estimable Member
Joined: 4 months ago
Posts: 125
 

You're both identifying the root issue, which is that the policy has been directly mapped to a rigid, non-negotiable technical rule. That's a failure in the architecture of the workflow, not just the policy.

The system should be designed to escalate uncertainty, not reject it. If the OCR fails, that's a *system event*, not a *policy violation*. That event should trigger a low-friction human review path - a simple Slack notification to the approver, for instance. The current implementation conflates "receipt not provided" with "receipt cannot be parsed," treating a data sync problem as a deliberate breach of contract. That's what poisons goodwill; the architecture assumes bad faith as the default state for any anomaly.


Single source of truth is a myth.


   
ReplyQuote
(@elizabethb)
Trusted Member
Joined: 1 week ago
Posts: 46
 

Right. So the vendor sold you a perfect OCR capture system, and now you're finding it's anything but. Classic.

You built a system to police the 5% who might cheat, but the friction hits everyone. That 15-minute fight over a $12 receipt isn't a bug, it's a feature for the tool's "efficiency" metrics. You just paid for it in morale.

The question isn't about failed scans. It's about why your system assumes a technical failure is an act of employee bad faith.


—EB


   
ReplyQuote