Expense approvals: prevent duplicate reimbursements
Design an expense approval workflow that separates receipt review, payment and reconciliation, with a practical duplicate-check example.
On this page
A reimbursement workflow needs separate answers to three questions: is the claim supported, is it approved, and has it been paid? An approval email answers only the second. Keeping those states separate gives employees a reliable status and gives finance a way to prevent a second payment.
Define the claim before the approval chain
Give each expense a stable claim ID. Capture the employee, expense date, merchant, amount, currency, business purpose and receipt. Group related expenses into a report without losing their individual IDs. A report can be approved even while a single line is returned for correction, if your policy and software support that distinction.
Do not use the attachment filename as the duplicate key. The same receipt can arrive as a photograph, a PDF and an email attachment. Use a combination of employee, date, merchant and amount to flag possible duplicates, then let a reviewer resolve legitimate repeat purchases.
A small example exposes the failure
In a hypothetical claim, an employee submits a taxi receipt for 840 currency units. The manager approves it. A payment export then times out, so finance reruns the export. Without a payment reference linked to the claim, both exports may include the expense.
Create an export batch ID and record which claims it contains. After a timeout, check the payment provider or bank result before retrying. A missing response is an unknown outcome, not evidence that no payment happened. Keep the claim in a visible reconciliation queue until someone resolves it.
Use states that mean something
| State | Evidence needed to leave it |
|---|---|
| Submitted | Receipt and required fields checked |
| Approved | Named approver and decision timestamp |
| Payment prepared | Unique batch and claim linkage |
| Paid | Confirmed payment reference |
| Reconciled | Payment matched to the claim and ledger |
A rejection should state what needs correcting. A request for information should return to the employee without silently changing the original receipt or removing the review history.
Test exceptions before launch
Run a duplicate receipt, a foreign-currency claim, a missing approver, a partial rejection and a payment timeout through a test environment. Check that employees can see progress without seeing other employees' expenses. Finance should be able to trace a payment back to its supporting evidence.
For a first pilot, measure unresolved payment outcomes and the age of submitted claims. Faster approvals are useful only when they do not conceal payment failures. Zoho Expense documents a separate approvals area; the control model above is a suggested implementation design that should be adapted to your own policies.
Further reading
Primary reference. The workflow examples above are illustrative implementation guidance, not customer results.
Explore the related Dood resource. To discuss your workflow, contact Dood System.