How post-clearing duplicate-payment detection caught a $84,200 retry on a 30-day window — case study

Setup — what the ledger looked like before the duplicate cleared

The customer is an anonymized mid-market industrial-packaging manufacturer, roughly $260M ARR, running on SAP with a single-approver AP chain above $40,000 and an annual spend volume of around $190M. Disbursements cleared daily through an automated ACH batch at 14:00 ET. The vendor file had been stable for the prior four months — no new vendor onboarding, no banking-ACH updates, no approver-rights changes. The prior 60-day cleared-payment history showed clean approver chains and consistent banking destinations for the two vendors in the affected spend category.

Then, over a 30-day window in mid-2026, two invoices landed to the same vendor — submitted through two different AP intake channels but routed against the same SAP vendor master record:

• Day 1. First invoice queued to Lakeshore Freight Systems for $82,000.00. PO matched, single-approver chain intact, automated disbursement cleared the same day at 14:00. Payment posted as a normal cleared-line entry on the SAP vendor master.
• Day 24. Second invoice queued to Lakeshore Freight Systems for $84,200.00 — a 2.68% relative delta from the cleared $82,000, well under the 5% near-duplicate threshold, well inside the 30-day cleared-payments window. Different intake channel, different invoice number, but routed to a banking ACH account closely matching — not identical to — the cleared first payment. Single-approver chain intact. Automated disbursement cleared the same day.

The duplicate here was structurally different from the pre-money ring. The receipt-layer signature on each individual queue entry was clean — PO matched, approver chain intact, no round-cent anomaly, no template divergence, no near-term prior queued receipt. From the queue perspective, there was nothing to flag either invoice at queue time. From the cleared-payments ledger perspective, the duplicate is unambiguous. detectDuplicatePayment is built to read that distinction.

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

The duplicate surfaced on the cleared-payments ledger two business days after the second payment cleared, when the daily continuous-audit re-run evaluated the newly-cleared second payment against all cleared payments inside the 30-day window at the same vendor. The lead rule and the corroborators fired on the second cleared payment within seconds of each other. The workpaper surfaced to the reviewer carried four annotations on a single cleared payment.

detectDuplicatePayment — HIGH. Triggered on the 30-day cleared-payments ledger rule: same SAP vendor master record (Lakeshore Freight Systems) as the cleared first payment, settled amount $84,200.00 lands within 5% relative delta of the cleared $82,000.00 (2.68% delta), both payments cleared inside the 30-day window. The receipt evaluated was the second cleared payment, not the original queued receipt. The override field was empty — the payment was already disbursed, so the rule surfaces it for ACH-reversal review rather than for queue hold.

findDuplicateInvoices — MEDIUM, corroborator. The rule that fires on the 14-day short-window queue signature ran on the receipt and returned clean at queue time — the second invoice was 24 days after the first, outside the 14-day queue window, but inside the broader 30-day cleared window. The detected pairing here, therefore, was a cleared-payments pairing, not a queue pairing. The detector annotates the cleared payment as a corroborator with a MEDIUM severity on the post-clearing evaluation, indicating that the queue-layer rule did not catch the duplicate at queue time but the broader 30-day pairing surfaces it now.

evaluatePolicy — HIGH. The customer's AP policy states that second invoices to the same vendor inside a 30-day cleared window require dual-approver chain. The cleared second payment ran through single-approver chain — a missing-approver violation that the rule reads directly off the cleared ledger. The chain had been intact for the cleared first payment 24 days prior, so the chain downgrade between the two cleared payments is itself the policy violation. Corroborator status elevated to HIGH because an approver-chain downgrade on a near-duplicate settled amount is a hard policy breach.

detectVendorRisk — MEDIUM. Cross-referenced the second cleared payment's banking ACH against AVS records for the same vendor. The cleared first payment was routed to a Wells Fargo business account at Lakeshore Freight Systems with verified AVS history on prior cleared payments. The cleared second payment was routed to a closely-matching — but distinct — banking ACH identifier on a different bank ledger, with no prior AVS history for this vendor at that routing destination. A banking-ACH mismatch on a cleared-payments pairing, taken with the near-duplicate settled amount and the approver-chain downgrade, gives the reviewer three independent corroborations on a single cleared payment.

Four rules, one cleared payment, one workpaper. The full pipeline — evaluatePolicy, findDuplicateInvoices, detectExpenseAnomalies, detectVendorRisk, detectThresholdGaming, detectRoundDollar, detectDuplicatePayment, detectGhostEmployee— runs on every cleared payment the customer posts; these four are the subset that tripped here. The other four returned clean on this cleared payment: detectExpenseAnomalies because the settled amount sat inside the vendor's recent cleared-vendor amount envelope, not outside it; detectThresholdGaming because a single cleared payment, not a clustered structured-sub-threshold pattern, is not the surface that rule reads; detectRoundDollar because both settled amounts carried non-zero cent components; detectGhostEmployee because the SAP master vendor and approver chain were both intact on the vendor record across the window — the approver-chain gap was on the second invoice payload, not on the master record.

Findings — what the reviewer actually saw in the workpaper

The reviewer opened the cleared-payments ledger evaluation on the second cleared payment and saw, in one screen: the settled amount ($84,200.00 to Lakeshore Freight Systems, on the closely-matching but distinct banking ACH), four rule ids (detectDuplicatePayment HIGH, findDuplicateInvoices MEDIUM, evaluatePolicy HIGH, detectVendorRisk MEDIUM), zero overrides applied, and the natural-language summary laying out the evidence chain — 30-day-window near-duplicate, banking-ACH mismatch against the cleared prior payment, approver-chain downgrade, queue-layer 14-day rule silent on the cleared-window pairing.

Four rules tripping at the same cleared payment is the cross-detector story the 8-detector pipeline surfaces by construction. A single rule could have caught the duplicate, the AVS mismatch, the approver-chain downgrade, or the cleared-window pairing — but no single rule by itself reconstructs the duplicate pairing. The pairing is the shape formed by four signals reading the same cleared payment at four fact layers, and that shape is what makes the ACH-reversal recommendation defensible on first-pass review.

Remediation — the four steps the customer took

1. 1. Route the cleared duplicate through ACH reversal. Because both invoices had already cleared, queue freeze was not in scope. The cleared first payment of $82,000 (further from its clawback-window edge) was escalated to the bank-relations team for ACH reversal inside the 60-day window; the cleared second payment of $84,200 — closer to its window-end — was escalated in parallel through a manual clawback request handled by the bank liaison. Both reversals were tracked against the flagged SAP vendor master record and against the closed banking-ACH routing on the second payment's destination bank.
2. 2. Quarantine the vendor file entry's banking-ACH routing. The vendor-file entry for Lakeshore Freight Systems was flagged as fraudulent on the SAP master record. The closely-matching banking ACH that appeared on the cleared second payment was quarantined in the AP intake layer, so any future invoices to this vendor entity with that destination banking ACH are held at intake pending a manual AVS confirmation by the AP team, with the originally-verified Wells Fargo routing preserved on the master record as the only legitimate destination.
3. 3. Attach the 4-rule workpaper to the incident report. The workpaper — settled amount, vendor master record, banking ACH identifiers, rule ids (detectDuplicatePayment, findDuplicateInvoices, evaluatePolicy, detectVendorRisk), 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. The override field was empty across all four annotations.
4. 4. Hand to internal audit for first-payment recovery. The 4-rule workpaper, the AVS mismatch trail, the approver-chain downgrade, and the cleared-payment records for both cleared payments were exported as a sealed evidence bundle and handed to internal audit. The cleared first payment of $82,000 (further from its 60-day clawback window) was routed through bank-relations ACH reversal with about a third of the principal returned; the cleared second payment of $84,200 (closer to its window-end) was routed through bank-relations ACH reversal with a partial recovery at the upper end of the published 30–45% band. Total recovery across the duplicate pair: approximately $63,150, all inside the 60-day clawback window.