## TL;DR

Invoice numbers are only unique per vendor: two vendors can both issue invoice 1001. Dedupe keys must always be composite (vendor plus invoice number), never the number alone. Normalize vendor identity first (master vendor ID, not name strings) so the composite key is stable.

## Steps

1. Define the dedupe key as vendor master ID plus normalized invoice number.
   Expected: A correct key.
2. Normalize invoice numbers: strip spaces, leading zeros, case.
   Expected: Stable comparison.
3. Never dedupe on invoice number alone.
   Expected: No cross-vendor false positives.
4. Test the key against historical duplicates.
   Expected: Validation of the design.
5. Monitor false-positive rate in review.
   Expected: Tuning signal.

## When to use

- Designing dedupe keys
- Multi-vendor AP
- Vendor master with ID stability

## When not to use

- Same-vendor duplicate review
- Line-item dedupe
- Payment duplicates

## Compatibility

ERP-agnostic.

## Variant phrasings

### invoice number collision vendors

### dedupe key vendor invoice number

### same invoice number different vendor

## Root cause

Invoice numbering is per-vendor sequential, so collisions across vendors are guaranteed at scale. A number-only key creates false duplicates constantly.

## Edge cases

- Vendor merges change master IDs; keep a mapping history
- Some vendors restart numbering yearly; include the year
- Acquired vendor records need ID remapping

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oLoqWngBHRgYY0RcTVQggA