How do I stop two AI agents from paying the same vendor invoice twice?

What should I check, step by step?

1. Write the normalization rules down before any agent pays: use your internal vendor id (not the display name), a single rule for trimming and casing invoice numbers, amounts as integer minor units, and currency as an ISO 4217 code.

2. Build the claim key as vendor + invoice number + amount + currency. Keep it within 160 characters of letters, digits, periods, underscores, colons, slashes, at signs or hyphens, which is what client_event_id allows.
3. Put the claim in one place every agent's payment path goes through: the same Rightshold account's action stream, or your own invoice register with an atomic insert on that key.
4. Before authorize_spend, record the claim with record_action (action_type invoice.claimed, client_event_id set to the key) using a canonical body that does not name which agent asked, so two agents sending the same claim look identical. If the receipt comes back with duplicate: true, the invoice was already claimed — do not pay. If the call is rejected because the key is bound to different content, stop and inspect; do not mint a new key.
5. Only if the claim is new, call authorize_spend and put the same key in reference so the spend receipt points at the claim. authorize_spend does not treat reference as a dedupe key; each new allow counts toward the daily cap.
6. After the payment succeeds, record payment.sent under a new client_event_id (for example pay:<claim-key>) that names the claim, the spend receipt id and the provider payment id.
7. If you allow partial payments against one invoice, drop amount from the uniqueness key and track the remaining balance in your register. When amount stays in the key, two identical full-amount payments of the same invoice are the duplicates you catch; two legitimate partials of different amounts will not collide.
8. If a duplicate payment already went out, refund it on the rail (Stripe's Refunds API accepts reason=duplicate) and post a linked reversing entry for the extra payment — don't delete that record. How to record a void or reversal of an AI agent's payment on an append-only ledger covers that pair.

Why isn't two AI agents paying the same vendor invoice the same as a payment retry?

A retry is one intended payment that may be sent more than once (a timeout, a crashed worker, a framework replaying a step). The fix is one idempotency key created before the first attempt and reused unchanged, which is covered on the page about stopping an agent from paying twice when it retries, and on the page about binding a payment receipt to its trigger, policy and idempotency key before replay.

• A duplicate bill is a different intended payment for the same vendor invoice: a second agent, a second task, or a person and an agent each see the invoice as unpaid and each create their own payment with their own idempotency key. The payment provider happily charges twice, because each request looks new.
• That is why the check has to run on the invoice, not on the payment attempt, and why it has to run before authorize_spend. Two allows against the same invoice, each with a different reference, will both pass a spend cap that only looks at amount and merchant.

How do I dedupe vendor, invoice number, amount and currency before an AI agent authorizes a payment?

Vendor id first. Many vendors number invoices from 1 or INV-001, so invoice number alone collides. Use the identifier from your vendor master, normalized the same way every time (lowercase internal id, not 'ACME Inc.' vs 'Acme, Inc.').

• Invoice number next, under one written rule for spaces, dashes and case, so 'INV 4471' and 'inv-4471' don't slip past each other unless you meant them to be different.
• Amount in minor units and currency (ISO 4217) last. Together they separate a corrected re-issue at a new total from a second payment of the same bill. If you accept partial payments, take amount out of the uniqueness key and hold a remaining balance instead.
• The claim itself has to be atomic: one insert that fails if the key exists, not a read-then-write. On Rightshold, record_action with a deterministic client_event_id is that insert for agents that share the account's action stream. Two identical claim bodies come back as duplicate: true. A different body under the same key is rejected. Agents that record to different accounts or streams do not share that key space, so they still need your own register in front.

What does Rightshold do, and not do, to stop two AI agents paying the same invoice?

record_action keys events by client_event_id on your account's private stream and will not bind that key to different content. authorize_spend checks one credential's spending policy and records a signed allow or deny; it does not look up other agents' payments or treat reference as unique. An allow counts toward the daily cap when it is recorded.

• Rightshold does not hold a vendor master, parse invoice PDFs, talk to your accounts-payable system or refund a duplicate charge. Normalization, the shared register (if agents don't share one stream) and the refund of a payment that already went out are steps you run. Not accounting or legal advice.