> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Failed Orders Value, BigCommerce **Metrics type:** [Card](/nerve-centre/overview#metrics-types-explained) > 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 = declined` plus `status = 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). | | | | --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **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. | | **Currency** | **Multi-currency arithmetic sum WITHOUT FX conversion.** Same gotcha as [BC Total Revenue](/nerve-centre/kpi-cards/bigcommerce/total-revenue). | | **Time window** | `30D vsP` (default 30D vs prior 30D). Re-evaluated every sync. | | **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** | The companion view, after recovery is subtracted (from BC Unrecovered Value): | Card | Value | | -------------------------------------- | ------------ | | Failed Orders Value (this card, gross) | \$55,374 | | Recovered within 30 days | \$24,544 | | **Unrecovered (Size of the Prize)** | **\$30,830** | What's interesting: 1. **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. 2. **`Incomplete` orders are 80% of the failed value.** $44,298 of $55,374. This is typical, `Incomplete` is usually higher volume than `declined` because checkout-page friction creates abandonment regardless of payment-side success rate. 3. **Recovery shaves 44% off the gross.** $24,544 of $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. 4. **Annualised: $55,374 × 365 ÷ 30 = ~$674,000/year of attempted purchases failing**, of which \~$300,000 doesn't return naturally. Even capturing 30% of the unrecovered portion ($90,000/year) is meaningful. **How this card moves over time:** * 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](/nerve-centre/kpi-cards/bigcommerce/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](/nerve-centre/kpi-cards/bigcommerce/declined-transaction-rate) | The `declined` half as a rate. Triggers the >8% alert. | | [BC Total Revenue](/nerve-centre/kpi-cards/bigcommerce/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](https://login.bigcommerce.com/deep-links/manage/orders), filter by `Declined`, 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 | **Cross-connector reconciliation (when payment processors are connected):** The dollar value of failures should partially reconcile against processor-side decline value, but the relationship is not 1:1. | Card | Expected relationship | Why it diverges | | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | [`stripe.stripe_decline_value`](/nerve-centre/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`](/nerve-centre/paypal/pp_decline_volume) (when available) | BC declined value (PayPal subset) ≈ PayPal decline volume | Same shape, different processor. | **Cross-platform same-metric:** Adobe Commerce's `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](/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 BOTH `paymentStatus = 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 $55k of attempted purchases, $25k came back naturally, $30k didn't. That $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](/nerve-centre/kpi-cards/bigcommerce/declined-transaction-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. *** ### Tracked live in Vortex IQ Nerve Centre *Failed Orders Value* is one of hundreds of KPI pulses Vortex IQ tracks across BigCommerce and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.