On this page Jump to section
Abstract. This paper sets out a reproducible method for detecting duplicate vendor payments in a small QuickBooks Online ledger. It defines the observation unit, compares exact and fuzzy match keys, describes how to estimate false positives, and explains why a detection rate without a review cost is not a useful result.
The method is for local process improvement. It does not estimate industry loss rates or certify a control.
The operational question
When a vendor bill is entered twice and paid twice, the loss is real but the evidence is thin. The two payments look independent in the bank feed, and the vendor may not volunteer a refund.
The practical question is narrower than "how common is duplicate payment fraud." It is: among bills and payments in a defined period, which pairs are similar enough to review, and what does reviewing them cost?
That framing makes the result actionable. A method that flags 40 candidates per month with 5 confirmed duplicates is different from one that flags 400 with the same 5.
Define the observation unit
Choose the unit before choosing the algorithm. Options are the bill, the payment, or the vendor-payment pair.
The bill is the natural unit for preventing duplicates. The payment is the natural unit for recovering them. The pair is what a reviewer actually examines.
Record the period, the systems included, the currency, and whether credits and prepayments are in scope. A method that ignores credits will report false duplicates whenever a vendor applies a credit to a later invoice.
Build the match keys
Start with exact keys. Vendor identifier plus invoice number is the strongest available key in most small ledgers. It fails when invoice numbers are missing, inconsistently formatted, or reused by the vendor.
Add a second key: vendor plus amount plus a date window. The width of the window is a judgment. Too narrow and a re-entry a week later is missed. Too wide and recurring monthly bills appear as duplicates.
A third key can use the attachment hash or file name when documents are stored consistently. This catches the same PDF entered twice under different dates.
Document the key definitions and keep them stable across periods so the trend is comparable.
Handle fuzzy matches explicitly
Fuzzy matching helps with vendor name variants and invoice numbers with prefixes or punctuation. It introduces two costs: false positives and arbitrary thresholds.
Choose the threshold from a labelled sample, not from intuition. Take 100 candidate pairs, have a reviewer label each as duplicate or not, and compare the threshold's precision at several settings.
Report precision and recall together. A threshold with high recall and low precision buries the reviewer. A threshold with high precision and low recall misses the cases the process exists to catch.
Count the review cost
Every candidate has a cost: the minutes needed to open both bills, compare attachments, check the payment, and record a decision.
Measure that time on a sample. Multiply by the candidate count to estimate the monthly review load. Compare it with the value of confirmed duplicates recovered.
This comparison is what justifies tightening or loosening the rule. It also prevents a well-intentioned control from consuming more time than it saves.
Design the review record
For each candidate, record the two bill or payment identifiers, the match key that fired, the amount, the dates, the reviewer, the decision, and the evidence.
Keep a reason code: exact duplicate, recurring charge, split payment, credit applied, vendor error, or unresolved. The codes tell you whether the rule or the process needs work.
Retain the record with the close file. An auditor asking why a payment was made twice needs the review, not just the payment.
Test with historical data
Before running the method live, apply it to a closed period. Compare the candidates it finds with the duplicates that were actually identified at the time.
This back-test exposes keys that never fire and rules that produce noise. It also gives a baseline for the review cost.
Do not tune the method on the same period you report. Use one period to set thresholds and a later period to evaluate.
Limitations
The method cannot see duplicate payments made to different vendor records for the same supplier. It depends on vendor master hygiene.
It does not detect duplicate payments across currencies without a rate conversion rule, and it does not distinguish an intentional split payment from an error.
Finally, a low duplicate count is not proof of a good control. It may mean the detection is weak or the review is not happening.
Sources
- Committee of Sponsoring Organizations of the Treadway Commission, Internal Control over Financial Reporting guidance: https://www.coso.org/guidance-on-ic
- PCAOB Auditing Standard 1105, Audit Evidence: https://pcaobus.org/oversight/standards/auditing-standards/details/AS1105
- U.S. Government Accountability Office, Standards for Internal Control in the Federal Government: https://www.gao.gov/green-book
- Internal Revenue Service, How long should I keep records: https://www.irs.gov/businesses/small-businesses-self-employed/how-long-should-i-keep-records