A duplicate payment audit finds vendor bills that were paid twice by grouping the invoice and payment registers in several different ways — by vendor and invoice number, by vendor and amount, by a cleaned-up invoice number, and across vendor codes that share a bank account, PAN or GSTIN — and then checking each matching pair against the bill and the bank statement. One test is never enough, because a duplicate that looked identical to the original would have been stopped by the accounting system in the first place.
Most duplicates are processing errors, not fraud. They are also one of the few audit findings that put cash back in the bank. This guide covers how duplicates get in, the tests in words, a worked example, and what to do once you find one.
Start here if you want the working file:
| Need | Use this |
|---|---|
| The tests with logic, fields and data sources for your system, plus a hit log and recovery tracker in Excel | Duplicate Payment Test Kit |
| The SAP tables and fields to ask your SAP team for | SAP Tables for Audit: Data Request Builder |
| The wider purchase-to-payment control review | P2P internal audit checklist and RCM |
How duplicate payments get in
1. The same invoice entered twice with a variant number
The bill arrives by email and again by courier, or the vendor resends it because payment is late. The second person types INV/45 where the first typed INV-0045. A dash, a slash, a missing prefix or a dropped zero is enough for the system to treat it as a new bill.
2. Two vendor codes for one supplier
The supplier was set up once by head office and again by a plant, or re-created after a name change. The system's duplicate check works inside one vendor code, so the same bill booked under each code passes cleanly twice.
3. An advance, and then the bill paid in full
An advance goes out against the purchase order. When the bill arrives it is approved and paid at face value because the approver cannot see the advance. The advance sits as a debit balance on the vendor account.
4. The purchase order route and the direct route
One copy of the bill is booked against the purchase order. Another copy reaches someone who books it as a direct expense entry. Both are valid entries in the eyes of the system.
5. A credit note that was never applied
The vendor issues a credit note for a return, a rate difference or a rejected lot. The original bill is still paid in full. No second payment was made, but the loss is the same.
A sixth route sits on the payment side rather than the invoice side: an urgent manual transfer made between payment runs, with the bill left open in the books so that the next run pays it again — or a payment file uploaded to the bank twice.
Why the system's own check is not enough
Both Tally and SAP can warn about a repeated supplier invoice number, depending on version and configuration. That warning compares the number as typed, within one vendor. It cannot see a retyped number, a second vendor code, a payment made without reference to the bill, or an advance. Treat it as a first line of defence and run the tests below on exported data.
The tests, in words
| Test | What you group or compare | What it catches |
|---|---|---|
| T1 Same vendor, same invoice number | Vendor + supplier invoice number, across financial years | The same bill entered twice |
| T2 Same vendor, same amount, dates close together | Vendor + amount, invoice dates within a window you choose, invoice numbers different | A second entry under a slightly different number |
| T3 Invoice number variants | Vendor + a cleaned invoice number: capitals, no spaces or punctuation, no leading zeros | INV-0045, INV/45 and inv 045 booked as three invoices |
| T4 Same bill under two vendor codes | Vendor codes sharing a bank account, PAN or GSTIN; then the same invoice number or amount and date across them | One supplier set up twice |
| T5 Same amount paid twice to one vendor | Payment register: vendor + amount paid within the window, confirmed against the bank statement | A manual payment plus the regular run; a file uploaded twice |
| T6 Credit note received but not applied | Vendor debit balances and unadjusted credit notes, against later bills paid in full | Returns and rate differences never recovered |
| T7 Advance paid and the bill paid in full | Open advances against later bills of the same vendor or purchase order | Advance never set off |
| T8 Same bill through two booking routes | Purchase-order invoices against direct vendor entries, same vendor, same cleaned number or same amount within the window | PO route and direct route both used |
The window for the near-match tests is your choice. Seven days is a reasonable starting point for invoice dates; payment dates often need a wider one, because a duplicate is commonly paid in the following month's run.
Two rules apply to every test. Match on the supplier's invoice number, not your own voucher or document number, which is always unique. And run the tests across at least two financial years — a bill booked in March and again in April sits in two different years, and in Tally possibly in two different company files.
Worked example: sample rows and the test that catches each
The rows below are illustrative. The near-match window is seven days.
| Row | Vendor | Invoice number as entered | Date | Amount (₹) | What happened | Caught by |
|---|---|---|---|---|---|---|
| 1 | Vendor A | PKG/0212/26-27 | 03 Aug 2026 | 64,900 | Booked at head office | — |
| 2 | Vendor A | PKG/0212/26-27 | 03 Aug 2026 | 64,900 | Booked again at the plant | T1 |
| 3 | Vendor B | INV-0045/24 | 12 Aug 2026 | 1,18,000 | Booked from the emailed copy | — |
| 4 | Vendor B | inv 45 24 | 12 Aug 2026 | 1,18,000 | Booked from the paper copy | T3 (both clean to INV4524) and T2 |
| 5 | Vendor C, code 2210 | AL-881 | 20 Aug 2026 | 2,36,000 | Booked under the original code | — |
| 6 | Vendor C, code 3317 | AL-881 | 20 Aug 2026 | 2,36,000 | Booked under a second code with the same bank account | T4 only |
| 7 | Vendor D | RENT/AUG/U1 and RENT/AUG/U2 | 01 Aug 2026 | 1,50,000 each | Rent for two separate premises | T2 — a false positive |
| 8 | Vendor E | One bill of 3,54,000 | Paid 28 Aug and 31 Aug 2026 | 3,54,000 | Paid in the run, then again by manual transfer | T5 |
| 9 | Vendor F | Credit note for a rejected lot | 18 Aug 2026 | 42,000 | Bill paid in full on 30 Aug | T6 |
| 10 | Vendor G | Advance against a purchase order | 10 Jul 2026 | 2,00,000 | Bill of 5,00,000 paid in full on 25 Aug | T7 |
| 11 | Vendor H | SV/771 against the PO; a direct entry with the number only in the narration | 22 Aug 2026 | 88,500 | Booked through both routes | T8 |
Three things to notice. Rows 5 and 6 are invisible to the first three tests, because those tests work within one vendor code. Row 7 is a hit that is not a duplicate. And rows 9 and 10 would never appear in any invoice-matching test at all, because there is only one invoice — the loss is in what was not deducted.
On these illustrative rows, the confirmed amount to recover is ₹11,03,400: the second entries in rows 2, 4, 6 and 11, the second payment in row 8, the credit note in row 9 and the advance in row 10.
Where the data comes from
| Data needed | Tally | SAP |
|---|---|---|
| Invoice register: vendor, supplier invoice number, date, amount | Purchase Register with supplier invoice number and date showing; journal vouchers that credit a supplier | BKPF and BSEG for all vendor invoices; RBKP for invoices posted through purchasing |
| Payments: vendor, date, amount, bank reference | Payment Register for the bank ledgers; bill-wise details for which bill was settled | REGUH and REGUP for payment runs; payment documents in BKPF/BSEG for manual payments; PAYR for cheques |
| Vendor master: PAN, GSTIN, bank account | Ledgers under Sundry Creditors exported from masters | LFA1, LFB1, LFBK; in S/4HANA bank details sit with the business partner |
| Debit balances, advances, unadjusted credit notes | Bill-wise outstandings for payables; Debit Note Register | Vendor open items; down payments carry a special G/L indicator on the vendor line |
Table availability differs between SAP ECC and S/4HANA, and where PAN and GSTIN are stored depends on the implementation, so ask for those by description. The data request builder lists the fields.
False positives to expect
Every test produces them. Clearing them is part of the work, not a failure of the test.
- Fixed recurring bills. Rent, retainers, subscriptions and monthly manpower bills are the same amount every month and will fill T2 until excluded. Keep a list of such vendors once checked.
- Invoice numbers restarted each year. A vendor who begins again at 001 every April will show up in T1 across years.
- A debit note and an invoice with the same number.
- An invoice reversed and correctly re-entered. Exclude reversed entries before matching.
- One PAN, several GSTINs. Normal for a supplier registered in several states.
- Instalments and milestone payments of equal amounts in T5.
- A failed transfer correctly re-issued. The bank statement will show the return credit.
- Genuine advances for orders not yet delivered, and security deposits, in T7.
What to do with a confirmed duplicate
- Confirm it. Pull both entries, the bill and the bank statement. Two debits and no return credit is a confirmed duplicate. Until then it is a hit, not a finding.
- Stop the second payment if it has not gone. If one entry is still unpaid, block it before the next payment run.
- Write to the vendor with both payment references and a copy of the bill.
- Agree the route: a refund, adjustment against the next payment, or a credit note. Where purchases continue, adjustment against the next payment is usually quickest.
- Correct the books. Reverse the entry that should not exist. If GST input credit or TDS was accounted on the duplicate entry, correct those as well.
- Record why it happened and what was changed, with an owner and a closure date. An item closes when the money is back or adjusted and the fix is in place.
- Look for a pattern. The same vendor repeatedly, a vendor code created shortly before payment, or a bank account shared with another vendor or an employee turns a processing error into something to investigate. The red flags for that are covered in our post on vendor fraud detection.
Act promptly. The older the payment, the harder the conversation with the vendor.
Prevention controls
| Control | What it closes |
|---|---|
| Supplier invoice number is mandatory and entered exactly as printed, in its own field | Variant numbers; blank fields that defeat every test |
| One entry point for vendor bills, with a received stamp or log | The same bill reaching two people |
| New vendor codes checked against existing bank accounts, PAN and GSTIN before creation | Two codes for one supplier |
| Manual and urgent payments must be matched to an open bill at the time of payment | The next run paying it again |
| Advances and unadjusted credit notes shown to the approver on the payment proposal | Bills paid at face value |
| Vendors with purchase orders cannot be booked through the direct route | Two booking routes |
| One upload per payment file, with maker and checker at the bank | A file sent twice |
| The duplicate tests run on the bills proposed for payment before each run | Everything above, before the money leaves |
The last control is the one that changes the economics. Run after the event, the tests recover money. Run before the payment run, on every bill rather than a sample, they prevent the loss — which is how continuous checks in tools such as CORAA are meant to be used, with each exception going to a named owner before the run is released.
Duplicate payment FAQ
How do I find duplicate payments to vendors?
Export the invoice register and the payment register and group them four ways: by vendor and invoice number, by vendor and amount with dates close together, by vendor and a cleaned invoice number, and across vendor codes that share a bank account, PAN or GSTIN. Then check advances and unadjusted credit notes. Confirm each pair against the bill and the bank statement.
How do I do a duplicate invoice check in Tally in 2026?
Export the Purchase Register to Excel with party name, supplier invoice number, supplier invoice date and amount showing, for the current and previous year, and run the tests on that sheet. Any built-in warning compares the number as typed, so variant numbers and second party ledgers are found only from the export.
How do I do a duplicate invoice check in SAP?
Extract vendor invoices from the accounting document tables (BKPF and BSEG) and the purchasing invoice header (RBKP), with the vendor master and bank tables (LFA1, LFB1, LFBK) and the payment run tables (REGUH, REGUP), then run the same tests. The standard duplicate-invoice check is switched on per vendor and compares the reference as typed, so cleaned-number and cross-vendor tests still need to be run on the extract.
What causes duplicate payments?
The common causes are the same bill received twice through different channels, an invoice number typed differently the second time, one supplier under two vendor codes, an urgent manual payment not matched to the open bill, and advances or credit notes not set off when the bill is paid.
How often should a duplicate payment audit be done?
Once on the last one to two years to find what has already been paid, and then before each payment run on the bills proposed for payment.
Is a duplicate payment fraud?
Not usually. Most duplicates are processing errors. A pattern — the same vendor repeatedly, a newly created vendor code, a shared bank account — is what makes it worth investigating further.