How VeraStream caught a ghost-employee AP fraud ring — case study

Setup — what the ledger looked like two weeks before

The customer is an anonymized mid-market SaaS company on a NetSuite AP ledger, annualized spend volume of roughly $180M, paying an average of a few hundred invoices a week. AP ran on a dual-approver chain for any payment above $25,000, with a $50,000 escalation threshold. Disbursements cleared twice a week — Mondays and Thursdays. Nothing anomalous appeared in the prior thirty days' worth of approved payments: the master-data vendor file was stable, the approver chain had not changed, the disbursement cadence was unchanged.

Then, over an eleven-day window in late July 2026, two coordinated changes landed in the master-data + rights layer:

• Day 1. A new vendor record was created: Beacon Strategy LLC, a Delaware LLC with a freshly provisioned banking ACH detail, an EIN filed three days earlier, and no prior invoice history.
• Day 4. A new approver, M. Tarrington, was granted sign-off rights on payments to Beacon Strategy LLC — under the $50,000 single-approver authorization tier.
• Day 8. First invoice queued to Beacon Strategy LLC, $48,500.00 exactly. M. Tarrington self-approved. Payment cleared on the Day 10 disbursement run.
• Day 11. Second invoice queued to Beacon Strategy LLC, $46,200.00. M. Tarrington self-approved. Queued for the Day 14 disbursement run. Held for review by the eight-detector pipeline 41 minutes after queue.

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

The first rule to trip the hold was the master ring signature. 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.

detectGhostEmployee — HIGH. The Day 1 vendor record and the Day 4 approver rights-grant landed inside the detection window (eight days, well under the same-week threshold for the master-data + rights co-move signature). Payment to the new vendor was being approved by the same new approver. The receipt was the second $46,200 invoice. The override field was empty — payment was held, not released.

detectVendorRisk — MEDIUM. The new vendor Beacon Strategy LLC was a Jaro-Winkler typosquat of the customer's already-approved vendor Beacon Strategies LLP — same trade name root, different legal suffix, payable to a different banking ACH. The approved vendor had an active PO history spanning four years; the new vendor had no PO history. The new vendor's first commit to the queue was within 11 days of master-data onboarding, the textbook payoff window.

detectDuplicatePayment — would have been HIGH had the first $48,500 cleared the second $46,200. The amounts are near-identical (under 5% relative delta) inside the 14-day short-window. The first payment cleared on Day 10; on Day 11 the second invoice queued. Without the pre-payment hold, this rule becomes the surface that catches the second leg of a ring. Under the eight-detector pipeline, the second never got the chance to clear, so the rule fires on the second invoice's queue entry against the cleared first invoice's record — pre-payment evidence of what would have been the duplicate disbursement.

evaluatePolicy — HIGH on segregation of duties. M. Tarrington self-approved both payments — neither had a second approver on the chain, even though both were above the $25,000 dual-approver threshold. The new approver's rights had been granted before the segregation check window flagged them. The approver-chain evidence is in the workpaper.

detectRoundDollar — MEDIUM on the round-cent pattern. Both invoices had no-cent amounts — $48,500.00 and $46,200.00 — and used the same memo template the customer's AP system had migrated off two quarters earlier. The template divergence was a soft signal that the invoices had been issued from a clone of the legacy AP template rather than from the live workflow.

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 (eval-on the same payment returned clean — exposure-curve not matched, expense-anomaly curve not matched, threshold-gaming curve not matched, because the second $46,200 sat alone, not in a cluster structured just below the threshold).

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 ($46,200.00 to Beacon Strategy LLC, self-approved by M. Tarrington), five rule ids (detectGhostEmployee HIGH, detectVendorRisk MEDIUM, detectDuplicatePayment conditional, evaluatePolicy HIGH, detectRoundDollar MEDIUM), zero overrides applied, and the natural-language summary laying out the evidence chain — same-week vendor + approver co-move, typosquat against an approved vendor, near-duplicate with the cleared prior invoice, segregation gap, round-cent template divergence.

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 eleven-day window). Under VeraStream's 95% pre-payment coverage, both invoices were evaluated on the day the second one queued, and the hold published 41 minutes after queue — before the Day 14 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 typosquat, the duplicate, the segregation gap, the round-cent template. 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 the customer's external auditor accepted on first pass as the basis for deactivating the master-data record and the rights grant, and for handing the matter to internal audit and external counsel.

Remediation — the four steps the customer took

1. 1. Freeze the payment queue. The Day 14 disbursement run was paused for the Beacon Strategy LLC payee, and a payment-queue alert was raised to the AP manager for any other pending payments to that vendor. The first $48,500 had already cleared on Day 10 and was outside the freeze's reach — recovery on that payment was routed through the ACH reversal pathway and bank liaison.
2. 2. Revoke the new approver. M. Tarrington's sign-off rights were revoked immediately on the Beacon Strategy LLC vendor and paused across all newly-onboarded vendors within the prior 30-day window. The rights grant was traced back through the audit log to the change request that provisioned it, which produced the second piece of the workpaper — the rights-change trail as evidence.
3. 3. Deactivate the master-data record. The vendor file entry for Beacon Strategy LLC was flagged as fraudulent and deactivated across the live ERP, with a quarantine note preserving the original banking ACH detail and EIN for the forensic trail. No further invoices to this entity were accepted at the queue.
4. 4. Hand to internal audit and external counsel. The five-rule workpaper, the master-data change trail, the rights-grant change trail, and the queued + cleared payment records were exported as a sealed evidence bundle and handed to internal audit and external counsel. The cleared $48,500 was treated as a recoverable loss pending ACH reversal; the queued $46,200 was held indefinitely pending the formal finding.