Six decisions, before your next payment run.
Every line below is a move, not a finding: what to do, by when, and what it protects. The invoices behind each one sit underneath it as evidence — the full ledger lives in the Financial Review. Work top to bottom and the exposure closes itself.
Ninety days, in three moves
The same vendor was paid the same amount against the same invoice more than once. Hold or reverse these before the next payment run, and confirm each with AP.
300 of 300 duplicate pairs share pairs posted exactly 3 day(s) apart — a scheduled run posting the same batch twice. Fixing that stops the next batch instead of cleaning up after it.
One vendor carried under several spellings splits its spend across records, so every report understates it. Merge them into one canonical record after confirming they are the same entity.
add an idempotency key to whatever posts on the 3-day cycle, so the same batch cannot post twice (300 pairs traced to this cadence).
require vendor + amount + invoice number to be unique against the trailing 90 days before any payment is released, so a duplicate is caught before it leaves the account, not after.
enforce one canonical vendor record and block near-duplicate names at creation, so spend stops fragmenting across spellings and reporting stays true.
Business risks
300 same-vendor, same-amount payment pairs totaling $421,870 at risk were flagged close together in time -- if both halves of a pair are genuine payments, this is a duplicate payment risk. Itemized in Critical Findings; verify with AP before your next payment run.