Skills / Audit and assurance

Duplicate Payment Scan

Duplicate payments hide behind the exact things that make AP data hard to scan by eye: a vendor name entered three different ways across three different years, a round-number invoice reposted after a system migration, a payment reference reused across a batch for convenience. None of it looks wrong in isolation. It only shows up as a pattern across the full population, which is precisely the kind of comparison a spreadsheet filter and a tired set of eyes are bad at and a full-population scan is built for.

What it does

This skill scans the complete AP invoice and payment register, twelve months or more, for duplicate-payment candidates across four risk-ranked tiers: an exact invoice number duplicated for the same vendor and amount, the same vendor and amount close in time under different invoice numbers, a same-amount close-in-time match where the vendor name is a normalized variant of another, and a payment reference reused across different invoice numbers. Every finding comes back with the specific matched records behind it, not a bare assertion, so AP can triage by tier and evidence instead of working through a flat, unordered pile.

The one rule it can't skip

It never declares a candidate a confirmed duplicate. Even a Tier 1 match, the strongest tier, is strong evidence, not proof; a company can legitimately receive two identical invoices for two separate shipments. This skill surfaces the pattern, ranks it by tier, and attaches the matched row references; a person with the actual invoice and payment detail in front of them makes the final call, the same way the full-population anomaly scan this pattern is built from, the journal-entry-anomaly-scan skill applied to the GL, never adjudicates an anomaly itself either.

How the matching actually runs

Vendor names are normalized (legal suffixes and common formatting stripped) into a consistent form before any comparison runs, and every normalization is logged so a Tier 3 match can be audited back to the exact spelling variants involved. Tier 1 looks for an exact vendor, amount, and invoice number duplicated outright. Tier 2 looks for the same vendor and amount with dates inside a proximity window you supply explicitly, since there's no built-in default: a tighter window suits AP that runs weekly, a wider one suits monthly-batch AP. Tier 3 applies that same window and amount match but allows the vendor name to be a normalized variant rather than identical. Tier 4 looks for one payment reference reused across different invoice numbers, regardless of amount. Every row read is accounted for: it's either scanned or listed, with a reason, on its own Unscanned/Unparsed Rows tab, and the two counts are checked against the total.

What it won't do

It won't resolve a candidate's status for you: confirmed duplicate, two genuinely separate invoices, or an already-netted credit memo all require someone to look at the underlying document. It won't assume a proximity window on your behalf; stating how close in time counts as suspicious is a decision this skill asks you to make rather than guesses. And it won't take any action on a vendor's account or adjust the AP subledger; the output is a tiered findings list for AP and the Controller to work from.

Inputs and output

InputsAP invoice and payment registers covering twelve months or more, and the date-proximity window to apply
OutputA risk-ranked list of duplicate candidates across four tiers, with the matched records and a vendor-name normalization log behind each finding
Who it's forControllers and AP teams running a periodic duplicate-payment review, and whoever follows up with vendors once a finding is confirmed

Adopt's agents run this scan against the AP population you already keep, tier every finding by evidence with the matched rows attached, and leave the vendor conversation and the recovery decision to AP. Start free with Fino, or book a pilot to run it against your own trailing twelve months.