> ## 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. # Financial Status Breakdown, Shopify > Financial Status Breakdown for Shopify stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) ## At a glance > Order distribution by `displayFinancialStatus`. The payment-state health view: how many orders are paid vs pending vs voided vs partially-refunded vs refunded? | | | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | `GROUP BY displayFinancialStatus`. Each order contributes one to its status bucket. Statuses include `PAID`, `PENDING`, `AUTHORIZED`, `PARTIALLY_PAID`, `PARTIALLY_REFUNDED`, `REFUNDED`, `VOIDED`, `EXPIRED`. | | **API endpoint** | `Admin GraphQL. Order.displayFinancialStatus`. | | **State semantics** | `PAID` = capture complete; `PENDING` = awaiting authorisation or capture; `AUTHORIZED` = card auth held but not captured; `PARTIALLY_PAID` = partial capture (rare, layby-style); `PARTIALLY_REFUNDED` = goods kept, partial money returned; `REFUNDED` = full money back; `VOIDED` = auth voided pre-capture; `EXPIRED` = auth window ran out without capture. | | **VAT / tax treatment** | Not applicable (count distribution). | | **Shipping** | Not applicable. | | **Discounts** | Not applicable. | | **Refunds** | A REFUNDED order is a count in the refunded bucket; cross-reference [Refund Rate](/nerve-centre/kpi-cards/shopify/refund-rate) for the share. | | **Cancelled / voided orders** | VOIDED is its own bucket here. | | **Currency** | Multi-currency safe (count distribution). | | **Channels / sources** | Online + POS + B2B all contribute. POS orders are typically PAID at the till; pending statuses are rare for POS. | | **B2B "Net 30 / Net 60"** | B2B Plus stores can have orders in PENDING for extended periods (waiting for invoice payment). These dominate the PENDING bucket on B2B-heavy stores; that is structural, not a problem. | | **Time window** | `30D` (single window) | | **Alert trigger** | None on this card directly; pair with cancellation alerts and refund alerts. | | **Roles** | owner, operations | ## Calculation ``` GROUP BY displayFinancialStatus WHERE date BETWEEN [period_start, period_end] ``` ## Worked example A US multi-channel home goods brand with B2B catalogue on Shopify Plus. Period: 12 Apr 26 to 11 May 26. | `displayFinancialStatus` | Order count | Share | Note | | ------------------------ | ----------- | -------- | ------------------------------------ | | `PAID` | 5,948 | 87.0% | Captured, healthy | | `PARTIALLY_REFUNDED` | 312 | 4.6% | Goods kept, partial money returned | | `REFUNDED` | 218 | 3.2% | Full money back | | `PENDING` | 218 | 3.2% | B2B Net 30 invoices outstanding | | `VOIDED` | 78 | 1.1% | Cancellations (pre-capture) | | `AUTHORIZED` | 42 | 0.6% | Auth held, capture not yet triggered | | `EXPIRED` | 18 | 0.3% | Auth windows ran out | | `PARTIALLY_PAID` | 6 | 0.1% | Layby / split-payment (rare) | | **Total** | **6,840** | **100%** | | Five things to notice: 1. **PAID at 87% is healthy for a mixed B2B / DTC store.** Pure DTC typically runs 92 to 96% PAID; B2B drags the rate because of Net 30 / Net 60 invoicing. The 3.2% PENDING is almost entirely B2B; check by tag-filter on the orders. 2. **PARTIALLY\_REFUNDED at 4.6% is the silent-margin-leak.** Customers who returned 1 of 3 items, or got a 20% post-purchase goodwill credit, sit here. Each is a small loss but they aggregate. Pair with [Top Refunded Products](/nerve-centre/kpi-cards/shopify/top-refunding-customers) to see which SKUs drive partial returns. 3. **AUTHORIZED at 0.6% needs follow-up.** 42 orders held in auth but never captured. Some are intentional (manual capture workflow); some are stuck. Capture windows on most card networks are 7 days; orders sitting in AUTHORIZED for >5 days are at risk of EXPIRED. Set up a daily review of orders aged >3 days in AUTHORIZED. 4. **EXPIRED at 0.3% is genuine lost revenue.** 18 orders where the customer's card auth expired before capture. Fix the workflow that's letting orders sit too long. Most often a manual-fulfilment delay coupled with manual-capture toggle on; switch to auto-capture or set a 48h SLA on capture. 5. **VOIDED at 1.1% should match [Cancellation Rate](/nerve-centre/kpi-cards/shopify/cancellation-rate) loosely.** Voided is the financial-status counterpart to cancelled-status. The two should track within 0.5 ppt. ## Sibling cards merchants should reference together Financial status is a payment-state diagnostic. Pair with these: | Card | Why pair it with Financial Status | What the combination tells you | | -------------------------------------------------------------------------------- | --------------------------------- | ------------------------------------------------------------------------------------------------------ | | [Cancellation Rate](/nerve-centre/kpi-cards/shopify/cancellation-rate) | The cancelled-status counterpart. | VOIDED bucket here ≈ cancelled count. Cross-check for consistency. | | [Refund Rate](/nerve-centre/kpi-cards/shopify/refund-rate) | The refund counterpart. | REFUNDED + PARTIALLY\_REFUNDED here ≈ refund count. | | [Order Count](/nerve-centre/kpi-cards/shopify/total-orders) | Total denominator. | Status shares × total orders = absolute counts per status. | | [Payment Methods](/nerve-centre/kpi-cards/shopify/payment-methods) | Method × status cross-tab. | PENDING heavy on bank-transfer methods; AUTHORIZED on saved-card flows. | | [Gateway Revenue](/nerve-centre/kpi-cards/shopify/revenue-by-payment-gateway) | Money flow per gateway. | A gateway with high PENDING share has slow capture; check capture latency. | | [`stripe.failed_charges`](/nerve-centre/stripe/stripe_failed_charges) | Stripe-side payment failures. | Stripe failures correlate with EXPIRED + VOIDED on Stripe-paid orders. | | [`paypal.paypal_pending_payments`](/nerve-centre/paypal/paypal_pending_payments) | PayPal-side pending. | PayPal e-checks and bank transfers can sit pending for days; check the PayPal-share of PENDING bucket. | ## Reconciling against the vendor's own dashboard **Where to look in Shopify Admin:** [Orders](https://admin.shopify.com/orders) → filter by *Payment status* (each value matches a `displayFinancialStatus`). Counts per filter should align with this card. Other Shopify Admin views: * **Reports → Sales by financial status**: a £-revenue split by status; useful for understanding £ at risk in pending / authorised. * **Settings → Payments**: configures capture and authorisation settings; doesn't show counts but explains why certain statuses are common (manual capture vs auto-capture). * **Apps like Eva.guru, Stripe dashboard direct**: gateway-level views; finer-grained payment state. **Why our number may legitimately differ from Shopify Admin:** | Reason | Direction | Why | | ----------------- | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | **Time zone** | Boundary days | Standard time-zone gap. | | **Status timing** | Either | A PENDING order in your window may flip to PAID after webhook; the next index update reflects the change. Snapshot timing matters. | | **Test orders** | Ours slightly higher | We do not yet filter `Order.test = true`. | | **Sync lag** | Ours lower for "today" | 5 to 15 minute index lag. | **Cross-connector reconciliation:** | Card | Expected relationship | What causes legitimate divergence | | -------------------------------------------------------------------------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------- | | [`stripe.failed_charges`](/nerve-centre/stripe/stripe_failed_charges) | Stripe failed-capture events correlate with EXPIRED + VOIDED orders | Some failures are recovered (retried successfully); not all surface here. | | [`paypal.paypal_pending_payments`](/nerve-centre/paypal/paypal_pending_payments) | PayPal pending count ≈ PayPal-paid orders in PENDING here | PayPal e-checks can sit pending for 5 to 7 days; expected. | ***
Same-metric documentation cross-reference (for agencies running multiple platforms) The same definition lives on other commerce platforms. Cross-platform navigation only. * [`bigcommerce.financial_status`](/nerve-centre/kpi-cards/bigcommerce/financial-status-breakdown) * [`adobe_commerce.financial_status`](/nerve-centre/kpi-cards/adobe-commerce/financial-status-breakdown)
## Known limitations / merchant FAQs **Why is my PENDING share so high?** Three usual causes: 1. **B2B Net 30 / Net 60 invoices.** Outstanding for days or weeks; structural for B2B. 2. **Bank-transfer / e-check payments.** PayPal e-checks, Klarna pay-later flows, ACH transfers. 1 to 7 day clearing time; expected. 3. **Manual capture toggle.** Some merchants run manual capture (capture only on fulfilment). Orders sit AUTHORIZED until you click capture; that bucket flows through PENDING in some configurations. **What's the difference between AUTHORIZED and PENDING?** AUTHORIZED = card auth held but not yet captured. Most card-network auth windows are 7 days; longer than that and the auth expires (becomes EXPIRED). PENDING = waiting for the payment provider to confirm (often used for e-checks, bank transfers, or B2B invoicing). **Should I worry about EXPIRED orders?** Yes. Each EXPIRED order is a customer who tried to buy but didn't pay because the auth ran out. Usually a workflow problem, manual capture not happening on time, or an unfulfilled-order pile-up. Audit your capture SLA and consider switching to auto-capture for routine orders. **Why does my Shopify Admin show different counts?** Time-zone or test-order filtering. Other than that, both should align closely. **Multi-currency, any impact?** None on the count distribution. **Shopify Plus vs basic?** Plus stores can use Shopify Functions to customise capture rules (e.g. capture only on shipment confirmation), which changes the AUTHORIZED-vs-PAID timing. The card's status counts are accurate; the merchant should understand their own capture policy when interpreting. **Refresh cadence?** 5 to 15 minute index lag. Status transitions propagate quickly. **B2B vs DTC, what differs?** B2B has more PENDING (Net 30 invoices) and PARTIALLY\_PAID (deposit-then-balance) orders. DTC is overwhelmingly PAID. Mixed stores benefit from filtering by tag if the goal is DTC payment health. **The card shows a spike in EXPIRED, what should I do?** 1. Pull the EXPIRED orders. Check creation-to-expiry lag; usually it's the days-to-capture metric. 2. Audit fulfilment workflow. If orders sat unfulfilled for >5 days, capture expired. 3. Switch to auto-capture for routine orders if you're on manual. 4. For B2B / large orders that need manual review, set a 48h SLA on capture decisions. 5. Customer-service follow-up: contact EXPIRED customers; offer to recreate the order. Recovery rate is typically 30 to 50% if reached within a week. *** ### Tracked live in Vortex IQ Nerve Centre *Financial Status Breakdown* is one of hundreds of KPI pulses Vortex IQ tracks across Shopify 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.