CORAA
Log inRun your first audit free
CORAA University · Free tool

Duplicate payment test kit 2026

Duplicate vendor payments rarely look like duplicates in the books: the invoice number is typed a little differently, the supplier has two vendor codes, or an urgent transfer was made between payment runs. Pick your system to see the tests that find them in your own data — the matching logic in plain words, the fields to pull from Tally or SAP, the false positives to expect — and download the working register and recovery tracker for FY 2026-27.

How duplicate payments happen
The same bill arrives twice
By courier and by email, or the vendor resends it because payment is late. Each copy lands with a different person.
The invoice number is typed differently
A dash, a slash, a missing prefix or a dropped zero is enough for the system to treat it as a new bill.
One supplier has two vendor codes
The duplicate check works inside one vendor code. Two codes means two clean entries.
A manual payment goes out between runs
An urgent transfer is made on request, the bill stays open in the books, and the next run pays it again.
Advances and credit notes are not set off
The bill is approved at its face value because the person approving cannot see the advance or the credit note.
The accounting system’s own warning catches only the first of these, and only when the number is typed identically under the same vendor. The rest need a test run across the whole vendor ledger.
Your system and your window
Where the vendor ledger is kept
How close two invoice dates, or two payments, must be to count as a possible repeat. A narrow window gives fewer hits to clear; a wide one catches the bill that was resubmitted a month later. It is your choice — start narrow, clear the hits, then widen.
Tally keeps each financial year’s data in the company as configured, and the supplier invoice number is a separate field from the voucher number. Export the registers to Excel with the supplier invoice number and date columns showing; the exact column names depend on the version and the configuration.
The tests to run on Tally data
T1Same vendor, same invoice number
What it catches
The same bill entered twice — a scanned copy and the original, a resubmission after a query, or a second entry by another branch.
Matching logic
Group vendor invoices by vendor and invoice number. Any group with more than one entry that has not been reversed is a hit. Run it across financial years, not within one year only.
Fields needed
Vendor code and name, supplier invoice number, invoice date, invoice amount, voucher / document number, entry date, reversal marker.
Where from — Tally
Purchase Register (and journal vouchers that credit a supplier), with the supplier invoice number and date columns switched on. Export each year's company data and stack them.
False positives
Vendors who restart invoice numbers every year; a debit note and an invoice carrying the same number; an invoice reversed and correctly re-entered.
What to do with a hit
Pull both entries and the bill. If both were paid, record the second in the recovery tracker. If one is unpaid, block it before the next payment run.
T2Same vendor, same amount, dates close together
What it catches
A second entry of the same bill under a slightly different invoice number — a typing slip, a prefix left out, or the delivery challan number used in place of the invoice number.
Matching logic
Group by vendor and invoice amount. Flag pairs whose invoice dates are within 7 days of each other and whose invoice numbers differ.
Fields needed
Vendor code, invoice amount, invoice date, supplier invoice number, document number.
Where from — Tally
Purchase Register sorted by party and amount, or the party's ledger vouchers for the period.
False positives
Rent, retainers, subscriptions, monthly manpower bills and fixed-price deliveries — genuine bills of the same amount. Keep a list of vendors with fixed recurring bills and exclude them once checked.
What to do with a hit
Compare the two bills side by side: period of service, delivery challan, purchase order line. Same supply means duplicate.
T3Invoice number variants
What it catches
INV-0045, INV/45 and inv 045 entered as three different invoices. The accounting system treats them as different numbers and its own duplicate warning stays silent.
Matching logic
Make a cleaned invoice number: capital letters, with spaces, punctuation and leading zeros removed. Then repeat the first test on vendor and cleaned number.
Fields needed
Vendor code, supplier invoice number as entered, cleaned invoice number (worked out), amount, date.
Where from — Tally
Purchase Register exported to Excel; add a column for the cleaned number.
False positives
Vendors whose series genuinely differ only by a prefix (for example a different series for each branch or each GST registration).
What to do with a hit
Where the amounts are equal, treat as the first test. Where the amounts differ, check whether one is a revised bill and whether the original was reversed.
T4Same bill under two vendor codes
What it catches
One supplier set up twice — two branches, a changed name, a re-created master — with the same bill booked and paid under each code.
Matching logic
First list vendor codes that share a bank account number, a PAN or a GSTIN. Then, within each such set, look for the same invoice number or the same amount and date booked under different codes.
Fields needed
Vendor code, name, PAN, GSTIN, bank account number and IFSC from the vendor master; invoice number, date and amount from the invoice register.
Where from — Tally
List of ledgers under Sundry Creditors with PAN, GSTIN and bank details exported from the masters, matched to the Purchase Register.
False positives
One PAN with several GSTINs is normal for a supplier registered in several states. Group companies may share a bank account legitimately, though that is worth knowing about in itself.
What to do with a hit
Recover any double payment, then merge or block the extra vendor code so it cannot be used again.
T5Same amount paid twice to one vendor
What it catches
A bill paid once through the regular payment run and again by a manual transfer or cheque, or a payment file uploaded to the bank twice.
Matching logic
From the payment register, group by vendor and amount paid. Flag two or more payments of the same amount within 7 days. Then confirm against the bank statement that both left the account.
Fields needed
Vendor code, payment date, amount paid, payment document number, bank reference (UTR or cheque number), payment mode, invoices the payment was set against.
Where from — Tally
Payment Register for the bank ledgers with party, amount, instrument number and date; the party's bill-wise details show which bill each payment was set against.
False positives
Instalments and milestone payments of equal amounts; one transfer that failed and was correctly re-issued (the bank statement will show the return).
What to do with a hit
Check the bank statement for both debits and for any return credit. Two debits and no return is a confirmed duplicate.
T6Credit note received but not applied
What it catches
Not a second payment, but the same loss: the vendor issued a credit note for a return, a rate difference or a rejected lot, and the original bill was still paid in full.
Matching logic
List vendor debit balances and unadjusted credit notes at the period end. For each, check whether later bills of that vendor were paid in full without adjusting it.
Fields needed
Vendor code, credit note / debit note number, date, amount, whether adjusted and against which bill, later payments to the vendor.
Where from — Tally
Bill-wise outstandings for payables showing debit balances and unadjusted references (on-account and debit note entries); the Debit Note Register.
False positives
Credit notes still under dispute; debit balances that are genuine advances for future supplies.
What to do with a hit
Adjust the credit against the next payment, or ask for a refund if no further purchases are expected from that vendor.
T7Advance paid and the bill paid in full
What it catches
An advance against a purchase order that was never set off: when the bill arrived it was paid at its full value, and the advance sits as a debit balance on the vendor.
Matching logic
List advances to vendors still open. For each, look for bills from the same vendor (or against the same purchase order) dated after the advance and paid without adjustment.
Fields needed
Vendor code, advance payment date and amount, purchase order number, later bill numbers and amounts, payments against those bills.
Where from — Tally
Bill-wise outstandings showing advance references still open against the party, read with the party's ledger vouchers.
False positives
Advances for orders not yet delivered; security deposits and retention held under the contract.
What to do with a hit
Set the advance off against the vendor's unpaid bills, or recover it. Ask why the advance did not show up when the bill was approved.
T8Same bill through two booking routes
What it catches
A bill booked once against the purchase order and once as a direct expense entry, often because the paper copy went to one person and the emailed copy to another.
Matching logic
Compare purchase-order invoices with direct (non-PO) vendor entries. Flag the same vendor with the same cleaned invoice number, or the same amount within 7 days, appearing in both lists.
Fields needed
Vendor code, invoice number, amount, date, voucher type or document type, purchase order number where there is one.
Where from — Tally
Purchase vouchers against journal vouchers that credit the same party; filter the Day Book by voucher type.
False positives
A freight or service bill legitimately booked without a purchase order alongside the goods bill from the same supplier.
What to do with a hit
Reverse the entry that should not exist. If both were paid, record the recovery and close the direct route for vendors that have purchase orders.
Try the invoice-number clean-up
These two are the same invoice number once cleaned. The accounting system would have accepted both; test T3 would flag the pair.
The clean-up used here: capital letters, everything except letters and digits removed, and leading zeros dropped from each run of digits. Nothing typed on this page leaves your browser.
What could be at stake — on your own assumption
Figures are in
Exposure on your assumption
—
Enter both figures to see the amount
What this number is
Arithmetic, not a finding
The rate is yours. This page gives no benchmark because the true rate depends on your own controls and data.
After the first run

The first run on a year or two of data usually produces a long list, most of it recurring bills of the same amount. Clear those once, keep the list of vendors with fixed monthly bills, and the second run is short. A hit becomes a duplicate only when the two bills are for the same supply and the bank statement shows both payments going out.

Recovering the money is half the job. Each confirmed duplicate says something about a control: a vendor master that allows two codes for one PAN, manual payments that bypass the open-bill check, or advances the approver cannot see. The wider control tests are in the procure-to-pay audit workbook and the procure-to-pay internal audit checklist; this kit covers only the duplicate tests.

Run once a year, these tests find money that has already left. Run before every payment run, the same tests stop it leaving. The monitoring rules builder shows how to turn a one-off test into a recurring one with an owner.

Before the payment, not after

The cheapest duplicate is the one caught before the money leaves

A test run on last year's ledger is a recovery exercise. The same matching, run on every bill as it is booked — every vendor, every invoice, not a sample — turns into a hold on the payment run, with the two entries side by side and a name against the decision. That is the part CORAA does.

Further reading: vendor fraud patterns and how they are detected and the procure-to-pay risk and control matrix for India.

How to find duplicate vendor payments in your own data in 2026

A duplicate payment is the same supply paid for twice. It almost never appears in the books as two identical entries, because accounting systems already warn when the same invoice number is entered twice under the same vendor. What gets through is the near-duplicate: the same bill with the number typed differently, the same bill under a second vendor code, a manual payment followed by the regular run, or a bill paid in full when an advance or a credit note should have been set off.

Each test in this kit is a way of grouping the vendor ledger so that those cases fall next to each other. The first test groups by vendor and invoice number. The second groups by vendor and amount and looks at how close the dates are. The third cleans the invoice number — capital letters, no spaces or punctuation, no leading zeros — and repeats the first test. The fourth finds vendor codes that share a bank account, PAN or GSTIN and looks for the same bill across them. The fifth works on payments rather than bills. The last three look at credit notes, advances and bills booked through two routes.

The data needed is small: an invoice register with vendor, supplier invoice number, invoice date and amount; a payment register with vendor, date, amount and bank reference; the vendor master with PAN, GSTIN and bank account; and the vendor ageing with debit balances. In Tally these come from the Purchase Register, Payment Register, bill-wise outstandings and the ledger masters. In SAP they come from the accounting document tables, the vendor master tables and the payment run tables. The page lists them for the system you pick.

Every test produces false positives, and the page says which ones to expect. Rent, retainers and monthly service bills are the same amount every month and will fill the second test until they are excluded. Clearing false positives is part of the work, not a failure of the test. What remains goes into the hit log, is checked against the bills and the bank statement, and only then moves to the recovery tracker with an owner and a closure date.

Worked example — an illustrative vendor ledger for FY 2026-27

Illustrative only. A supplier bills ₹4,72,000 on invoice number "KT/0318/26-27" dated 12 June 2026. Accounts payable books it from the emailed copy. The paper copy arrives a week later at the plant, where it is entered as "KT-318-2627" dated 12 June 2026. The system raises no warning because the two numbers differ. The first entry is paid in the June payment run and the second in July.

Inputs
Entry 1Vendor K, invoice KT/0318/26-27, 12 June 2026, ₹4,72,000 — paid 28 June
Entry 2Vendor K, invoice KT-318-2627, 12 June 2026, ₹4,72,000 — paid 27 July
Near-match window7 days
Output
T1 — same vendor, same invoice numberNo hit: the numbers differ as typed
T3 — cleaned invoice numberBoth become KT3182627 — hit
T2 — same vendor, same amount, dates within 7 daysSame amount, same invoice date — hit
T5 — same amount paid twice within 7 daysNo hit at 7 days: the payments are 29 days apart. A hit if the window is widened to 30
Confirmed against the bank statementTwo debits of ₹4,72,000, no return — duplicate of ₹4,72,000 to recover
Two of the tests catch the pair and two do not, which is why the kit runs several tests rather than one. The example also shows what the window does: on invoice dates a narrow window is enough because the dates are the same, but on payment dates a duplicate paid in the following month's run needs a wider one.

Common mistakes

Relying on the system's own duplicate warning
The built-in check compares the invoice number as typed, within one vendor code. It cannot see a retyped number, a second vendor code, or a payment made outside the invoice. It is a first line, not the test.
Testing one financial year at a time
A bill booked in March and again in April sits in two different years. In Tally in particular, where each year may be a separate company or period, stack two years of registers before running the tests.
Matching on the voucher number instead of the supplier's invoice number
The voucher or document number is given by your own system and is always unique. The test needs the supplier's invoice number. If that field is blank or holds narration, fixing the data entry rule is the first finding.
Treating every hit as a duplicate
A hit is a pair worth looking at. Fixed monthly bills, instalments and re-issued failed transfers are all legitimate. Confirm against the bills and the bank statement before writing to the vendor.
Recovering the money and stopping there
If the same route stays open, the same thing happens next quarter. Record why each duplicate happened and what was changed — vendor master clean-up, a rule on manual payments, visibility of advances at approval.
Leaving out employee and one-time vendors
One-time vendor accounts and reimbursements through the vendor ledger are where a bill is easiest to pay twice, because there is no stable vendor code to group on. Test them by amount, date and bank account.

Frequently asked questions

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 by amount and date across vendor codes that share a bank account, PAN or GSTIN. Check each resulting pair against the bills and the bank statement. This page lists the logic and the fields for each test.
How do I check for duplicate invoices in Tally in 2026?+
Export the Purchase Register to Excel with the party name, supplier invoice number, supplier invoice date and amount showing, for the current and previous year, and run the tests on that sheet. Depending on the version and configuration, Tally may warn about a repeated supplier invoice number for the same party, but any such check compares the number as typed, so variants and second party ledgers are found only by the export.
Which SAP tables are used for a duplicate invoice test?+
The accounting document header and line tables (BKPF and BSEG) for all vendor invoices, the invoice header table RBKP for invoices posted through purchasing, the vendor master tables LFA1, LFB1 and LFBK for name, company-code data and bank details, and the payment run tables REGUH and REGUP for payments. In S/4HANA the line items are also in ACDOCA and vendor bank details sit with the business partner. Table availability and custom fields vary by installation.
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 set up under two vendor codes, an urgent manual payment that is not matched to the open bill, and advances or credit notes not set off when the bill is paid.
What percentage of payments are duplicates?+
There is no figure that applies to your company, and this page deliberately gives none. The rate depends on how invoices arrive, how the vendor master is kept and how manual payments are controlled. The estimator on this page multiplies your annual vendor payments by a rate you choose, so that you can size the question; the answer comes from running the tests.
How often should the duplicate payment tests be run?+
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. Run after the event, the tests recover money; run before the payment, they prevent the loss.
How do I recover a duplicate payment from a vendor?+
Write to the vendor with both payment references and the bill, and agree one of three routes: a refund, adjustment against the next payment, or a credit note. Where purchases continue, adjustment against the next payment is usually quickest. Track each item to closure in the recovery tracker sheet.
Is a duplicate payment the same as fraud?+
Not usually. Most duplicates are processing errors. A pattern — the same vendor repeatedly, a vendor code created shortly before the payment, a bank account shared with another vendor or an employee — is what turns an error into something to investigate.

Authoritative sources

SAP Help Portal — standard table and field documentation — Reference for the standard accounting document, vendor master and payment tables named on this page. Confirm table availability for your release with your SAP team.
TallyPrime Help — registers and bill-wise details — Reference for the Purchase Register, Payment Register and bill-wise outstanding reports and how to export them.
Always confirm against the latest version of the source. Regulations evolve and amendments are common.
Related calculators
Procure-to-pay audit workbook →Procure-to-pay internal audit checklist →Internal audit monitoring rules →SAP tables for audit — data request builder →Finance controls health check →Month-end close checklist generator →
Share this tool
Last reviewed: 2026-10-01 · For informational purposes only — not professional advice.