## TL;DR

Duplicate invoices are the most common AP leakage: the same invoice submitted twice, often with slight variations. Detect with a layered check: exact match on vendor plus invoice number plus amount, then fuzzy match on near-identical amounts and dates, then cross-entity and historical checks. Block on exact matches; review fuzzy ones. Measure prevented duplicates as the control's ROI.

## Steps

1. Check exact duplicates: same vendor, invoice number, amount, and date.
   Expected: Certain duplicates blocked.
2. Fuzzy-match on amount plus date window plus vendor.
   Expected: Near-duplicates flagged.
3. Check across subsidiaries and entities.
   Expected: Cross-entity duplicates caught.
4. Check against paid history, not just open invoices.
   Expected: Old duplicates caught.
5. Route fuzzy matches to review with the candidate pair shown.
   Expected: Fast human decisions.

## When to use

- Designing AP duplicate controls
- Double-payment investigations
- Vendor master with many similar names

## When not to use

- Duplicate lines within one invoice
- Duplicate POs
- Payment file duplicates (different layer)

## Compatibility

ERP-agnostic; implement in AP automation or as a pre-posting check.

## Variant phrasings

### duplicate invoice detection

### prevent double payment invoice

### AP duplicate check

## Root cause

Invoices arrive through multiple channels (email, portal, mail) and get submitted more than once, sometimes with retyped numbers. Without a dedicated check, each submission looks like a new payable.

## Edge cases

- Recurring invoices (monthly rent) look like duplicates; allowlist by pattern
- Credit memos netting needs separate handling
- Acquired companies bring overlapping vendor masters; dedupe vendors first

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-vgAZFd1qiEXXn19mnMpyA