Duplicate payment review sheet, with the evidence next to the verdict.
Two entries for one payment is a bookkeeping problem with a technical cause, and the instinct to make the smaller-looking one disappear is usually wrong. This sheet puts the four candidate entries, the evidence that separates a double entry from a genuine second payment, and the resulting action on one page. It includes a pair that is not a duplicate, because the second one is the case that actually costs money to get wrong. Copy it as CSV and work it before you post anything.
The template, filled with an example
The example carries four candidate entries and two findings, with an as-on date of 4 October 2026. Value recorded twice is ₹25,000.00 — one pair only — against a total of₹87,200.00 entered across the four rows. The gap is the point: three of those four entries were real money, and the cash pair looked exactly as suspicious as the pair that was not.
Illustrative example only. Every counter, operator, reference, invoice number, amount and date on this page is invented. No duplicate rate, error rate, fraud statistic or benchmark of any kind is claimed anywhere on it — the two pairs were chosen to show the reasoning, because one of them is a genuine pair of payments that look identical until you check the evidence.
Header block
- Sheet as on
- 04-10-2026
- Payments under review
- 4
- Confirmed duplicates
- 2
- Value recorded twice
- ₹25,000.00
- Reviewer
- Counter supervisor (name and date at sign-off)
- Escalate to
- Owner, before any reversal is posted
Candidate entries
| Payment ref | Recorded at | Amount | Method | Counter | Operator | Applied to | State |
|---|---|---|---|---|---|---|---|
| PMT-4471 | 01-10-2026 10:14 | ₹25,000.00 | UPI | Terminal 1 | Staff A | INV-2290 | Kept |
| PMT-4472 | 01-10-2026 10:15 | ₹25,000.00 | UPI | Terminal 1 | Staff A | INV-2290 | Reversed |
| PMT-4488 | 03-10-2026 18:41 | ₹18,600.00 | Cash | Counter 2 | Staff B | INV-2304 | Kept |
| PMT-4489 | 03-10-2026 18:42 | ₹18,600.00 | Cash | Counter 2 | Staff B | INV-2304 | Reversed |
Four rows, ₹87,200.00 entered, ₹25,000.00 confirmed as double-recorded. Nothing here is a rounding artefact: 4 entries, of which 2 pairs, of which 1 pair is two real payments. That leaves ₹62,200.00 of genuinely distinct money behind 3 entries.
Evidence and verdict
| Pair | Same amount | Same external reference | Same minute | Verdict | Action |
|---|---|---|---|---|---|
| PMT-4471 / PMT-4472 | Yes — 25,000.00 both | Yes — one UPI reference on the statement, cited by both | Yes — 10:14 and 10:15, same terminal, same operator | Same money, recorded twice | Reverse PMT-4472. Keep PMT-4471. |
| PMT-4488 / PMT-4489 | Yes — 18,600.00 both | No — cash leaves no external reference | Yes — 18:41 and 18:42, same counter | Not the same money | Two genuine payments. Clear PMT-4489. Do not reverse. |
The cash pair is the one worth reading twice. Same amount, same counter, one minute apart, and it is not a duplicate — the counted cash supports both entries. A sheet that only ever finds duplicates is a sheet that will eventually reverse a real payment.
Payment ref,Recorded at,Amount,Method,Counter,Operator,Applied to,State PMT-4471,01-10-2026 10:14,25000,UPI,Terminal 1,Staff A,INV-2290,Kept PMT-4472,01-10-2026 10:15,25000,UPI,Terminal 1,Staff A,INV-2290,Reversed PMT-4488,03-10-2026 18:41,18600,Cash,Counter 2,Staff B,INV-2304,Kept PMT-4489,03-10-2026 18:42,18600,Cash,Counter 2,Staff B,INV-2304,Reversed Pair,Same amount,Same external reference,Same minute,Verdict,Action PMT-4471 / PMT-4472,"Yes — 25,000.00 both","Yes — one UPI reference on the statement, cited by both","Yes — 10:14 and 10:15, same terminal, same operator","Same money, recorded twice",Reverse PMT-4472. Keep PMT-4471. PMT-4488 / PMT-4489,"Yes — 18,600.00 both",No — cash leaves no external reference,"Yes — 18:41 and 18:42, same counter",Not the same money,Two genuine payments. Clear PMT-4489. Do not reverse.
The verdict column is free text on purpose. “Duplicate” and “not a duplicate” are not the only two answers a review can reach, and a sheet that forces a binary choice will push borderline cases into whichever box the person filling it in was trying to avoid. The header block carries the reviewer and the escalation name because a reversal is a ledger event somebody will have to explain later, and it is much easier to explain when the decision was signed off before it was posted.
How to fill it in
Four steps, and the second one is the one people skip.
Pull the pairs, do not start from a suspicion
Start from the records: same amount, same counter or same method, and a short gap between timestamps. The sheet above was produced that way, which is why one of its two pairs turned out to be legitimate.
Look for an external reference before you judge the time
A bank or provider reference that appears on both entries but exists once in the statement is close to decisive. A cash payment has no such reference, and you should say so rather than treat the missing column as agreement.
Write the verdict and the action on the same row
“Looks like a double entry” is not a decision anyone can audit later. “Same money, recorded twice — reverse PMT-4472, keep PMT-4471” is. The reason matters as much as the outcome, because the reason decides whether the fix belongs in training, in the network, or in the process.
Escalate before posting, not after
A reversal is a ledger event that somebody will have to explain. Get the owner to sign off the pair before it is posted rather than reconciling the story afterwards, and keep the reviewer and the date on the header block.
When to use this, and when to stop
A review sheet is the right size of tool while duplicates are an occasional event with a human who can adjudicate them. It stops being the right size when the only way to find them is a month-end total that does not match.
When this template is the right tool
- You have noticed a payment total that is higher than the bank or provider settlement and you need to work out which entries are real.
- Two people can record a payment against the same invoice, and you want the review written down rather than settled in a corridor.
- You are choosing between blocking the second entry automatically and flagging it for a person, and you want the decision argued on paper first.
- You have inherited records and need to establish how the duplicate-detection rule behaves before you trust it.
When you have outgrown it
- Duplicates are still being found by comparing a month-end total against a bank statement, because nothing checks them as they are entered.
- A reversal needs a note in a notebook to explain it, and that notebook lives with one person.
- Two people can record against the same invoice and both entries look equally correct to whoever reads them later.
- You cannot tell, after the fact, which of two identical entries was the one that actually moved money.
The same process in NoxOrigin
Prevention and detection are different jobs, and the system does the first so the second gets smaller. A payment carries a key derived from the event that produced it, so a retried submission returns the original result instead of creating a second record — the retry after a dropped connection stops being a finance problem. What remains is the case this sheet exists for: a genuine second payment of the same amount, which has a different key and still needs a person to decide. That decision is recorded as a reversal with its own reason and author, the original entry stays readable, and the invoice carries the applied and outstanding amounts rather than a single paid flag. We do not claim a payment can be reconciled to a provider automatically where no verified integration exists, which is why the external-reference column on this sheet is allowed to say no.
- Recording a payment twice: idempotency for moneyWhy the human cause and the system fix are different problems, and what has to be true for a second attempt to return the first result instead of a second record.
- Workflow & automation glossaryIdempotency, retry, exception and reversal, defined alongside the machinery that runs the business when nobody is watching.
- Cash, UPI and card reconciliation worksheetThe shift-close routine this sheet depends on, including where a cash payment can and cannot be settled against a reference.
- Payment collection trackerThe outstanding-side view: what was promised, by when, and what is still unpaid once allocations are recorded.
- Quotes, billing and financeWhere the invoice, the payment, and the reversal are held as separate records on one chain, so a duplicate is visible rather than netted away.
Duplicate payment review questions
The two amounts are identical and one minute apart. Is that proof?
No, and this is the reason the sheet has a reference column rather than a verdict column. An identical amount and a close timestamp are how a genuine second payment looks as well as how a double tap looks. The two entries above show both cases, and the pair that is the same money is only distinguishable because both entries cite one bank reference that the statement contains once. Amount and time narrow the field; they do not close it.
Our payment method is cash. What do we compare then?
The counter, the drawer, and the count. A cash payment leaves no external reference, so the question becomes whether the drawer holds the money once or twice — which is a shift-close question, not a payment-record question. That is why the second pair on this sheet resolves to two genuine payments: the second entry is also supported by the counted cash, and reversing it would be wrong. Where the drawer cannot settle it, the honest outcome is to flag the pair for the owner rather than pick one.
What should happen to the entry that was not real?
It should be reversed by an equal and opposite entry, not deleted. Deleting it removes the evidence that it ever existed, which is exactly what you need when someone asks why a sum does not match the bank. The reversal carries its own reason and its own author, so the trail shows the duplicate was found and dealt with rather than quietly removed. The original entry stays readable either way.
Should the person who made the duplicate be told?
Yes, and without blame, because the useful information is where it came from. A double tap is a screen problem, a retry after a slow connection is a network problem, two shifts both closing is a process problem, and a re-run import is a system problem. Only the last of those is fixed by software. The sheet records the cause rather than the person, so the fix targets the mechanism.
Can a system just stop this happening?
It can stop most of it, and the mechanism is that each payment carries a key, so a second attempt with the same key returns the first result instead of creating a second record. That is what idempotency means, and it is a real protection. It is not complete, though: a genuine second payment of the same amount has a different key, so it is still a judgement call afterwards. Detection and prevention are different jobs, and the second one does not remove the first.
Make the second attempt return the first result.
The expensive duplicates are the ones found a month later by a total that does not match. Catching them at entry removes the argument, not just the error.