# Duplicate payment self-test > Run a duplicate payment self-test on your own AP data before an outside audit finds it. A step-by-step method using data you already have. Read the full guide. Source: https://valuexpa.com/insights/duplicate-payment-self-test Publisher: ValueXPA (https://valuexpa.com) Updated: 2026-09-06 --- Margin drift is the gap between what a vendor contract says and what the invoice actually charges. A duplicate payment is one specific, checkable form of it: the same charge, paid twice, sitting in your AP history right now. You do not need new software to find it. You need a query against your existing payment file and a method for reading what comes back. This guide gives you both, so you can run the test yourself before deciding whether a deeper audit is worth commissioning. ## Executive Summary A duplicate payment self-test is a repeatable query you run against your own accounts payable history to surface invoices that were paid more than once under a different invoice number, a different date, or a slightly altered amount. It costs nothing beyond an afternoon and a spreadsheet, and it tells you something an ERP's built-in duplicate check does not: whether the same real-world charge slipped through under a disguise. The mechanism behind most duplicates is not carelessness at the AP desk. It is that ERPs check for an exact match on invoice number, vendor and amount, and duplicates rarely repeat all three identically. A vendor resubmits with a new invoice number after a system change. A credit is issued and then the original is paid anyway. A statement is paid in full on top of invoices already settled individually. None of these trip an exact-match rule. Running the self-test changes what you know, not what you owe until you act on it. It gives you a list of candidates to investigate, a defensible basis for a recovery claim, and a read on whether your vendor master and matching rules need attention before the next cycle repeats the same gap. ## 1. How do you use a duplicate payment self-test? **Export twelve to eighteen months of AP payment history, then sort it by vendor and amount rather than by invoice number. Flag any pair where the same vendor, the same amount, and a close date fall within a short window of each other, even if the invoice numbers differ. Review each flagged pair against the source invoice image before assuming it is a true duplicate, since some matches are legitimate repeat charges.** Start with the payment register, not the invoice register. The payment register shows what actually left your bank account, which is the number that matters for recovery. Pull vendor name, invoice number, invoice date, payment date, and amount for every payment in the period. Sort the export by vendor and amount, not by invoice number or date. Exact-amount matches within the same vendor are the highest-yield signal, because a resubmitted or restated invoice usually carries the same charge even when the reference number changes. Once you have flagged pairs, pull the source documents. A true duplicate shows the same line items, the same PO reference where one exists, and the same service period. A false positive is usually a recurring flat fee, like a monthly service charge, that legitimately repeats at the same amount every cycle. Keep a log of what you flagged, what you confirmed, and what you dismissed and why. That log is what turns a one-time check into a control you can repeat next quarter. ## 2. What patterns should the export actually be sorted by? **Sort the export three ways in sequence: vendor plus exact amount, vendor plus amount within a small tolerance band, and vendor plus invoice date within a short window regardless of amount. Each sort catches a different disguise. The first catches identical resubmissions, the second catches partial credits paid on top of the original, and the third catches statement payments layered over invoices already paid individually.** An exact-amount, same-vendor sort catches the simplest case: the identical invoice paid twice under two invoice numbers. This is the easiest pattern to confirm and usually the fastest recovery once found. A tolerance-band sort, allowing a small percentage difference, catches a different case: the original invoice paid, then a corrected or re-issued version paid again at a slightly different amount because a late fee or a rounding adjustment was added. A date-window sort without an amount constraint catches statement-level duplication: a vendor sends a monthly statement covering invoices that AP already paid individually earlier in the cycle, and the statement gets paid in full as if it were new. Running all three sorts takes longer than running one, but each targets a mechanism the others miss entirely. ## 3. Which vendor categories are worth checking first? **Check any category where invoices arrive frequently and in high volume relative to their individual size: freight and 3PL, contract labor and staffing, and MRO or Class C supplies are structurally suited to this pattern because a high invoice count gives more opportunities for the same charge to be entered twice. This is a statement about invoice volume and structure, not a claim about which category leaks the most.** High-frequency, lower-dollar invoice categories create more opportunities for a duplicate to occur, simply because there are more invoices moving through the same approval queue in a given period. Freight and 3PL invoices often arrive daily or weekly per carrier, which is a lot of surface area for a repeat entry. Contract labor and staffing invoices frequently bill on overlapping periods, weekly against monthly, which can produce two payments covering the same hours if the overlap is not reconciled explicitly. MRO and Class C supply invoices are often processed in batches by whoever is fastest through the queue that week, which increases the odds of a second entry when a batch is re-run or partially re-keyed. None of this means these categories account for a larger share of total findings than any other. It means their invoice mechanics make a duplicate more likely to occur and worth checking first. ## 4. Why doesn't the ERP's own duplicate check already catch this? **Most ERP duplicate checks test for an exact match on vendor, invoice number, and amount, which is a narrow rule by design. A resubmitted invoice with a new number, a statement paid on top of individually paid invoices, or a corrected amount all fall outside that exact match and pass through untouched. The control is doing what it was built to do; it was simply never built to catch a disguised repeat.** An exact-match rule is fast and produces almost no false positives, which is why ERPs default to it. The tradeoff is that it only catches the laziest form of duplication: literally re-entering the same invoice number twice. The [three-way match](/guides/the-three-way-match-gap-what-your-erp-structurally-cannot), where it exists, checks the invoice against the purchase order and the goods receipt. It does not compare the invoice against prior payments to the same vendor, so it has nothing to say about whether this exact charge was already paid last month under a different reference. This is a structural gap, not a configuration mistake. Closing it requires a check that looks across payment history by vendor and amount, which is exactly what the self-test in this guide runs manually, and what a matching engine would need to run continuously to catch it before payment rather than after. ## 5. What do you do once you've confirmed a real duplicate? **Document the pair with both invoice images, the payment record, and the PO or service record if one exists, then route it to the vendor as a credit request rather than a dispute of service quality. Most vendors will apply a credit memo once shown clear proof of double payment, since it is their error too. Track the credit through to actual application against a future invoice, not just its issuance.** A confirmed duplicate is a credit conversation, not a dispute. Vendors generally process a documented double-payment claim quickly because the evidence is unambiguous: two payments, one charge. Request the credit in writing and specify whether you want a refund or an offset against a future invoice. A refund is cleaner for the record but slower; an offset is faster but needs tracking so it is not lost against a later invoice that gets paid at full value anyway. Close the loop by confirming the credit actually landed, either as cash or as a reduced future invoice. A credit memo issued but never applied is not a recovery, it is a promise. Log the root cause too: was it a resubmission, a statement overlap, or a vendor master duplicate. That detail feeds directly into fixing the control, not just the individual invoice. ## 6. How do you turn a one-time self-test into a recurring control? **Schedule the same export and sort on a fixed cadence, quarterly at minimum, rather than treating this as a one-time cleanup. Assign ownership to a specific person so the check does not quietly stop happening when priorities shift. Compare each period's flagged count against the prior period so a rising trend gets noticed before it becomes a pattern worth an outside review.** A self-test run once tells you what happened in the period you checked. It says nothing about the next twelve months unless you repeat it. Putting a name and a date on the recurring check is what keeps it alive past the first quarter. Without an owner, the query gets run once, the findings get fixed, and the habit disappears along with the person who built it. Tracking the flagged count over time turns a compliance task into a signal. A stable, low count suggests the vendor master and matching rules are holding. A rising count suggests something changed, a new vendor onboarding process, a staffing change in AP, or a vendor system migration, and is worth investigating on its own. If the volume of invoices makes a [manual quarterly export](/guides/the-quarterly-margin-drift-review-a-control-design-pattern) impractical, that volume itself is the argument for a continuous check rather than a periodic one, a tradeoff worth weighing on its own terms. For the wider pattern this sits inside, start with the [margin drift](/guides/contract-compliance-controls-p2p) guide. ## 7. Frequently Asked Questions (People Also Ask) ### How far back should a duplicate payment self-test look? Twelve to eighteen months of payment history gives enough volume to surface a genuine pattern without making the review unmanageable. Going back further rarely adds new findings once a vendor relationship and invoice process have stabilized, and it makes the export significantly harder to work through by hand. ### Can a duplicate payment self-test be done in a spreadsheet? Yes. An export of vendor, invoice number, date, and amount from the payment register, sorted and filtered in a spreadsheet, is enough to run the exact-match and tolerance-band checks described in this guide. No specialized software is required for a first pass. ### What is the difference between a duplicate invoice and a duplicate payment? A duplicate invoice is the same bill entered twice into the AP system, which may or may not get paid twice depending on whether it is caught before payment. A duplicate payment is the actual cash outflow happening twice, which is the number that matters for recovery regardless of how the entry occurred. ### Will my vendor push back on a duplicate payment claim? Most vendors accept a duplicate payment claim once shown the two payment records and matching invoice details, because the error sits on both sides of the relationship. Keep the documentation clear and specific, and route the request as a credit memo ask rather than framing it as a dispute. ### Does a three-way match in my ERP already prevent this? A three-way match checks the invoice against the purchase order and the goods receipt. It does not compare the invoice against prior payments made to the same vendor, so a resubmitted or restated invoice can pass a three-way match and still be a duplicate payment. ### How do I know if a repeated amount is a duplicate or a legitimate recurring charge? Check the service period and line-item detail on both invoices. A legitimate recurring charge, like a monthly subscription or flat retainer, covers a distinct period each time. A duplicate covers the identical period or the identical delivery, PO, or shipment reference twice. ### Should I run this self-test myself or bring in an outside review? Running it yourself first costs nothing and tells you whether the volume and pattern justify a deeper look. If the self-test turns up findings across several vendors or categories, that is a reasonable trigger to scope a full audit rather than working through it invoice by invoice. ### What data fields does the export need at minimum? Vendor name, invoice number, invoice date, payment date, payment amount, and a PO or service reference where one exists. Missing any of these narrows what the sort can catch, particularly the PO reference, which helps confirm whether two payments cover the same underlying delivery. ### Is a duplicate vendor record a separate problem from a duplicate payment? Yes, though the two are related. A duplicate vendor record, where the same vendor exists twice under slightly different names in the vendor master, makes duplicate payments harder to catch because an exact-match check on vendor name will not link the two payment histories together. ### Is contract complexity quietly draining your operating margin? A small systematic drift between your negotiated contracts and your actual vendor billing compounds quietly across a year of invoices. Stop guessing at your exposure and run a targeted audit. **[Take the Free Screener → https://valuexpa.com/margin-drift-screener](https://valuexpa.com/margin-drift-screener)** ## Executive Summary A duplicate payment self-test is a repeatable query you run against your own accounts payable history to surface invoices that were paid more than once under a different invoice number, a different date, or a slightly altered amount. It costs nothing beyond an afternoon and a spreadsheet, and it tells you something an ERP's built-in duplicate check does not: whether the same real-world charge slipped through under a disguise. The mechanism behind most duplicates is not carelessness at the AP desk. It is that ERPs check for an exact match on invoice number, vendor and amount, and duplicates rarely repeat all three identically. A vendor resubmits with a new invoice number after a system change. A credit is issued and then the original is paid anyway. A statement is paid in full on top of invoices already settled individually. None of these trip an exact-match rule. Running the self-test changes what you know, not what you owe until you act on it. It gives you a list of candidates to investigate, a defensible basis for a recovery claim, and a read on whether your vendor master and matching rules need attention before the next cycle repeats the same gap. ## 1. How do you use a duplicate payment self-test? Export twelve to eighteen months of AP payment history, then sort it by vendor and amount rather than by invoice number. Flag any pair where the same vendor, the same amount, and a close date fall within a short window of each other, even if the invoice numbers differ. Review each flagged pair against the source invoice image before assuming it is a true duplicate, since some matches are legitimate repeat charges. Start with the payment register, not the invoice register. The payment register shows what actually left your bank account, which is the number that matters for recovery. Pull vendor name, invoice number, invoice date, payment date, and amount for every payment in the period. Sort the export by vendor and amount, not by invoice number or date. Exact-amount matches within the same vendor are the highest-yield signal, because a resubmitted or restated invoice usually carries the same charge even when the reference number changes. Once you have flagged pairs, pull the source documents. A true duplicate shows the same line items, the same PO reference where one exists, and the same service period. A false positive is usually a recurring flat fee, like a monthly service charge, that legitimately repeats at the same amount every cycle. Keep a log of what you flagged, what you confirmed, and what you dismissed and why. That log is what turns a one-time check into a control you can repeat next quarter. ## 2. What patterns should the export actually be sorted by? Sort the export three ways in sequence: vendor plus exact amount, vendor plus amount within a small tolerance band, and vendor plus invoice date within a short window regardless of amount. Each sort catches a different disguise. The first catches identical resubmissions, the second catches partial credits paid on top of the original, and the third catches statement payments layered over invoices already paid individually. An exact-amount, same-vendor sort catches the simplest case: the identical invoice paid twice under two invoice numbers. This is the easiest pattern to confirm and usually the fastest recovery once found. A tolerance-band sort, allowing a small percentage difference, catches a different case: the original invoice paid, then a corrected or re-issued version paid again at a slightly different amount because a late fee or a rounding adjustment was added. A date-window sort without an amount constraint catches statement-level duplication: a vendor sends a monthly statement covering invoices that AP already paid individually earlier in the cycle, and the statement gets paid in full as if it were new. Running all three sorts takes longer than running one, but each targets a mechanism the others miss entirely. ## 3. Which vendor categories are worth checking first? Check any category where invoices arrive frequently and in high volume relative to their individual size: freight and 3PL, contract labor and staffing, and MRO or Class C supplies are structurally suited to this pattern because a high invoice count gives more opportunities for the same charge to be entered twice. This is a statement about invoice volume and structure, not a claim about which category leaks the most. High-frequency, lower-dollar invoice categories create more opportunities for a duplicate to occur, simply because there are more invoices moving through the same approval queue in a given period. Freight and 3PL invoices often arrive daily or weekly per carrier, which is a lot of surface area for a repeat entry. Contract labor and staffing invoices frequently bill on overlapping periods, weekly against monthly, which can produce two payments covering the same hours if the overlap is not reconciled explicitly. MRO and Class C supply invoices are often processed in batches by whoever is fastest through the queue that week, which increases the odds of a second entry when a batch is re-run or partially re-keyed. None of this means these categories account for a larger share of total findings than any other. It means their invoice mechanics make a duplicate more likely to occur and worth checking first. ## 4. Why doesn't the ERP's own duplicate check already catch this? Most ERP duplicate checks test for an exact match on vendor, invoice number, and amount, which is a narrow rule by design. A resubmitted invoice with a new number, a statement paid on top of individually paid invoices, or a corrected amount all fall outside that exact match and pass through untouched. The control is doing what it was built to do; it was simply never built to catch a disguised repeat. An exact-match rule is fast and produces almost no false positives, which is why ERPs default to it. The tradeoff is that it only catches the laziest form of duplication: literally re-entering the same invoice number twice. The [three-way match](/guides/the-three-way-match-gap-what-your-erp-structurally-cannot), where it exists, checks the invoice against the purchase order and the goods receipt. It does not compare the invoice against prior payments to the same vendor, so it has nothing to say about whether this exact charge was already paid last month under a different reference. This is a structural gap, not a configuration mistake. Closing it requires a check that looks across payment history by vendor and amount, which is exactly what the self-test in this guide runs manually, and what a matching engine would need to run continuously to catch it before payment rather than after. ## 5. What do you do once you've confirmed a real duplicate? Document the pair with both invoice images, the payment record, and the PO or service record if one exists, then route it to the vendor as a credit request rather than a dispute of service quality. Most vendors will apply a credit memo once shown clear proof of double payment, since it is their error too. Track the credit through to actual application against a future invoice, not just its issuance. A confirmed duplicate is a credit conversation, not a dispute. Vendors generally process a documented double-payment claim quickly because the evidence is unambiguous: two payments, one charge. Request the credit in writing and specify whether you want a refund or an offset against a future invoice. A refund is cleaner for the record but slower; an offset is faster but needs tracking so it is not lost against a later invoice that gets paid at full value anyway. Close the loop by confirming the credit actually landed, either as cash or as a reduced future invoice. A credit memo issued but never applied is not a recovery, it is a promise. Log the root cause too: was it a resubmission, a statement overlap, or a vendor master duplicate. That detail feeds directly into fixing the control, not just the individual invoice. ## 6. How do you turn a one-time self-test into a recurring control? Schedule the same export and sort on a fixed cadence, quarterly at minimum, rather than treating this as a one-time cleanup. Assign ownership to a specific person so the check does not quietly stop happening when priorities shift. Compare each period's flagged count against the prior period so a rising trend gets noticed before it becomes a pattern worth an outside review. A self-test run once tells you what happened in the period you checked. It says nothing about the next twelve months unless you repeat it. Putting a name and a date on the recurring check is what keeps it alive past the first quarter. Without an owner, the query gets run once, the findings get fixed, and the habit disappears along with the person who built it. Tracking the flagged count over time turns a compliance task into a signal. A stable, low count suggests the vendor master and matching rules are holding. A rising count suggests something changed, a new vendor onboarding process, a staffing change in AP, or a vendor system migration, and is worth investigating on its own. If the volume of invoices makes a [manual quarterly export](/guides/the-quarterly-margin-drift-review-a-control-design-pattern) impractical, that volume itself is the argument for a continuous check rather than a periodic one, a tradeoff worth weighing on its own terms. For the wider pattern this sits inside, start with the [margin drift](/guides/contract-compliance-controls-p2p) guide. ## Common questions ### How far back should a duplicate payment self-test look? Twelve to eighteen months of payment history gives enough volume to surface a genuine pattern without making the review unmanageable. Going back further rarely adds new findings once a vendor relationship and invoice process have stabilized, and it makes the export significantly harder to work through by hand. ### Can a duplicate payment self-test be done in a spreadsheet? Yes. An export of vendor, invoice number, date, and amount from the payment register, sorted and filtered in a spreadsheet, is enough to run the exact-match and tolerance-band checks described in this guide. No specialized software is required for a first pass. ### What is the difference between a duplicate invoice and a duplicate payment? A duplicate invoice is the same bill entered twice into the AP system, which may or may not get paid twice depending on whether it is caught before payment. A duplicate payment is the actual cash outflow happening twice, which is the number that matters for recovery regardless of how the entry occurred. ### Will my vendor push back on a duplicate payment claim? Most vendors accept a duplicate payment claim once shown the two payment records and matching invoice details, because the error sits on both sides of the relationship. Keep the documentation clear and specific, and route the request as a credit memo ask rather than framing it as a dispute. ### Does a three-way match in my ERP already prevent this? A three-way match checks the invoice against the purchase order and the goods receipt. It does not compare the invoice against prior payments made to the same vendor, so a resubmitted or restated invoice can pass a three-way match and still be a duplicate payment. --- ValueXPA runs a fixed-scope Margin Drift Diagnostic that validates every service vendor invoice against contract terms, for $100M+ US industrial manufacturers and distributors. Two to four weeks. The client retains 100% of recoveries. https://valuexpa.com/contact-us