One analytical test is not enough for a full duplicate payment assessment. Here’s why.

One rule will never cover it

Most teams start with a simple check: same vendor, same invoice number, same amount. That finds exact duplicates. It misses almost everything else.

Easy to catch

Exact duplicates

Invoice INV-1042 for $12,500 paid twice under the same number. Your ERP often blocks this already.

Where money leaks

Near-duplicates

Same bill as INV-1042 and INV1042. Same amount two weeks later with a new number. Same bank account under two vendor codes. One rule won’t see these.

Duplicate risk is not one problem. It is a set of business scenarios. Each needs its own test—or you leave gaps.

Scenarios that cause duplicate payments

Start here—not with SQL. These patterns show up again and again in AP data.

  1. 01

    Same invoice number — two posts share one invoice ID.

  2. 02

    Same vendor, different invoice format — 1042, INV-1042, and INV1042 are often the same bill.

  3. 03

    Same amount within a time window — $47,850 to the same vendor twice in 14 days, with different invoice numbers.

  4. 04

    Different vendor, same bank account — two vendor masters, one bank account, cash leaves twice.

  5. 05

    Credit notes and reversals — a credit is raised, then the original invoice is paid again anyway.

  6. 06

    Partial payments — splits and short-pays make “same amount” checks look clean when they are not.

  7. 07

    Partial invoices against a PO — 60% then 40% is normal, until the full amount (or a partial) is billed again.

Translate scenarios into analytics

Each scenario becomes one or more tests. Together, they give you coverage. Alone, none of them is enough.

Matching rules

Clear yes/no checks for high-confidence cases—exact invoice + vendor + amount, or the same bank account across two vendor IDs. Few hits. High confidence.

Similarity scoring

Score how close two invoice numbers or vendor names are. Example: INV-1042 and INV1O42 should score high, not fail a string match.

Thresholds

Define “close enough”: amount within $1, dates within 30 days, similarity above 85%. Set these from your data—not from a generic template.

Exceptions to exclude

Rent, utilities, and approved installments repeat on purpose. Exclude them, or your queue fills with noise.

Risk scoring

Rank findings so analysts review the strongest cases first: exact matches, then strong near-matches, then weaker signals.

Common mistakes

  • Looking only for exact matches You catch what the ERP already blocks—and miss the leakage.
  • Ignoring master data quality Duplicate vendors and messy invoice numbers break every test you write.
  • Using one rule for every business A company with 40 vendors is not the same as one with 4,000. Thresholds must fit the process.
  • Producing too many false positives If the queue is full of noise, people stop trusting the analytics.
Key takeaway

Good duplicate payment analytics combine business understanding, clean data, and several detection techniques—not a single SQL query.

How foretale.ai helps

Building this by hand takes time: map scenarios, write tests, tune thresholds, and cut false positives.

foretale.ai turns those scenarios into analytics in minutes. It understands your data, creates many tests at once—matching rules, similarity checks, windows, exclusions, and risk ranking—and runs them with clear evidence for every finding.

You test across the full range of duplicate payment scenarios—not only the exact-match check most teams start with.

See it in action

See how Foretale designs and executes these analytics automatically.

Request a demo