How pre-money interception stopped a duplicate-invoice ring before ACH cleared — case study

Setup — what the ledger looked like two weeks before

The customer is an anonymized mid-market specialty retailer, roughly $420M ARR, running on NetSuite with a dual-approver AP chain above $25,000 and an annual spend volume of around $310M. Disbursements cleared twice a week — Tuesdays and Fridays. The vendor file had been stable for the prior six months: no new vendors, no approver-rights changes, no banking-ACH updates. The 30-day prior payment history was clean — every cleared payment had a matched PO, an open receipt, and a complete dual-approver trail.

Then, over a 14-day window in early August 2026, two invoices landed to the same vendor, in the same amount band, with the same memo template:

• Day 1. First invoice queued to Northwind Logistics Group for $61,800.00. PO matched, dual-approver chain intact, no anomaly on the receipt signature. Payment cleared on the Day 3 disbursement run.
• Day 12. Second invoice queued to Northwind Logistics Group for $63,400.00 — a 2.59% relative delta from the cleared $61,800, well under the 5% near-duplicate threshold, well inside the 14-day short window. Same vendor, same memo template, but routed to a different banking ACH account than the cleared first payment. Held for review by the eight-detector pipeline 38 seconds after queue.

The ring here required no master-data co-move and no approver-rights co-move. The signature surfaced only at the receipt layer: same vendor, near-identical amount, inside the short window, against a different banking destination. That is the ring form findDuplicateInvoices is built to read.

Detection — what tripped, in order, and on what evidence

The first rule to trip the hold was the ring signature itself. The corroborators followed within seconds — each reading the same payment but at a different fact layer. The workpaper that surfaced to the reviewer carried all five annotations on a single receipt.

findDuplicateInvoices — HIGH. Triggered on the 14-day-window rule: same vendor ID as the cleared first payment, receipt amount $63,400.00 lands within 5% relative delta of the cleared $61,800.00 (2.59% delta), both invoices posting inside the 14-day short window. The receipt was the queued second invoice. The override field was empty — payment was held, not released.

detectDuplicatePayment — MEDIUM, corroborator. The same receipt signature from the duplicate-invoices detector re-evaluated against the cleared-payments ledger. The cleared first invoice was paid to one banking ACH; the queued second invoice was routed to a different banking ACH at the same vendor — the duplicate-payment posture this rule is built to flag, surfaced as a second independent signal on the same payment.

detectRoundDollar — MEDIUM. Both invoices were issued with no-cent amounts — $61,800.00 and $63,400.00 — and both used the same memo template that the customer's AP system had been migrating off for the prior two quarters. The template divergence was a soft signal that the second invoice had been reissued from a clone of the legacy AP memo format rather than from the live AP template the cleared first payment had used.

evaluatePolicy — HIGH. The second invoice carried an open PO reference, but the PO itself had been marked closed at the time the first payment cleared — a missing approval-chain gap on the second queue entry. The customer's AP policy states that a closed PO cannot fund a second invoice to the same vendor; the second queue entry violated that policy on the receipt signature alone. Corroborator status elevated to HIGH because the approval-chain gap is a hard policy violation.

detectVendorRisk — MEDIUM. Cross-referenced the second invoice's banking ACH against AVS records for the same vendor. The cleared first payment was routed to Northwind Logistics Group's account at a US bank with verified AVS history on prior cleared payments. The queued second invoice was routed to a different bank, in a different state, with no prior AVS history for this vendor — a banking-ACH mismatch that, taken with the near-duplicate amount and the closed PO, gives the reviewer three independent corroborations on a single receipt.

Five rules, one receipt, one workpaper. The full pipeline — evaluatePolicy, findDuplicateInvoices, detectExpenseAnomalies, detectVendorRisk, detectThresholdGaming, detectRoundDollar, detectDuplicatePayment, detectGhostEmployee— runs on every payment the customer posts; these five are the subset that tripped here. The other three returned clean on this receipt: detectExpenseAnomalies because the amount sat inside the vendor's cleared expense curve, not outside it; detectThresholdGaming because a single receipt, not a structured sub-threshold cluster, is not the surface that rule reads; detectGhostEmployee because the master vendor and approver chain were unchanged for this vendor across the window.

Findings — what the reviewer actually saw in the workpaper

The reviewer opened the second invoice's hold queue and saw, in one screen: the receipt ($63,400.00 to Northwind Logistics Group, routed to an alternative banking ACH), five rule ids (findDuplicateInvoices HIGH, detectDuplicatePayment MEDIUM, detectRoundDollar MEDIUM, evaluatePolicy HIGH, detectVendorRisk MEDIUM), zero overrides applied, and the natural-language summary laying out the evidence chain — 14-day-window near-duplicate, banking-ACH mismatch against the cleared prior payment, closed-PO approval gap, no-cent template divergence.

Five rules tripping at the same receipt is the cross-detector story the 8-detector pipeline surfaces by construction. A single rule could have caught one signal — the duplicate, the round-cent template, the approval gap, the banking mismatch, the 14-day window. No single rule by itself reconstructs the ring. The ring is the shape formed by five signals reading the same payment at five fact layers. That shape is what makes the hold defensible on first-pass review.

Remediation — the four steps the customer took

1. 1. Freeze the payment. The Friday disbursement run was paused for the queued $63,400 invoice to Northwind Logistics Group, and a payment-queue alert was raised to the AP manager for any other pending payments to that vendor. The first $61,800 had already cleared on Day 3 and was outside the freeze's reach — recovery on that payment was routed through the ACH reversal pathway and bank liaison.
2. 2. Deactivate the vendor file entry. The vendor-file entry for Northwind Logistics Group was flagged as fraudulent and quarantined across the live ERP, with a quarantine note preserving the original banking ACH detail and the alternative-ACH routing that appeared on the held invoice for the forensic trail. No further invoices to this entity were accepted at the queue.
3. 3. Attach the 5-rule workpaper to the incident report. The workpaper — receipt, rule ids (findDuplicateInvoices, detectDuplicatePayment, detectRoundDollar, evaluatePolicy, detectVendorRisk), override field empty, natural-language summary — was exported as the evidence bundle for the incident report. An internal-audit reviewer accepted it on first pass as the basis for escalating to external counsel and to the bank-relations team for ACH reversal on the cleared first payment.
4. 4. Hand to internal audit. The 5-rule workpaper, the AVS mismatch trail, the closed-PO approval gap, and the queued + cleared payment records were exported as a sealed evidence bundle and handed to internal audit. The cleared $61,800 was treated as a recoverable loss pending ACH reversal; the queued $63,400 was held indefinitely pending the formal finding.