Duplicate Payment Reconciliation
Review possible duplicate payments when one customer, invoice, order, or bank amount appears more than once and the safe match is unclear.
Try with sample files | View sample report
Problem statement
Duplicate-payment review is risky because amount-only matching can make two similar transfers look legitimate when one may be duplicate, reversed later, or meant for another invoice or order.
Numeric example
| Line item | Amount |
|---|
| Invoice INV-8821 | $240.00 |
| First bank transfer | $240.00 |
| Second bank transfer | $240.00 |
| Safe status | Needs duplicate review |
Why the numbers do not match
- The same customer may send two similar transfers close together.
- One invoice amount can appear more than once in the bank statement.
- A correction or reversal may arrive in a later period than the original transfer.
- Repeated amounts make amount-only matching unsafe.
What files to export
- Bank statement export with dates, signed amounts, descriptions, and references for the repeated payments.
- Invoice or order export with expected amounts, open balances, and source references.
- Optional refund or reversal support when one payment was corrected later.
Manual workflow
- Identify repeated bank rows or source rows with the same likely reference and amount.
- Match the strongest-reference payment first and leave the other row open.
- Check for later reversal, refund, correction, or credit-note support before closing the duplicate.
- Keep duplicate candidates in review until the second payment has a clear business explanation.
- Export the final report with the duplicate candidate preserved as an open case if needed.
Review checks
- Two similar payments were both marked matched against one invoice.
- A later reversal or refund was not considered before finalizing the duplicate.
- The second payment was written off without supporting evidence.
How Reconcile Locally helps
- Preserves duplicate candidates instead of forcing both rows into accepted matches.
- Keeps matched rows, duplicate-review rows, and unknown payments separated in the final output.
- Supports local review before a refund, credit, or accounting follow-up is approved.
What still needs manual review
- Final customer-credit, refund, or posting treatment remains a separate accounting decision.
- Weak references can still require follow-up outside the reconciliation file set.
Content review and sources
Written and reviewed by the Reconcile Locally product team. Last reviewed June 7, 2026.
Guidance is checked against current product behavior and first-party documentation where available. Reconciliation results still require human review.
Frequently asked questions
Should I match both payments if the amounts are the same?
No. Match the strongest-reference payment first and keep the second payment in duplicate review until another export or business explanation resolves it.
What if the second payment was refunded later?
Keep the original duplicate candidate and the later refund or reversal linked in the review package so the full payment trail stays visible.