At a glance
Refund volume as a percentage of total Square volume. The companion to squ_refund_volume. Industry-benchmarked: bookshops 1, 3%, apparel 15, 30%, digital <1%. Spikes signal product / fulfilment issues; gentle creep signals subscription churn.
| What it counts | SUM(refunds.amount) / SUM(payments.amount) * 100 over the period, both status = COMPLETED. |
| Currency | Per-currency rate. |
| Time window | 30D vsP. |
| Alert trigger | >10% absolute, OR +30% relative spike. Sentiment inverse-gauge: good <=3, warn >=8. |
| Roles | owner, finance, operations |
Calculation
Calculated automatically from your Square data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
30 days, Austin bookshop:| Subset | Refund rate |
|---|---|
| POS chip + tap | 0.7% |
| Square Online | 2.3% |
| Cash App Pay | 1.5% |
| Square Invoices | 12.3% (the one preorder cancellation) |
- Blended 1.43% is well below the 10% alert threshold. Bookshops sit in the 1, 3% peer band.
- Invoices subset 12.3% is a single-event distortion. One USD 590 refund on a USD 4,800 invoice base. Always slice when sample is small.
- Online 2.3% is normal for non-apparel ecom.
Sibling cards merchants should reference together
| Card | Why pair |
|---|---|
squ_refund_volume | The numerator. |
squ_total_volume | The denominator. |
squ_dispute_rate | Inverse-correlated; refunding promptly prevents disputes. |
Stripe stripe_refund_rate | Cross-PSP. |
Reconciling against the vendor’s own dashboard
Where to look in the Square Dashboard: Square Dashboard does not surface refund-rate as a headline KPI; you compute from refunds tile / sales tile. Why ours may differ:| Reason | Direction |
|---|---|
| Period boundary | A refund processed today for a payment from last month: how it’s bucketed |
| Cash inclusion | Both numerator and denominator |