How VeraStream caught two overlapping vendor records inside one vendor master file — case study

Setup — what the vendor master file looked like at onboarding

The customer is an anonymized mid-market regional distributor, roughly $280M annualized revenue, running on NetSuite with a dual-approver AP chain above $50k and an annual spend volume of around $215M. Disbursements cleared weekly. The vendor master file had been onboarded cleanly for the prior nine months — every record carried a unique trade name, a unique EIN, a unique remit-to address, and a unique banking ACH routing line. The dominant indirect-spend supplier — Acme Industrial Supplies, an Illinois Inc with a three-year PO history banked with the customer's incumbent ACH intermediary — had no close synonyms anywhere else in the file.

Then, during a vendor-master import that landed in the file as a single CSV drop, a second record landed alongside the approved vendor carrying clerical drift on three fields (the legal suffix, the EIN, and the trade-name line), but converging on every other field — the trade-name root, the remit-to address, and the banking ACH were identical. The two records looked like this to a reviewer reading the file line by line:

• Record A. Acme Industrial Supplies — Illinois Inc, the approved vendor, three-year PO history, banked at a Wells Fargo ACH line verified against AVS records on prior cleared payments.
• Record B. Acme Industrial Supply Co. — a freshly-provisioned Delaware Inc with a freshly-issued EIN, a registered agent in Wilmington, no PO history. Same trade-name root, same remit-to address, same banking ACH as Record A. Distinct legal suffix, distinct state, distinct EIN — the clerical-drift signature a master-file parse gate is built to catch.

No reviewer noticed the overlap during import — the master file parsed cleanly into the live NetSuite vendor ledger with both records active. The first invoice against the new Record B queued nine days after the import committed.

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

The first rule to trip the hold was the master-file shape itself — two records carrying clerical drift on three fields but converging on every other field. The corroborators followed within seconds, each reading the queued invoice against the cleared ledger, the approver chain, and the GL curvature. The workpaper that surfaced to the reviewer carried all five annotations on a single receipt.

detectVendorRisk — HIGH. The master-file parse tripped the rule on the typosquat-within-the-file — Jaro-Winkler string similarity on the trade-name root crossed the typosquat threshold on Record A vs. Record B (different legal suffix, different EIN, but identical remit-to address and identical banking ACH). The text-layer signature plus the address-layer signature plus the banking-layer signature is the three-layer convergence detectVendorRisk reads; the rule fired on the master import itself but did not block the import — it annotated Record B as high-risk from the moment the file committed.

findDuplicateInvoices — HIGH. The queued ~$48,300 invoice against Record B carried an amount within the 5% relative-delta band of the cleared ~$47,100 against Record A — same trade-name root (Acme Industrial Supply), posted eleven days apart, against two distinct vendor record IDs drawing from the same banking ACH. The receipt signature is the duplicate ledger entry surface this rule reads; cross-referenced against the high-risk Record B annotation from detectVendorRisk, the duplicate-pair signal becomes the duplicate-vendor-graph signal the workpaper is built to surface.

detectDuplicatePayment — MEDIUM. The cleared ~$47,100 against Record A and the queued ~$48,300 against Record B re-evaluated against the cleared-payments ledger produced a duplicate-payment signature — same trade-name root, same banking ACH, near-duplicate amounts inside an 11-day window, but routed through two distinct vendor record IDs. This is the "duplicate ledger entry against a duplicate-vendor graph" posture the rule is built to flag. Corroborator status on the same receipt.

evaluatePolicy — HIGH on the dual-approver bypass. The queued ~$48,300 against Record B sat under the $50k single-approver escalation threshold and cleared under the same AP approver workflow as the cleared prior invoices against Record A — but Record B was unflagged on the master report because the master-file parse committed both records as independent vendors. The customer's dual-approver policy treats Record B as a routine single-approver queue entry; under the cross-record perspective the workpaper carries, the same approver chain signed off on the approved Acme record AND on the clerical-drift Acme record without any master-data-change review gate for the second record's onboarding.

detectExpenseAnomalies — MEDIUM. The GL curvature on the "Acme Industrial" trade root appeared at roughly 2× the historical cleared rate across the eleven-day window — because Record A and Record B are both booked as separate vendors, the line item for the "Acme" root appears twice in the cleared ledger where it historically appeared once. The rule fired on the duplicate line-item signature against the historical rate, not on a single-receipt anomaly; corroborator status on the same workpaper.

Five rules, two overlapping records in one master file, 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 (detectRoundDollar, detectThresholdGaming, detectGhostEmployee) returned clean on this receipt: the amounts carried a cents-portion, the queue entry was a single receipt and not a structured sub-threshold cluster, and the master vendor and approver chain were unchanged for the underlying approved record across the window. The pattern is a pure master-data ring, not a ring that crosses with the master-data + rights co-move the ghost-employee detector reads.

The detection fired 22 seconds after the queued ~$48,300 invoice landed in the AP queue. The hold published before the weekly disbursement run — pre-payment, in the narrow window a sample-review-only posture would have missed entirely. For prevention posture, see /solutions/vendor-master-anomalies — the master-file parse gate the customer's vendor master audit now runs on every new import.

Findings — what the reviewer actually saw in the workpaper

The reviewer opened the queued invoice's hold queue and saw, in one screen: the receipt (~$48,300 against Record B's vendor ID, approved by the same AP approver who signed the cleared prior invoices against Record A), five rule ids (detectVendorRisk HIGH on the master-file shape at import time, findDuplicateInvoices HIGH on the duplicate-pair envelope, detectDuplicatePayment MEDIUM corroborator on the duplicate-payment signature, evaluatePolicy HIGH on the dual-approver bypass against the unflagged record, detectExpenseAnomalies MEDIUM on the 2× GL curvature), zero overrides applied, and the natural-language summary laying out the two-record overlap with the same trade-name root and the same banking ACH.

The reviewer also saw the master-file overlay: the VeraStream vendor master audit view rendered the entire vendor master file as a single shape, with the detectVendorRisk annotation on Record B visible from the moment the import committed. The cleared ~$47,100 against Record A was inline alongside the queued ~$48,300 against Record B, joined by the duplicate-pair evidence and the cross-record workpaper overlay — so the reviewer saw the two-record overlap on first open rather than reconstructing it from two isolated alerts.

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 the master-file shape alone, the duplicate-pair alone, the GL curvature alone. No single rule by itself reconstructs the duplicate record inside the master file — the file shape is the master-data layer, the duplicate-pair is the ledger layer, the approver bypass is the policy layer, the GL curvature is the trend layer. The workpaper is the single artifact that makes that shape readable to an external auditor under PCAOB AS 2315, with each rule annotation tied to a specific control objective.

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 overlap produced, a sample would have seen less than 1 of 2 (under 1% sample rate over the eleven-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 22 seconds after queue — before the weekly disbursement run.

Remediation — the four steps the customer took

1. 1. Freeze the payment queue. The next weekly disbursement run was paused for any pending invoice against Record B, and a payment-queue alert was raised to the AP manager for any other pending payments to any vendor record bearing the "Acme Industrial Supply" trade root. The cleared ~$47,100 against Record A had already cleared the prior week and was outside the freeze's reach — recovery on that payment was routed through the ACH reversal pathway and the bank liaison within the 60-day clawback window.
2. 2. Deactivate the clerical-drift record. The vendor file entry for Record B (Acme Industrial Supply Co.) was flagged as fraudulent and deactivated across the live NetSuite ledger, with a quarantine note preserving the original Delaware Inc registration, the freshly-issued EIN, and the beneficiary ACH account number for the forensic trail. The approved Record A vendor entry was retained; its banking ACH routing was unchanged.
3. 3. Attach the 5-rule workpaper to the incident report. The workpaper — receipt, the two-record overlay, the rule ids (detectVendorRisk, findDuplicateInvoices, detectDuplicatePayment, evaluatePolicy, detectExpenseAnomalies), the override field empty on the queued invoice, the 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 prior invoice.
4. 4. Hand to internal audit and stand up a master-file parse gate. The 5-rule workpaper, the master-file overlay at import time, the cleared-vs-queued payment records, and the GL curvature annotation were exported as a sealed evidence bundle and handed to internal audit. The cleared ~$47,100 was treated as a recoverable loss pending ACH reversal; the queued ~$48,300 was held indefinitely pending the formal finding. Going forward, every new vendor-master import runs through the VeraStream master-file parse gate at import time so the detectVendorRisk trip happens at parse, not at invoice queue. See /solutions/vendor-master-anomalies for the master-file parse pipeline and per-tier rollout.