agent voided the wrong invoice: invoice number matched by prefix, not exact id

TL;DR

Matching an invoice number by prefix instead of exact id voids the wrong invoice: invoice numbers that share a prefix are different invoices. Always match on the exact invoice id (or the full exact invoice number), and make the void tool reject prefix or fuzzy matches. Restore or reissue the wrongly voided invoice and confirm with the customer.

agent voided the wrong invoice: invoice number matched by prefix, not exact id

Use this when

• An agent voided the wrong invoice via prefix matching
• Invoice lookup uses fuzzy or prefix matching
• You need exact-id enforcement on void

Not for this skill when

• The right invoice was voided but should not have been (authorization issue)
• The invoice number itself is ambiguous in the source data
• You are debugging invoice search rather than void

Steps

1. Confirm which invoice was wrongly voided and which was intended. Expected: The error is scoped.

2. Restore or reissue the wrongly voided invoice and notify the customer. Expected: The damage is repaired.

3. Change the lookup to exact-id matching only; reject prefix, contains, and fuzzy matches in the void path. Expected: The wrong match is structurally impossible.

4. Require the agent to echo the exact invoice id and total before voiding, and get human approval for voids. Expected: A person confirms the target.

5. Add a regression test with prefix-colliding invoice numbers. Expected: The fix is proven.

6. Audit recent voids for other prefix-match errors. Expected: Siblings are caught.

Tool compatibility

Invoice void APIs (Stripe, NetSuite, QuickBooks); exact-id lookup patterns.

Variant phrasings

void wrong invoice prefix match

The mechanism phrased directly.

invoice number exact id void

The fix phrasing.

agent voided incorrect invoice

The incident phrasing.

Why it happens

Invoice numbers are often sequential or share prefixes (INV-2024-001 vs INV-2024-0017), so prefix matching is ambiguous by construction: it returns the first match, not the right match. A void is irreversible in its business effect (the customer is told they owe nothing), so acting on an ambiguous match is the worst place to be fuzzy. Exact-id matching removes the ambiguity entirely, and the human approval gate adds judgment where the stakes are highest. The persona brief's guardrail principle applies directly: destructive actions need exact targeting plus a person.

Edge cases / pitfalls

• Some systems have separate invoice ids and invoice numbers; match on the immutable id, not the display number.
• Bulk void operations multiply this risk; require exact-id lists, never patterns.
• A voided-then-reissued invoice needs a new number in some systems; follow your platform's rules.

Provenance

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