Duplicate Vendor Payment
Find duplicate vendor-payment candidates by normalized name and amount tolerance.
Description
Duplicate-payment candidates combine normalized vendor names with amount similarity.
Duplicate-payment candidates combine normalized vendor names with amount similarity. Candidate status requires investigation.1
Find duplicate vendor-payment candidates by normalized name and amount tolerance.
When to use Duplicate Vendor Payment
Use this tool to find duplicate vendor-payment candidates by normalized name and amount tolerance.
Prepare the documented facts, aligned totals or expected/observed evidence labels requested. Choose applicable requirements and thresholds separately before interpreting a planning screen.
How to use Duplicate Vendor Payment and understand its results
- Prepare the documented facts, aligned totals or expected/observed evidence labels requested. Choose applicable requirements and thresholds separately before interpreting a planning screen.
- Enter vendorNames, paymentAmounts, amountTolerance using the field table and calculation rules, then run the tool.
- Read candidatePairs, candidateCount, candidatePaymentValue. The explanation below defines the units, signs, ordering and any flags or placeholder values.
- If the tool reports an input issue, correct the values and run it again. Apply the stated assumptions when interpreting a successfully returned result.
| Input field | Meaning | Value type; see rules below | Requirement |
|---|---|---|---|
| vendorNames | Vendor names | list of string | Required |
| paymentAmounts | Payment amounts | list of number | Required |
| amountTolerance | Payment amount tolerance | number; minimum: 0 | Required |
Enter nonempty aligned names/nonnegative amounts and nonnegative tolerance. Lowercase names and remove all except ASCII a–z/0–9; check every i<j. Return zero-based i-j pairs/count and sum of each later payment per pair.
pair(i,j) when normalizedName equal AND abs(amounts)≤tolerance Units, indexing, boundary conditions and exceptional cases are defined in the calculation rules above.
| Output field | Meaning | Value type |
|---|---|---|
| candidatePairs | Candidate duplicate index pairs | list of string |
| candidateCount | Candidate duplicate count | integer; minimum: 0 |
| candidatePaymentValue | Later-payment value in candidate pairs | number; minimum: 0 |
{
"input": {
"vendorNames": [
"Acme Inc.",
"ACME INC",
"Beta"
],
"paymentAmounts": [
100,
101,
50
],
"amountTolerance": 2
},
"output": {
"candidatePairs": [
"0-1"
],
"candidateCount": 1,
"candidatePaymentValue": 101
}
}Limitations and assumptions
Non-ASCII or blank names can normalize identically. The same payment can be counted repeatedly; value is not unique duplicated loss. Pairwise processing favors short lists.
Numeric inputs, where present, must be finite. Follow the calculation-specific rules for overflow, underflow and exceptional cases. Lists are limited to 100,000 entries; the rules above may require smaller limits. Missing required fields, extra fields, wrong value types and violations of the calculation rules are input errors.
Alternative or Complementary methods
Use Missing Invoice Sequences: Find gaps inside the observed minimum-to-maximum invoice-number sequence. For a complementary task, use Credit-Memo Vouching: Audit credit-memo authorization and refund evidence.
References
-
Duplicate Vendor Payment — tool.io
Similar or alternative tools
- Missing Invoice Sequences
Find gaps inside the observed minimum-to-maximum invoice-number sequence.
- Credit-Memo Vouching
Audit credit-memo authorization and refund evidence.