## TL;DR
Recurring payments are similar by nature: same vendor, same amount, regular intervals. A dedupe rule that only compares vendor and amount will erase them. Require date proximity to the suspect event, an invoice or bill reference, and a shared source, such as one batch or one import retry, before calling anything a duplicate. Regular monthly rents and retainers each with their own bill pass; two payments against one bill do not.

```text
agent's dedupe pass failed: flagged legitimate recurring vendor payments as duplicates
```

## Use this when
- Legitimate recurring payments, such as monthly rent or a retainer, are flagged as duplicates.
- Each flagged payment settles a distinct bill or billing period.
- The payments are spread across weeks or months, not minutes.

## Not for this skill when
- Two payments really did settle one invoice, or a retry created a second transfer. Those are true duplicates; keep the flags and resolve them.
- The same bill was paid twice in one day. Date proximity is high and the flag is probably right; verify, do not dismiss it.

## Steps
1. List the flagged pairs with dates, invoice or bill references, and the payment source. Verify: each pair shows whether it settles one bill or two
2. Confirm recurrence from the payment history: same vendor, amount, and regular cadence over several periods. Verify: the recurrence pattern is established from history, not asserted
3. Clear the false flags and let each payment settle its own bill. Verify: no legitimate payment remains flagged after the review
4. Rewrite the dedupe rule to require corroborating evidence beyond similarity: shared invoice, shared batch id, or date proximity within the retry window. Verify: the rule definition names its evidence conditions
5. Test the new rule on historical data URIs true past duplicates must still flag and recurring payments must not. Verify: both sides of the test pass on known cases

## Variant phrasings
### dedupe flagged recurring monthly payments false duplicate
The false-positive phrasing.
### recurring vendor payment duplicate detection rule fix
When tuning the rule.

Compatibility: Agent dedupe logic in AP and reconciliation tools handling recurring payments.

## Why it happens
Similarity is necessary but not sufficient for duplication. Recurring business creates repetition by design, so a matcher that stops at similarity converts routine operations into exceptions. The missing ingredient is linkage: duplicates share an origin event, an invoice, a batch, a retry, while legitimate recurrence links each payment to its own distinct obligation. Requiring linkage focuses flags on events that are actually wrong.

## Edge cases / pitfalls
- True duplicates hide inside recurrence too: a double rent payment this month is one extra event, not the pattern. Review counts per period, not just patterns.
- Amount variation breaks similarity-based rules in the other direction; recurring payments with varying amounts need reference-based linking instead.
- Log rule changes and back-test them; a rule quieted for one vendor may be the only protection for another.

## Provenance

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