Case study
How VeraStream caught a duplicate-vendor shell-corporation AP fraud ring — case study
The ring below was running against the AP queue of an anonymized mid-market home-healthcare staffing company — roughly $340M revenue, multi-state field workforce, a Sage Intacct ledger, nineteen-day window. VeraStream's 8-detector pipeline held the second invoice before it cleared. The first never got recovered through the ACH reversal pathway in time; the second was queued but never released. About $1,800 in net new audit effort — and $128,400 that did not leave the account a second time.
Outcome
$128,400 held before the second disbursement across a two-vendor shell-corp ring. One near-clone vendor record and the unbacked approver chain it rode deactivated. Five detectors fired on two payments routing to the same ultimate beneficiary bank account, producing a single workpaper the customer's external auditor accepted under PCAOB AS 2315.
Setup — what the ledger looked like three weeks before
The customer is an anonymized mid-market home-healthcare staffing operator on a Sage Intacct AP ledger, annualized spend volume of roughly $340M, paying an average of a few thousand invoices a week across a multi-state field workforce. AP ran on a single-approver chain for any payment at or below $75,000, with a dual-approver escalation above. Disbursements cleared daily. Nothing anomalous appeared in the prior sixty days' worth of approved payments: the master-data vendor file was stable, the dominant staffing vendor — Meridian Home Health Staffing Inc, a Delaware Inc operating in twelve states — had a four-year PO history and banked with the customer's incumbent ACH intermediary, and the spend curve was predictable.
Then, over a nineteen-day window in July and August 2026, a second payee was provisioned in master-data and began receiving invoices routed to the same beneficiary bank account as the approved vendor:
- Day 1. A new vendor record was created: Meridian Home Health Staffing LLC, a Wyoming LLC with a freshly filed EIN, a registered agent in Cheyenne, and a fresh Wells Fargo ACH routing line — textually distinct from the approved vendor on every name-stratum but with the same ultimate beneficiary bank account number as the approved Meridian Inc (the convergence the detector was built to catch).
- Day 6. First invoice queued to Meridian Home Health Staffing LLC, $64,900.00 exactly — just under the $75,000 single-approver threshold. Cleared the next morning on the daily disbursement run under the same AP approver who had signed off on the legitimate Meridian Inc PO run all quarter.
- Day 14. Second invoice queued to the same shell Meridian Home Health Staffing LLC, $63,500.00 — again just under the $75,000 threshold, inside a 5%-relative-delta band of the cleared $64,900. Queued for the next-day disbursement run. Held for review by the eight-detector pipeline 18 minutes after queue.
- Day 19. ACH reversal pathway initiated on the cleared $64,900 from the prior cycle. The customer's bank liaison flagged the routing-line convergence with the approved vendor's banking detail, supporting the ring hypothesis internally — but the workpaper was already the authoritative artifact.
Detection — what tripped, in order, and on what evidence
The first rule to trip the hold was the vendor-graph signature — the near-clone registration with bank-ACH convergence. The corroborators followed within seconds, each reading the same payment at a different fact layer: the duplicate-pair evidence, the threshold-structuring pattern, the segregation-of- duties gap. The workpaper that surfaced to the reviewer carried all five annotations on a single receipt.
detectVendorRisk — HIGH. The new vendor Meridian Home Health Staffing LLC was registered twenty days after the approved vendor Meridian Home Health Staffing Inc with a flipped legal suffix, a flipped incorporation state, a flipped registered agent, and a different intermediary bank — but the beneficiary ACH account number was identical. Textual-similarity score alone would not have caught this; bank-routing convergence did. detectVendorRisk reads both layers and fires when the textual similarity is below the typosquat threshold but the bank-routing convergence crosses it.
findDuplicateInvoices — HIGH. The queued $63,500 to the shell Meridian LLC was a near-duplicate of the cleared $64,900 invoice that had cleared eight days earlier — amount within 2.2% relative delta, same memo template, same purpose code, same payee trade-name root, same beneficiary bank. New-vendor first commit inside 14 days of master-data onboarding, duplicate-amount envelope inside 14 days of a cleared invoice to the same root. Two anomalies reading the same payment on two different fact layers.
detectDuplicatePayment — would have been HIGH had the second $63,500 cleared after the first $64,900. Without the pre-payment hold, this is the rule that catches the duplicate disbursement post-clearance; it is also part of the same workpaper envelope because the duplicate-pair evidence is reachable. Under the eight-detector pipeline the second never got the chance to clear, so the rule fires on the queued leg of what would have been the duplicate — pre-payment evidence of the structuring pattern.
detectThresholdGaming — MEDIUM. Both invoices sat just under the $75,000 single-approver escalation threshold — $64,900 and $63,500 — and were both approved by the same AP approver whose threshold-driven workflow lets invoices at this amount clear without a second sign-off. A two-invoice cluster under $75,000 inside a fourteen-day window is the textbook structuring pattern. The rule is the co-conspirator with the duplicate-pair evidence: structuring alone reads as behavior, structuring plus duplicate reads as intent.
evaluatePolicy — HIGH on segregation of duties and dual-vendor approval. The same approver chain that had signed off on the legitimate Meridian Inc PO run all quarter was the only chain that signed off on the new Meridian LLC — there was no second approver on either shell-corp invoice, and no master-data-change review gate existed for a near-clone vendor registration. Both gaps were visible in the approver-rights trail attached to the workpaper. For the broader detection ecosystem, see ghost-employee prevention — many of the same approver-rights signals carry across to vendor-graph rings, because both attack the same fact layer.
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 (detectExpenseAnomalies, detectRoundDollar, detectGhostEmployee) returned clean: this ring had no expense-category curve excursion, no round-cent template divergence worth flagging (the amounts had a cents-portion), and no same-week master-data + approver-rights co-move — it was a pure vendor-graph ring, not a ghost-employee ring, and the detectors are designed to read that distinction rather than smudge it.
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,500.00 to Meridian Home Health Staffing LLC, approved by the same AP approver who signed the cleared $64,900), five rule ids (detectVendorRisk HIGH on the bank-ACH convergence, findDuplicateInvoices HIGH on the duplicate-pair envelope, detectDuplicatePayment conditional on the cleared pair, detectThresholdGaming MEDIUM on the $75k structuring pattern, evaluatePolicy HIGH on the segregation gap), zero overrides applied, and the natural-language summary laying out the two-vendor convergence with the same ultimate beneficiary bank account. The cleared $64,900 to the same bank was inline alongside the queued $63,500, joined by the duplicate-pair evidence — so the reviewer could see the ring on first open.
The reviewer also saw the population math. A legacy sample review would have pulled roughly 25 to 60 items a quarter — and of the two invoices this ring posted, a sample would have seen 0 of 2 (under 1% sample rate over the nineteen-day window across a multi-thousand-invoice weekly volume). Under VeraStream's 95% pre-payment coverage, both invoices were evaluated on the day the second one queued, and the hold published 18 minutes after queue — before the next-day disbursement run.
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 bank-ACH convergence alone, the duplicate amount alone, the structuring pattern alone, the segregation gap alone. 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 — and the workpaper is the single artifact that makes that shape readable to an external auditor. For the broader control-set the customer's auditor mapped the evidence against, see regulatory coverage of the eight detectors — the same five-rule pattern maps cleanly onto AS 2315 evidence expectations, with each rule annotation tied to a specific control objective.
Remediation — the four steps the customer took
- 1. Freeze the payment queue. The next-day disbursement run was paused for both the shell Meridian LLC payee and the approved Meridian Inc payee, pending the segregation review. A payment-queue alert was raised to the AP manager for any other pending payments to any vendor record bearing the "Meridian Home Health Staffing" trade-name root. The cleared $64,900 had been routed to the same beneficiary bank as the queued $63,500, so recovery on that payment was routed through the ACH reversal pathway and the bank liaison.
- 2. Revoke the unbacked approver chain. The AP approver's sign-off authority on newly-onboarded vendor records was suspended pending the segregation review. The rights grant was traced back through the audit log to the change request that had provisioned the new-vendor onboarding workflow, which produced the second piece of the workpaper — the rights-change trail and the master-data change trail as a paired evidence set.
- 3. Deactivate the master-data record. The vendor file entry for Meridian Home Health Staffing LLC was flagged as fraudulent and deactivated across the live ERP, with a quarantine note preserving the original Wyoming LLC registration, EIN, and beneficiary ACH account number for the forensic trail. The approved Meridian Inc vendor record was retained; its bank-ACH routing was unchanged.
- 4. Hand to internal audit and external counsel. The five-rule workpaper, the master-data change trail, the rights-grant change trail, the bank-ACH convergence evidence, and the queued + cleared payment records were exported as a sealed evidence bundle and handed to internal audit and external counsel. The cleared $64,900 was treated as a recoverable loss pending ACH reversal; the queued $63,500 was held indefinitely pending the formal finding.
Net effect
$128,400 — the queued $63,500 plus the cleared-but-recoverable $64,900 — was prevented from completing as further loss to the shell-corp ring. The ring was identified and fully annotated before the second invoice cleared. Run the same 8-detector pipeline against your own ledger at /audit, or browse /pricing to launch continuous monitoring against your live ERP.
Frequently asked
Common questions about this duplicate-vendor case study
Plain HTML answers — no JavaScript required to read.
What is a duplicate-vendor shell-corporation scheme?
A fraudulent payee is registered in master-data as a near-clone of an approved vendor — same trade name, different legal suffix (Inc vs LLC vs LLP), different state of incorporation, but wired to the same ultimate beneficiary bank account or a money-mule pass-through. On its own, each vendor record looks legitimate. Together they form a duplicate-vendor shell ring: two payee IDs that look unrelated to a reviewer but route disbursements to the same real-world destination — the textbook pattern where the EINs differ, the trade names differ, but the bank ACH converges. VeraStream's detectVendorRisk and findDuplicateInvoices detectors read the same payment at the vendor-graph layer and the ledger layer respectively, and that is what surfaces the convergence.
Why is duplicate-vendor shell-corp fraud harder to spot than typosquatting?
A typosquat ("Beacon Strategy LLC" vs approved "Beacon Strategies LLP") trips detectVendorRisk on Jaro-Winkler string similarity alone — the legal suffix is enough of a tell. A shell-corp variant is deliberately distinct on every textual surface: the legal suffix flips (Inc → LLC), the state flips (Delaware → Wyoming), the registered agent flips, and the EIN is fresh — but the bank ACH resolution converges. A reviewer reading the vendor file sees two unrelated vendors; only a detector that also reads the bank-routing graph and the AP ledger together can see the second payee is money flowing to the same destination. That is what findDuplicateInvoices and detectVendorRisk working in tandem give you that string-similarity alone does not.
How did five detectors fire on a single shell-corp ring?
detectVendorRisk tripped first on the dissimilar-but-convergent vendor shape: same trade root, different legal suffix, different state, same banking intermediary. findDuplicateInvoices fired on the second $63,500 against the cleared $64,900 — amounts inside the 5%-delta band on a 14-day window. detectDuplicatePayment would have been HIGH had the first cleared the second; under the eight-detector pipeline the second was held first, so the rule fired on the queued leg of what would have been the duplicate. detectThresholdGaming tripped because both invoices sat just under the $75,000 single-approver escalation threshold — a textbook structuring pattern. evaluatePolicy fired on segregation of duties: the same approver chain that approved the legitimate Meridian Inc invoices also approved the shell Meridian LLC invoices. Five rules, two payee IDs, one underlying beneficiary.
What does the workpaper look like for a duplicate-vendor shell-corp ring?
Each trip carries the same receipt shape: the original transaction (the queued or cleared invoice flagged), the rule that tripped (the detector id from the eight), and the override field (empty when held for review). When five trips share a single payment, the workpaper annotates that payment with all five rule ids as the evidence set — so an auditor under PCAOB AS 2315 reads one screen, sees two vendor records, one bank ACH convergence, one approver chain weakness, and a just-under-threshold structuring pattern, and understands the ring on first pass rather than reconstructing it from five isolated alerts. The workpaper also links the cleared $64,900 to the queued $63,500 as the duplicate-pair evidence the recovery pathway needs.
Run the eight on your own ledger today
Drop a CSV at /audit and watch the eight detectors evaluate it in under 90 seconds in the browser. Browse /pricing to launch continuous monitoring against your live ERP.