Calculator
Partial refund reversal calculator
Partial refunds demand per-event arithmetic: the proportional expectation, rounded half-up like Stripe, clamped at 100%, compared against running reversals with a two-cent tolerance. Enter four values to see the computation your reconciliation should be performing — including whether a discrepancy you are seeing is real money or rounding noise.
Inputs and formulas
Fields: original charge amount; original transfer amount; this refund’s amount; sum of existing reversals. Expected = round(min(refunded ÷ amount, 1) × transfer) · Missing = Expected − existing · tolerance |Missing| ≤ 2 minor units before flagging.
- Ratio (clamped)
- 0.3333
- Expected reversal
- $30.00
- Missing
- $30.00
Rounding behaviour worth knowing
Multi-partial charges accumulate independent roundings: three-partials totalling one cent below single-shot math is normal, not theft. The tolerance exists precisely so accumulation noise never becomes queue noise.
Limits, honestly
This computes expectations; it cannot see live state, prior reversals outside what you entered, or net-position interactions with fee refunds. The scanner handles full context; this handles quick checks.
Common questions
Does Stripe compute this for me going forward?
With reverse_transfer set, yes — proportionality is automatic on future refunds. Retroactive corrections remain manual or tooled.
Zero-decimal currencies?
Enter minor units throughout; the math is unit-agnostic and JPY-style amounts work unadjusted.