How do I record a void or reversal of an AI agent's payment on an append-only ledger?

What should I check, step by step?

1. Keep the original payment record as it was written: its event id, amount in minor units, currency, payee, time, approver and policy version. Do not edit those fields later.

2. Decide what void means on the payment rail. If the charge was authorized but not captured, cancel it (Stripe: you can cancel a PaymentIntent that has not succeeded; a succeeded PaymentIntent cannot be canceled). If it has already succeeded, create a refund for some or all of the remaining amount — Stripe creates a separate Refund object and will error if you try to refund more than is left.
3. Get a human approval for the void when the original payment needed one, bound to the original entry id, the refund or cancel reference, the amount and the reason.
4. Write the reversal as a new entry with a new client_event_id (for example void:<original_event_id>) and action_type payment.reversed or payment.voided. Name the original event id, the reversing amount and currency, the reason, the approver and the provider's refund or cancel id.
5. If you don't want those details in summary, put them in a private sidecar, hash its exact bytes, and send that SHA-256 as action_sha256. Keep names, emails and account numbers out of summary and client_event_id: recorded events can't be edited or deleted.
6. Never reuse the original client_event_id for the reversal. The same key with the same content comes back as a duplicate of the first receipt (a retry), and the same key with different content is rejected because that key is already bound to different event content.
7. When you report the period, net each original with the reversals that name it. Rightshold does not compute that net, move money or talk to your card provider.
8. Check both receipts: the stream chain for the pair, and ledger_verify for the public commitments. Keep the pair together for as long as you keep the books.

Why shouldn't I delete or overwrite an AI agent's original payment when I void it?

A hash-chained log works because each entry commits to the one before it. Removing or editing the original payment changes every hash after it, which is exactly what the log exists to expose. Overwriting the amount to zero in place has the same problem: a later reader sees only the zero, not that a payment was once recorded and then taken back.

• Ordinary books make the same distinction. QuickBooks Online's help (updated 7 September 2026) says that when you void a transaction you keep a record in your books that doesn't affect your totals, that voided transactions are zero and show as void, that you can't undo a void, and that deleting a transaction removes it everywhere except the audit log.
• Card networks keep history the same way. Stripe's refunds documentation says you can cancel a payment before it is completed, but a PaymentIntent can't be canceled after it has succeeded; from then on you create a refund. The Refunds API creates a new Refund object against the original Charge or PaymentIntent. You can refund part of a charge, more than once, until nothing remains, and the API errors if you try to refund more than is left or refund a charge that has already been fully refunded. Some refunds issued shortly after the original charge appear as a reversal (the original charge drops off the customer's statement) rather than a separate credit, but that is still a new Refund object on Stripe's side, not an edit of the charge.
• IAS 8 requires material prior-period errors to be corrected by retrospective restatement in the first statements authorized after discovery, and paragraph 49 requires disclosure of the nature of the error and the amount of the correction. That is about the figures presented in the statements, not a license to erase the underlying entries. PCAOB AS 1105.10 tells the auditor to test the accuracy and completeness of information produced by the company (or the controls over it), and AS 1105.11 defines completeness as the assertion that all transactions that should be presented in the financial statements are included. A payment that was deleted is no longer in that population. A payment that was reversed, with the reversal pointing at it, still is.

What should a reversing ledger entry for an AI agent's voided payment contain?

The original entry id (so a reader can join the pair without guessing).

• The reversing amount and currency, equal and opposite for a full void, or the remaining amount for a partial refund. The net of original plus every reversal that names it should be what you report.
• The reason (duplicate payment, order cancelled, goods returned, charged in error) and who approved the void, with the policy version in force at approval time.
• When the reversal was recorded, from a clock you don't control (on Rightshold, received_at is set when the event arrives; occurred_at is the business time you give).
• The provider's reference: a Stripe refund id (re_...) or the canceled PaymentIntent id, so the ledger entry and the rail can be matched.
• A new client_event_id. The original key has to stay bound to the original content; that is how a retry of the original recording stays a retry, and how a later reader can still fetch it.

What does Rightshold do, and not do, when I record an AI agent payment reversal?

record_action appends the event you send to your account's private stream and puts a salted commitment to it on the public ledger. The event (action_type, outcome, occurred_at, summary, action_sha256, client_event_id) can't be edited or deleted. A receipt proves what was submitted and when, and that it hasn't changed since. It does not prove the payment or the refund happened.

• Rightshold does not compute original-plus-reversal nets, does not cancel or refund a card charge, and does not talk to Stripe, your bank or your accounting software. Canceling or refunding on the rail, getting approval and adding the two amounts when you report are steps you run around those records.