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

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.

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/pstrbjccVmlRQjtawXNMu_aw