Duplicate Payment & Credit Recovery Ledger
Paid Twice, Credited Never — The Full Evidence Chain

01Executive Summary

Five detection passes hunted the same obligation paid twice: same-vendor amount/date collisions, cross-vendor collisions (re-onboarded supplier records), cross-subsidiary collisions, bills carrying more than one payment, and vendor-master duplicate records. The verdict: zero confirmed duplicate payments in $3.40M of vendor billing. Thirteen candidate pairs matched on vendor + amount + date proximity — every one dissolved under the evidence chain: each bill traces to its own purchase order with its own item receipt. What looked like duplicates is a business that orders identical replenishment baskets on rhythm (the currency axis collapses by configuration: this is a single-currency USD instance, verified).

The hunt still produced two things worth money and attention. First, a $33,700 near-miss: bill VB05 (Generation N) briefly carried two $33,700 payments — the original was voided the same day the replacement posted. The control worked; the evidence chain (kept in §03) shows exactly what a real duplicate will look like when one eventually survives. Second, the credit-side trace found a live recovery ledger of $369.88: a supplier credit agreed 54 days ago and never issued, a credit received but never applied to any bill, an unapplied credit tied to the Vol. III anomaly, and a paid vendor prepayment awaiting offset. Small dollars — but each is a process leak, and one of them connects directly to the VB397 investigation.

02Duplicate Hunt: Five Passes, Full Results

Why the 13 same-vendor pairs cleared

Every candidate pair traces to two distinct purchase orders, each with its own item receipt — the goods arrived twice because they were ordered twice, deliberately. The clearest proof: Health & Beauty Supplies shows four $310.00 pairs spread across two years (Sep 2024, Mar 2025, Oct 2025, Apr 2026). Those are two different standing baskets — a body-care basket (PO791 lineage) and a cosmetics basket (PO985 lineage) — that both happen to total $310.00 and re-order on the same ~6-month rhythm. Same-amount collision, entirely different goods.

03The Near-Miss: Anatomy of a Caught Double Payment

04Credits, Returns & Rebates: The Full Trace

Every credit-side instrument in the account, traced end-to-end: vendor return authorizations (returns made), bill credits (credits agreed), vendor prepayments, and refund checks. No rebate program exists in this account (no rebate items, accruals, or credit memos referencing rebates) — stated as a scope boundary, not silently skipped.

05The Recoverable Ledger

06Recommendations

1. Work the four-line ledger this week. Apply the two idle credits ($119.96 combined — minutes of AP work), demand the VRMA21 credit ($149.95, 54 days overdue), and offset or recover the $99.97 prepayment. Total: $369.88.
2. Run a single consolidated Generation N review. Fold in the open VB397 claim ($2,984.52), this ledger, the off-PO channel ($373K exposure, Vol. III), and the near-miss. One meeting, one vendor, every exhibit already evidenced across Vols. III–IV.
3. Install the five duplicate detectors (§08) as monthly controls. Today they return zero confirmed duplicates — that is the baseline. Q4 (multi-payment) is the one that catches a VB05-style event if the void step is ever missed.
4. Add a credit-aging control. The gap this report exposes is not duplicates — it is credit latency: nothing in the current process notices a Pending Credit at 54 days or an unapplied credit at 41 days. Q6 ages every open credit instrument; anything > 30 days goes on the AP huddle agenda.
5. Retire the 18 inactive "Tax Agency" vendor shells superseded by the Department-of-Revenue records — zero transactions, pure file hygiene, and it keeps P5's re-onboarding detector signal clean.
6. Do not buy a recovery-audit service on this evidence. Two years, $3.4M billed, zero surviving duplicates: the classic contingency-fee recovery pitch has nothing to find here. The leaks are credit-side and vendor-specific — fix the process, keep the detectors.

07Methodology, Assumptions & Data Quality

Method

Duplicates: five passes over all 1,017 VendBills — (P1) same vendor + |Δamount| < $0.005 + ≤5 days; (P2) different vendors, same amount, ≤3 days, ≥$500; (P3) same vendor + amount, different subsidiary (via mainline transactionline.subsidiary), ≤10 days; (P4) bills with >1 non-void payment or applied total > bill total (payment links via transactionline.createdfrom on VendPymt lines); (P5) vendor-master scan on normalized name/email. Candidates cleared only by evidence: distinct POs with distinct item receipts and line-level differences — never by assumption. Credits: full census of VendAuth, VendCred, VPrep, Check; each traced from authorization → credit issuance → application lines → residual, with NetSuite display statuses decoded (VendAuth: A=Pending Approval, B=Pending Return, F=Pending Credit, G=Credited).

Assumptions & boundaries

(1) Single currency (USD, verified) — the cross-currency duplicate axis is structurally empty in this account; the P1–P3 queries carry the FX variant in comments for multi-currency instances. (2) No rebate program exists in the account (no rebate items/accruals found) — "rebates earned" is out of scope by absence, stated rather than skipped. (3) Amount-tolerance $0.005 and date windows (5/3/10 days) are the detection envelope; widening them found no additional candidates at 2× windows. (4) The Broyhill PO1141/PO1142 identical-basket pattern cleared on separate receipts but is flagged to confirm the ordering cadence with purchasing — near-identical POs a day apart is also what a re-keyed PO looks like. (5) One SuiteQL artifact handled: payment-application joins fan out across payment lines; per-payment dedup (COUNT DISTINCT payment id, MAX not SUM per doc) prevents false "overpaid" hits — the naive join showed VB01 "paid $341K" until deduped to its single payment.

Data quality

(i) A bill credit's tranid is a 16-digit card-formatted number — same string as VB397's memo; both belong to the same case file and the number should be redacted from both records. (ii) The voided payment retains its full application trail — good void hygiene worth keeping. (iii) 18 inactive Tax Agency vendor shells (see Rec. 05). (iv) All credit instruments cluster in Jul–Aug 2026, suggesting the returns process is newly in use — early enough to fix its latency before volume grows.

08Appendix: Source Queries (Standing Detectors)

SELECT b1.id, b1.tranid, b2.id, b2.tranid, v.companyname,
       TO_CHAR(b1.trandate,'YYYY-MM-DD') AS date1, TO_CHAR(b2.trandate,'YYYY-MM-DD') AS date2,
       ROUND(ABS(b1.foreigntotal),2) AS amount, b1.status, b2.status
FROM transaction b1
JOIN transaction b2 ON b2.entity = b1.entity AND b2.id > b1.id
  AND ABS(b2.foreigntotal - b1.foreigntotal) < 0.005
  AND ABS(b2.trandate - b1.trandate) <= 5
JOIN vendor v ON v.id = b1.entity
WHERE b1.type = 'VendBill' AND b2.type = 'VendBill' AND ABS(b1.foreigntotal) >= 100
ORDER BY ABS(b1.foreigntotal) DESC
-- Clear candidates ONLY via the PO chain: each bill's createdfrom → distinct PO → own ItemRcpt.
-- Multi-currency instances: compare on base-currency totals or join currency and match per-pair.

-- P2: same amount, different vendor records, tight date window (re-onboarded supplier signature)
SELECT b1.id, v1.companyname, b2.id, v2.companyname,
       TO_CHAR(b1.trandate,'YYYY-MM-DD') AS d1, TO_CHAR(b2.trandate,'YYYY-MM-DD') AS d2,
       ROUND(ABS(b1.foreigntotal),2) AS amount
FROM transaction b1
JOIN transaction b2 ON b2.entity <> b1.entity AND b2.id > b1.id
  AND ABS(b2.foreigntotal - b1.foreigntotal) < 0.005 AND ABS(b2.trandate - b1.trandate) <= 3
JOIN vendor v1 ON v1.id = b1.entity
JOIN vendor v2 ON v2.id = b2.entity
WHERE b1.type = 'VendBill' AND b2.type = 'VendBill' AND ABS(b1.foreigntotal) >= 500

-- P5: vendor-master audit — names, emails, created dates, bill counts; eyeball near-matches
SELECT v.id, v.entityid, v.companyname, v.email, v.isinactive,
       (SELECT COUNT(*) FROM transaction t WHERE t.entity = v.id AND t.type='VendBill') AS bills
FROM vendor v ORDER BY UPPER(COALESCE(v.companyname, v.entityid))

SELECT v.companyname, b1.id, tl1.subsidiary AS sub1, b2.id, tl2.subsidiary AS sub2,
       ROUND(ABS(b1.foreigntotal),2) AS amount, ABS(b2.trandate - b1.trandate) AS days_apart
FROM transaction b1
JOIN transactionline tl1 ON tl1.transaction = b1.id AND tl1.mainline='T'
JOIN transaction b2 ON b2.entity = b1.entity AND b2.id > b1.id
  AND ABS(b2.foreigntotal - b1.foreigntotal) < 0.005 AND ABS(b2.trandate - b1.trandate) <= 10
JOIN transactionline tl2 ON tl2.transaction = b2.id AND tl2.mainline='T'
  AND tl2.subsidiary <> tl1.subsidiary
JOIN vendor v ON v.id = b1.entity
WHERE b1.type='VendBill' AND b2.type='VendBill'
-- transaction.subsidiary is NOT_EXPOSED in this account; the mainline line carries it.

SELECT b.id, b.tranid, v.companyname, ROUND(ABS(b.foreigntotal),2) AS bill_total,
       COUNT(DISTINCT p.id) AS payment_count
FROM transaction b
JOIN vendor v ON v.id = b.entity
JOIN transactionline ptl ON ptl.createdfrom = b.id
JOIN transaction p ON p.id = ptl.transaction AND p.type = 'VendPymt' AND p.status <> 'V'
WHERE b.type = 'VendBill'
GROUP BY b.id, b.tranid, v.companyname, b.foreigntotal
HAVING COUNT(DISTINCT p.id) > 1
-- CRITICAL: count DISTINCT payment ids — the line join fans out and a naive SUM of line
-- amounts reports fictitious overpayment. Exclude voided (status 'V') payments, but ALSO run
-- WITH voids included to find near-misses like VB05 (two payments, one voided).

-- Census: every credit-side instrument and its NS status
SELECT t.id, t.tranid, t.type, t.status, BUILTIN.DF(t.status) AS status_name,
       TO_CHAR(t.trandate,'YYYY-MM-DD') AS dt, v.companyname,
       ROUND(t.foreigntotal,2) AS total
FROM transaction t
LEFT JOIN vendor v ON v.id = t.entity
WHERE t.type IN ('VendAuth','VendCred','VPrep','Check')
ORDER BY t.trandate
-- Application trace per credit: which bills (if any) it reduces
SELECT c.id, c.tranid, ROUND(c.foreigntotal,2) AS credit_total,
       ROUND(SUM(CASE WHEN app.type='VendBill' THEN ABS(ctl.foreignamount) ELSE 0 END),2) AS applied
FROM transaction c
LEFT JOIN transactionline ctl ON ctl.transaction = c.id AND ctl.createdfrom IS NOT NULL
LEFT JOIN transaction app ON app.id = ctl.createdfrom
WHERE c.type = 'VendCred'
GROUP BY c.id, c.tranid, c.foreigntotal
-- applied = 0 on an open credit → "received, never applied" ledger item.
-- VendAuth status letters here: A=Pending Approval, B=Pending Return, F=Pending Credit, G=Credited.

SELECT t.type, t.tranid, v.companyname, ROUND(ABS(t.foreigntotal),2) AS amount,
       BUILTIN.DF(t.status) AS status_name,
       TRUNC(SYSDATE) - TRUNC(t.trandate) AS age_days
FROM transaction t
LEFT JOIN vendor v ON v.id = t.entity
WHERE (t.type = 'VendAuth' AND t.status IN ('A','B','F'))   -- stuck before credit
   OR (t.type = 'VendCred' AND t.status = 'Y')              -- credit open/unapplied
   OR (t.type = 'VPrep'    AND t.status = 'B')              -- prepayment paid, not offset
ORDER BY age_days DESC
-- Anything over 30 days = AP huddle agenda. Current hits: VRMA21 (54d), VRMA20 credit (41d),
-- credit ···2809 (2d), VPrep 354 (2d), VRMA22 (24d), VRMA23 (16d).