Stop paying the same invoice twice. — on continuous audit.
Fortune 500 AP organizations typically leak 0.05–0.1% of spend to duplicates — invisible to quarterly samples, expensive to chase retroactively. VeraStream runs the same eight production detectors against every payment your business posts, so a duplicate surfaces the day the second check queues, not the day a recovery firm sends a contingency invoice. Source: Ardent Partners, State of ePayables (latest annual).
Why sample-based duplicate review is no longer enough
Three gaps in how AP teams catch duplicates today
Recovery audits cost 20–30% contingency
Outside recovery-audit firms charge contingency fees on every dollar they find — typically 20 to 30 percent for duplicate-payment engagements. The same money-back guarantees that get you a paid engagement are the same fee that comes out of your recoverable spend every quarter.
Duplicates hide across ERPs, business units, and payment runs
A single Fortune 500 AP stack spans NetSuite, SAP, Oracle, Coupa, and a tangle of regional entities. Two clerks can post the same invoice against the same vendor id under different ERP instances, and never collide on a quarterly sample — let alone erp-side master-data reconciliation.
Source: Deloitte – Audit & Risk Services
Manual quarterly reviews catch <40% of duplicates before the check clears
Quarterly sample-based duplicate review sees a fraction of the population, and the sampling cadence means most duplicates close before the auditor ever opens the file. The vast majority of recoverable dollars never get reviewed by a human.
Detector → duplicate pattern mapping
How VeraStream detects the duplicates your AP stack already creates
Eight production detectors, run continuously against every payment. The same logic that surfaces a duplicate mid-cycle also produces the workpaper — the receipt, the rule that tripped, the override applied. Test it on your own ledger at /audit or browse /pricing to see what continuous detection costs at your spend level.
| Detector | Duplicate Pattern | Sample Finding |
|---|---|---|
evaluatePolicy | Approval-matrix gap — invoice bypasses required PO/match/approver chain | A six-figure invoice posted without a three-way match — held before the payment batch cleared. |
findDuplicateInvoices | Same vendor paid twice under typosquatted IDs — legacy master + new onboarding | "Acme Logistics LLC" and "ACME Logistix LLC" both paid in the same week — flagged as duplicate invoice. |
detectExpenseAnomalies | One-cardholder, two closenames, same weekend — confirm before payment approval | Same employee charged two different merchant categories with conflicting description fields — flagged as expense anomaly. |
detectVendorRisk | Typosquat / unapproved payee / shell-vendor heuristic — near-miss name matching | New vendor "Microsot Azure LLC" — a two-character delta from "Microsoft Azure" — held before payment posted. |
detectThresholdGaming | Structured sub-threshold payments to evade approval tier | $18,400 × 2 to the same vendor within 3 hours — each below the $25,000 approver threshold, flagged as threshold gaming. |
detectRoundDollar | Round-dollar disbursements to first-seen vendors under 30 days — template / script flag | $50,000 wire to a vendor first-seen 11 days prior — no cents, same memo template as the prior batch — flagged as round-dollar. |
detectGhostEmployee | SOD weakness — new vendor on a new approver in the same week as a master-data change | A new vendor was added to the master and a new approver was granted sign-off rights within the same 48-hour window — flagged as ghost employee. |
detectDuplicatePayment | Same vendor + same or near amount clustered in a short window (recurring SaaS/rent and refund reversals auto-suppressed) | $25,000 wire to Mercury Logistics on Monday and $25,025 wire on Wednesday — flagged as a near-duplicate cluster. |
See it on real data
What continuous duplicate detection looks like in your environment
A worked sample on a 2,400-row synthetic ledger, the production detectors against your live AP feed, and an instant estimate of what your recoverable spend actually is.
Frequently asked
Common questions from AP and internal audit teams
What the agent does for accounts payable duplicate-payment detection — plain HTML answers, no JavaScript required to read.
How does continuous AP duplicate payment detection work?
The same eight production detectors — evaluatePolicy, findDuplicateInvoices, detectExpenseAnomalies, detectVendorRisk, detectThresholdGaming, detectRoundDollar, detectDuplicatePayment, detectGhostEmployee — run on every payment. The audit runs against every payment your business posts, not a quarterly sample. A duplicate surfaces the day the second check queues — the same workpaper (receipt, rule, override) is produced at the moment of flag, so the AP team can void the second payment before it clears.
What is the difference between duplicate-payment detection and a recovery audit?
A recovery audit is retroactive — a firm gets paid 20–30% contingency on every duplicate they find, usually quarterly. Continuous duplicate payment detection is preventive — every payment is checked by the eight production detectors before it clears, so duplicates are stopped at posting rather than chased months later. The same eight production detectors — evaluatePolicy, findDuplicateInvoices, detectExpenseAnomalies, detectVendorRisk, detectThresholdGaming, detectRoundDollar, detectDuplicatePayment, detectGhostEmployee — run on every payment.
Which ERPs and card feeds do you connect to for duplicate-payment detection?
Live deploys use pre-built connectors to NetSuite, SAP, Oracle, Coupa, Concur, Expensify, Brex, and Ramp. New payments and invoice postings stream into the audit in real time. The same eight production detectors — evaluatePolicy, findDuplicateInvoices, detectExpenseAnomalies, detectVendorRisk, detectThresholdGaming, detectRoundDollar, detectDuplicatePayment, detectGhostEmployee — run on every payment. If your ERP is a different platform, the /audit page lets you drop a CSV of the AP ledger and see the same detectors run in the browser — no integration required. For the connector target list and the progressive tier-by-tier rollout of each one, see /integrations.
What does the workpaper for a flagged duplicate payment look like?
Every flag ships a workpaper: the receipt (the original invoice, the duplicate posting, the payment that triggered the flag), the rule that tripped (the detector name and the threshold or heuristic that fired — one of evaluatePolicy, findDuplicateInvoices, detectExpenseAnomalies, detectVendorRisk, detectThresholdGaming, detectRoundDollar, detectDuplicatePayment, detectGhostEmployee), and any override applied. Sized to PCAOB AS 2315 — your auditor receives the same evidence package they would demand from a manual control test, but produced continuously rather than once a quarter.
How long does a baseline AP duplicate-payment scan take — and what does it cost?
A baseline scan against a full AP ledger returns flagged duplicates in under 90 seconds in the browser. A monitored live deployment — connectors to the ERP and card feed, evaluatePolicy, findDuplicateInvoices, detectExpenseAnomalies, detectVendorRisk, detectThresholdGaming, detectRoundDollar, detectDuplicatePayment, detectGhostEmployee running continuously, with weekly finding roll-ups — typically launches within two weeks of data access. Use /roi to estimate your recoverable spend before engagement.
Run it on your own ledger
Stop paying the same invoice twice.
Drop a CSV in the in-browser audit, or book a walkthrough and run VeraStream against your actual AP spend — no recovery-firm contingency, no quarterly sampling, every duplicate surfaced before the second check clears.