unrecovered_value × 365 ÷ period_days. The yearly $-on-the-table figure used to size the business case for recovery investment.
At a glance
The annual run-rate of BC Size of the Prize. The 30-day unrecovered-failure value scaled to a full year using unrecovered_value × 365 ÷ period_days. This is the boardroom number, the same data as the 30-day card, framed for the P&L conversation.
| What it counts | The unrecovered-failure dollar value over the period, multiplied by 365 / period_days to express as an annual run-rate. Example: 375,099/year. |
| VAT / tax treatment | Tax-inclusive. Inherited from BC Size of the Prize, which sums total_inc_tax (always tax-inclusive). |
| Shipping | Included. Standard total_inc_tax semantics. |
| Discounts | Already deducted. The unrecovered values reflect what the customer was trying to pay. |
| Refunds | Not in scope, the underlying card looks at orders that never succeeded. |
Incomplete quirk | Inherited: both Declined and Incomplete failure populations contribute to the underlying unrecovered value. Annualising preserves their ratio. |
| What “annualised” actually means | A naive linear extrapolation. We do NOT seasonality-adjust, do NOT account for promotional cycles, do NOT discount for assumed remediation. The raw arithmetic. Treat the number as an order-of-magnitude estimate, not a CFO-precise forecast. |
| Currency | Inherits the multi-currency arithmetic-sum-without-FX limitation from the underlying card. Multi-currency stores get a meaningless mixed-currency total. |
| Channels / sources | Not filtered. All channel_id values contribute. |
| Time window | 30D (the underlying period, then × 365/30 = 12.17x scaling factor) |
| Alert trigger | None. Companion alerts: BC Decline Rate, BC Incomplete Rate, and the operational BC Size of the Prize card. |
| Roles | owner, finance |
Calculation
Calculated automatically from your BigCommerce data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US homewares brand on BigCommerce Enterprise (the same store as the BC Total Revenue worked example and BC Size of the Prize worked example). The 30-day window covers 14 Mar 26 to 12 Apr 26.| Component | 30-day value | × 365 / 30 | Annualised |
|---|---|---|---|
| Failed value (Declined + Incomplete) | $55,374 | × 12.17 | $673,886 |
| Recovered value (joined to subsequent successes) | $24,544 | × 12.17 | $298,697 |
| Unrecovered value (the prize) | $30,830 | × 12.17 | $375,189 |
| Failed orders (count) | 485 | × 12.17 | 5,902 |
| Unrecovered customers | 269 | × 12.17 | 3,274 |
- The number reframes the conversation. 375k a year is “we need a meeting”. Same data, different audience. Use this version for board reviews, recovery-tooling-vendor RFPs, and finance-team forecasting.
- Recovery tooling ROI math becomes obvious. A typical Klaviyo + smart-retry stack costs 375k prize ($94k/year) returns 1.5-3x on tooling spend in year one. This card is the strongest single argument for buying recovery software.
- The annualised view exposes seasonality drift. If your 30-day window happens to fall in a quiet shoulder period (Feb, late Aug), the annualised number under-states the prize. If it falls in peak (late Nov, early Dec, post-Easter UK), it over-states. Always cross-check the annualised number across at least 3 different 30-day windows before committing it to a board pack.
- Compare to revenue. This store does ~375k unrecovered prize is 6.7% of gross revenue, on the high side of normal (industry baseline 3-7%). A 6.7% prize is large enough that recovery tooling investment should be top-three on the operations roadmap.
- Board / investor decks: “We are leaving $375k on the table annually that recovery tooling can capture 25-40% of.”
- CFO / finance: “Compared to our $5.6M revenue base, our recovery prize is 6.7%. Closing half of that adds 3.4% to top-line, equivalent to a 5% growth campaign with no acquisition cost.”
- Recovery-vendor RFPs: “Our addressable prize is $375k/year; show us the ROI math at 25%, 40%, and 60% capture rates.”
- Operations team: “The 30-day operational view is in BC Size of the Prize. This card is for executive framing, not daily action.”
Sibling cards merchants should reference together
| Card | Why pair it with Size of the Prize Annualised |
|---|---|
| BC Size of the Prize | The 30-day operational version. Same data, daily-action framing. Use both, the 30-day for action, the annualised for executive conversations. |
| BC Failed Orders Value | The numerator before recovery is subtracted. Annualised failed value gives the gross prize ceiling. |
| BC Organic Recovery Rate | The base rate of “free” recoveries (no merchant action). Multiplying the gross prize by (1 - organic_recovery_rate) gives a more honest addressable opportunity. |
| Total Revenue | The denominator for “prize as % of revenue”, the most useful single ratio for board conversations. |
| BC Decline Rate | If decline rate is climbing, the prize will grow even if you do nothing. |
| BC Incomplete Rate | Same but for the UX-side failure population. |
| BC Repeat Failure Customers | The customer-level concentration view; annualising the $-impact of repeat-failure customers gives the per-customer prize. |
| BC Decline by Payment Method | Method-level slicing of the prize. Often one method holds 40-60% of the addressable opportunity. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: BigCommerce does not surface this metric natively. No section of the BC Control Panel computes annualised recovery opportunity. To partially verify:- Filter Orders by status
DeclinedandIncompletefor a 30-day period, sum the order totals, that is the gross failed value. - There is no native BC view for the recovery join or the annualisation step.
- Plug the gross failed value into the formula
(failed_value − recovered_value) × 12.17to approximate this card; you’ll need a manual recovery query (per-customer order history) for the recovered_value side.
| Reason | Direction |
|---|---|
Email-first join semantics. We capture more recoveries than naive customerId-only manual exports, which lowers the unrecovered base, which lowers the annualised number. | Vortex IQ LOWER than naive manual annualisation |
| 30-day recovery window. Manual analysis often uses 14-day windows; we use 30 days. Longer window = more recoveries = lower prize. | Vortex IQ LOWER |
| 365-day vs 360-day annualisation. Some finance teams use 360 (banking convention); we use 365 (calendar). | Vortex IQ ~1.4% higher |
| Period selection. The annualised number is sensitive to which 30-day window you sample. A peak-traffic window inflates; a quiet window deflates. | Either direction, often material |
| Currency. Multi-currency stores get a meaningless mixed-currency total. | Mixed-currency totals are nonsense |
| Card | Expected relationship | Notes |
|---|---|---|
stripe.stripe_decline_rate | Stripe-side decline base for the BC declines | Stripe sees only successfully captured charges; the unrecovered side is invisible Stripe-side. |
paypal.pp_decline_rate | PayPal-side decline base for the PayPal-routed declines | Same as above. |
Declined + Incomplete distinction is BC-specific in our current build. Adobe Commerce has pending_payment orders (rough analogue of Incomplete) and Shopify has displayFinancialStatus = ABANDONED, but the recovery-join + annualisation logic is BC-only. Equivalents are tracked on the CONNECTOR_BACKLOG.
Known limitations / merchant FAQs
Why annualise instead of just showing the 30-day number? Because finance teams and boards think in years, not 30-day chunks. A 375k annual prize is a P&L line item. Same data, different framing, dramatically different decisions. Use the operational BC Size of the Prize for daily action; use this card for executive conversations where the audience needs a yearly figure. Is the annualised number reliable for budgeting? Order of magnitude, yes; precise forecast, no. The number is sensitive to which 30-day window you sample. A peak-traffic window (Black Friday spilling into December) inflates; a quiet window (early February, late August) deflates. Cross-check across at least 3 different 30-day windows before quoting the figure in a budget. My number jumped 50% this month, did the prize really grow that much? Probably not. Three usual causes: (1) Period sampling, your current window includes a high-traffic event (sale, seasonal peak, paid-ads burst). (2) Underlying failure rate climbed, check BC Decline Rate and BC Incomplete Rate trends. (3) Recovery rate dropped, your abandonment-recovery tooling stopped firing or your email deliverability tanked. Look at the underlying components before trusting the headline jump. What recovery rate should I assume when modelling ROI? Industry benchmarks: 25-40% of the addressable prize is genuinely recoverable with serious tooling investment. Conservative model: 20%. Mid model: 30%. Aggressive model: 45%. The split varies by failure type:Incomplete orders recover at 35-50% with email; Declined orders recover at 15-25% with retry logic plus email. The BC Organic Recovery Rate card tells you what fraction recovers without ANY tooling; that’s the floor.
My prize is 80k/year, is that worth it?
Run the math: 112.5k revenue back. Subtract 32.5k incremental revenue. That’s an 1.4x ROI in year one, marginal. The decision pivots on (a) whether the vendor’s actual capture rate hits 30% (test in pilot), (b) whether the incremental revenue carries normal gross margin (so 13-20k gross profit), and (c) whether saved customers have lifetime value beyond the recovered transaction (typically yes, +30-50% LTV). For most stores, yes; for thin-margin stores, negotiate harder.
Why does the underlying card use 30 days, not 90 days?
30 days matches typical abandonment-recovery email cadence (most flows fire within 24-72 hours, last touch by day 21). A 90-day window would catch more recoveries but also more “the customer was always going to come back anyway” noise. 30 days is the canonical recovery-tooling window in the industry.
Should I trust the annualisation if my business is highly seasonal?
Take it with a grain of salt. A swimwear retailer’s June 30-day window annualises to a wildly different number than their December window. For seasonal businesses, run the underlying card on three windows (peak, shoulder, trough), average the unrecovered values, then annualise the average. The Vortex Mind decline-recovery-intelligence report has a built-in seasonality-adjusted annualisation; use that view instead of this raw card for serious planning.
Why is my multi-currency annualised number meaningless?
Because multi-currency stores produce a mixed-currency total at the underlying card level (no FX conversion), and annualising a mixed-currency number is just multiplying nonsense by 12.17. Per-currency annualised cards are on the BC roadmap. Until then, filter the underlying view by currencyCode first, then apply the 365 / period_days scaling manually.
Can I use this for my recovery-vendor RFP?
Yes, that’s one of its intended use cases. Quote the annualised prize, then ask vendors to provide ROI math at three capture rates: 25%, 40%, 60%. Reject anyone whose math assumes >50% capture, that’s not realistic for the BC checkout-failure use case.
Why don’t you adjust for inflation / future revenue growth?
Because the card is a snapshot of current run-rate, not a future forecast. Inflation and growth adjustments belong in your finance team’s planning model, not in the operational metric. Keep the metric simple and let the planning team layer adjustments on top.