SUM(totalIncTax) for declined + incomplete orders. The gross ‘what’s leaking’ figure before recovery deduction.
At a glance
The gross dollar value of every BigCommerce checkout that failed in the period:paymentStatus = declinedplusstatus = Incomplete. This is what’s leaking, the upper bound on opportunity, before any recovery deduction. The “after recovery” view is BC Unrecovered Value (Size of the Prize).
| The formula | SUM(total_inc_tax) WHERE paymentStatus = 'declined' OR status = 'Incomplete'. Both failure types are summed; we surface the combined number here, the per-type breakdowns are on BC Decline Rate and BC Incomplete Rate. |
| VAT / tax treatment | Tax-inclusive. Standard total_inc_tax semantics. The figure represents the full amount the customer was trying to pay. |
| Shipping | Included. total_inc_tax already contains shipping cost. |
| Discounts | Already deducted, this is post-discount. The customer was attempting to pay the discounted price. |
Why both declined and Incomplete are summed | They’re different failure types but both represent intent to pay that didn’t complete. Aggregating them gives the merchant a single “leak” number. The two types should be diagnosed separately, but tracked together at the headline level. |
| What’s NOT counted | (a) Cancelled orders (the customer or merchant deliberately voided after success), (b) refunded orders (different stage of the lifecycle), (c) Pending orders (still in flight, not yet failed). |
| Refunds | Not in scope. Refunds happen after a successful order; failed orders never reached that stage. |
| Recovered orders | This card does NOT subtract recovered revenue. It’s the gross “what tried to come in but didn’t” figure. The post-recovery view is BC Unrecovered Value. |
| Currency | Multi-currency arithmetic sum WITHOUT FX conversion. Same gotcha as BC Total Revenue. |
| Channels / sources | Not filtered. Failures across all channel_id values are summed. Use BC Failures by Channel to slice. |
| Time window | 30D vsP (default 30D vs prior 30D). Re-evaluated every sync. |
| Alert trigger | None directly, this is a magnitude card, not a rate card. The companion alerts are BC Decline Rate (>8%) and BC Incomplete Rate (>5%). |
| Roles | owner, finance, marketing |
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
Same US homewares store on BigCommerce, 30-day window 14 Mar 26 to 12 Apr 26.| Failure type | Order count | Total total_inc_tax |
|---|---|---|
paymentStatus = declined | 71 | $11,076 |
status = Incomplete | 414 | $44,298 |
| Failed Orders Value (this card) | 485 | $55,374 |
| Card | Value |
|---|---|
| Failed Orders Value (this card, gross) | $55,374 |
| Recovered within 30 days | $24,544 |
| Unrecovered (Size of the Prize) | $30,830 |
- The headline $55,374 is the gross opportunity number. This is the total dollars that tried to come in and didn’t, before any natural recovery. CFOs reading this should understand it’s the upper bound on what’s at stake.
Incompleteorders are 80% of the failed value. 55,374. This is typical,Incompleteis usually higher volume thandeclinedbecause checkout-page friction creates abandonment regardless of payment-side success rate.- Recovery shaves 44% off the gross. 55,374 came back within 30 days organically (without any merchant action). That’s healthy organic recovery. The remaining $30,830 is what targeted recovery tooling addresses.
- Annualised: 674,000/year of attempted purchases failing, of which ~90,000/year) is meaningful.
- Up + Decline Rate up = real performance regression. Investigate.
- Up + traffic up = volume effect; check rates not absolute values.
- Up + AOV up = bigger orders are failing (higher-value cart abandonment patterns).
- Down + traffic down = quieter period, less to leak.
- Down + traffic flat = recovery tooling working, OR fraud rules eased (check for fraud-loss spike before celebrating).
Sibling cards merchants should reference together
| Card | Why pair it with Failed Orders Value |
|---|---|
| BC Failed Orders Count | The order-count companion. Failed Value ÷ Count = average failed order value (often skewed high by big abandoned carts). |
| BC Decline Rate | The declined half as a rate. Triggers the >8% alert. |
| BC Incomplete Rate | The Incomplete half as a rate. Different root causes; track separately. |
| BC Unrecovered Value (Size of the Prize) | This card minus organic recoveries. The addressable opportunity. |
| BC Organic Recovery Rate | What fraction came back without action. Healthy stores see 30, 50% organic recovery. |
| BC Decline by Payment Method | Where the failures concentrate. The fastest fix surface. |
| BC Top Unrecovered Today | The daily action list, biggest unrecovered failures from yesterday. |
| BC Total Revenue | Useful denominator: failed_value ÷ (total_revenue + failed_value) = “share of attempted revenue that failed”. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: Orders, filter byDeclined, sum the order totals, then repeat for Incomplete, then add. This gives you the manual equivalent of this card. BC does NOT surface this aggregate as a single dashboard metric.
Why our number may legitimately differ from a manual BC sum:
| Reason | Direction |
|---|---|
| Time-zone. BC Control Panel uses store timezone; Vortex IQ uses UTC by default. Boundary-day effects. | Marginal |
Cancelled exclusion. Some manual analyses include Cancelled orders in “failed”. This card excludes them by design. | Vortex IQ slightly lower |
| API page caps. If BC API throttled during indexer run, latest orders may be a few minutes stale. | Self-resolves |
| Currency. We sum across currencies arithmetically. | Multi-currency stores see meaningless totals |
| Card | Expected relationship | Why it diverges |
|---|---|---|
stripe.stripe_decline_value (when available) | BC declined value ≈ Stripe-routed declined value (when Stripe is the processor) | Stripe sees individual charge attempts; BC sees orders. A 3DS retry is two Stripe failures but one BC declined order. |
paypal.pp_decline_volume (when available) | BC declined value (PayPal subset) ≈ PayPal decline volume | Same shape, different processor. |
pending_payment value is a rough analog of Incomplete; Shopify’s “abandoned checkout value” is an even rougher analog. Direct cards on those platforms are tracked in the CONNECTOR_BACKLOG. Until those ship, this card is BC-specific.
Known limitations / merchant FAQs
Why is this number so much bigger than my Stripe declined number? Because this card includes BOTHpaymentStatus = declined AND status = Incomplete. Stripe only sees attempts that reached its API. Incomplete orders, where the customer hit Place Order but the payment iframe never returned, may never have hit Stripe at all (network timeout, customer closed the tab, 3DS interstitial got blocked). On BC, Incomplete is typically 3, 5× larger than declined by volume.
Is this number “lost revenue”?
Not quite. It’s the gross “attempted purchases that didn’t complete” figure. Some of these customers came back and bought (organic recovery), some won’t ever (lost). The “lost” view is BC Unrecovered Value (Size of the Prize), which subtracts organic recoveries.
The number is huge but my CEO is asking “is this real”?
Yes, the value is real, but framing matters. Most of these customers will buy elsewhere if you don’t recover them. The right CEO conversation is: “Of this 25k came back naturally, 30k annualised is $375k/year of P&L line that proper retry tooling could capture.”
My number jumped 2× this week, what should I check?
Check whether BC Decline Rate and BC Incomplete Rate both spiked, or just one. If only Incomplete spiked, the issue is checkout-page; if only Declined spiked, payment-side or fraud-rules; if both spiked together, it’s usually traffic-mix (a low-quality affiliate burst or a discount campaign brought worse customers).
Are test orders included?
No. BC test orders use a separate flag (is_test). Vortex IQ filters them. Note: developer-environment test orders sometimes leak into production indexes when is_test isn’t set; if you see weird-looking high-value entries on BC Top Unrecovered Today, check the developer environment.
What’s the relationship between this card and Refund Value?
None directly. Refunds happen after a successful order. This card is about orders that never succeeded. Track them as separate revenue-leakage signals.
My subscription store, do recurring failures inflate this?
Yes, every failed recurring billing attempt (declined card, expired card, insufficient funds) shows up as a paymentStatus = declined order. Subscription stores often see this card sit at higher absolute values than equivalent-revenue DTC stores; that’s normal. Pair with BC Repeat Failure Customers to identify subscribers in trouble.
My multi-currency BC store, what currency does this show?
Sums across currencies arithmetically without FX. Multi-currency stores see a meaningless mixed total. Use a currencyCode-filtered view, or filter at the BC Orders level when reconciling.
Why does this number include Incomplete but BC’s order list separates them?
Because the merchant’s commercial concern is “what failed”, regardless of the BC-internal taxonomy. The two failure types aggregate naturally for executive reporting; the type-specific cards exist for diagnosis.
Is this real-time or daily?
Re-evaluated every sync (every 15-30 minutes typically). The trend chart on the card uses 30-day rolling but the underlying figure is fresh.