Duplicate Payment Scan

Findings here are self-evidently valuable — every confirmed duplicate is recoverable cash. The discipline is in proving each finding with the actual matched rows rather than asserting "duplicate" and moving on.

The gate

The scan refuses to produce a clean workbook when:

1. Coverage cannot be proven. Every row read must end up either scanned or in the unscanned/unparsed list with a stated reason. Scanned count plus unscanned count must equal total rows read — checked explicitly, not assumed.
2. A record_id is duplicated in the source file. Row identity must be unambiguous before any finding can reliably point back to a specific transaction.

A row with an unparseable amount or date is not itself a gate failure — it is excluded from matching and listed, with its reason, on the Unscanned/Unparsed Rows tab, so the scope limitation is visible rather than silently absorbed into a clean-looking result.

Inputs

AP invoice and payment register (12+ months) — one file, one row per invoice or payment event: record_id, vendor, amount, invoice_date, invoice_no, payment_date, payment_ref. invoice_no, payment_date, and payment_ref may be blank on any given row.

Step 1 — Run the scan

python3 scripts/duplicate_payment_scan.py --register ap_register.csv --window-days 5 \
  --client "Northwind Systems Inc" \
  --out "Northwind - Duplicate Payment Scan.xlsx"

--window-days has no built-in default — state the proximity window you actually want checked (a tighter window for weekly-run AP, a wider one for monthly-batch AP) rather than relying on a number this skill would otherwise have to invent.

Step 2 — What each tier catches, and why it's ranked there

Each finding carries the matched records' row references and fields, never a bare assertion.

Deliver

Workbook tabs:

1. Risk Summary — population rows read, scanned vs. unscanned, population dollar total, and finding counts and dollars at risk by tier.
2. Findings — every match with tier, basis, vendor(s), amount, matched record references, and dollars at risk.
3. Unscanned-Unparsed Rows — every row excluded from scanning, with the reason.
4. Vendor Normalization Log — every raw vendor string mapped to its normalized form, so a Tier 3 match can be audited back to the exact spelling variants involved.

Then, in chat: the population scanned, total dollars at risk by tier, and the highest-tier findings first. State plainly if the unscanned count is material — a scan with a large unparsed population proves less than it appears to.

What to escalate

• Any Tier 1 finding — confirm with the bank or payment processor whether both payments actually cleared before assuming it's a false positive.
• A payment reference reused across invoices to different vendors, if it occurs — a reference collision this specific is unusual and worth confirming isn't a data-entry artifact versus a real misapplied payment.
• A vendor-name variant cluster (Tier 3) spanning many distinct normalized groups — may indicate the vendor master itself needs cleanup, a separate project from the duplicates found this pass.
• Concentration of findings in one AP clerk's or approver's batch, if that data is available separately — the scan does not have approver data and cannot make this link itself, but a reviewer with access to it should check.

Report each as a fact with the record references. Do not characterize intent — the scan reports pattern and evidence, never motive.

Security posture

Fully local: standard library plus openpyxl. No network calls, no uploads, no telemetry. Vendor and payment data never leave the machine.

Dependencies

pip install openpyxl

Built by Adopt AI — free to use and modify.