invoice number reuse across different vendors
Handles invoice numbers that collide across vendors in duplicate detection. Use when designing dedupe keys. Not for same-vendor duplicates.
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
- Define the dedupe key as vendor master ID plus normalized invoice number.
Expected: A correct key.
- Normalize invoice numbers: strip spaces, leading zeros, case.
Expected: Stable comparison.
- Never dedupe on invoice number alone.
Expected: No cross-vendor false positives.
- Test the key against historical duplicates.
Expected: Validation of the design.
- 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
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.