> ## 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. # Unfulfilled Orders, Adobe Commerce > Unfulfilled Orders for Adobe Commerce stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) ## At a glance > Live count of orders sitting in `state IN (new, processing, holded, payment_review)` that have not reached `complete` or `closed`. Real-time backlog of orders the warehouse, fulfilment partner, or finance team owes the customer. | | | | ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | `COUNT(*)` of order rows where `state` is one of `new`, `processing`, `holded`, or `payment_review`. These are paid (or paying) orders that have not yet been fully shipped and closed in Adobe Commerce. | | **API field** | `state` (string enum). Adobe Commerce REST endpoint `GET /rest/V1/orders` filtered by `searchCriteria[filter_groups][0][filters][0][field]=state`. | | **VAT / tax treatment** | n/a, this is a count. Tax inclusion is irrelevant. | | **Shipping** | n/a for the headline count. The card concerns shipping *readiness*; the order's `shipping_amount` is unrelated to whether it's shipped yet. | | **Discounts** | n/a. A discounted order in `processing` counts the same as a full-price order in `processing`. | | **Credit Memo refund treatment** | **Credit-Memo-refunded orders are NOT in this card.** A refunded order has typically progressed to `state = closed` (or stayed at `complete` if a partial refund). Either way, it's not in the unfulfilled set. The exception is if a Credit Memo was issued before the order ever shipped, the order may still sit in `processing`; in that rare case it's still counted here. | | **`state` machine inclusion** | **Included:** `new` (created, payment captured, not yet picked), `processing` (the typical "shipping in progress" state), `holded` (admin paused, e.g. fraud check), `payment_review` (gateway flagged for manual review). **Excluded:** `complete` (shipped), `closed` (shipped + refunded or voided post-ship), `canceled` (voided pre-ship), `pending_payment` (gateway never returned, no shipping intent). The Adobe-specific quirk: `pending_payment` orders look "unfulfilled" superficially but they were never paid for, so we exclude them. | | **`pending_payment` quirk** | Excluded from this card by design. Adobe Commerce creates the order skeleton when the shopper hits Place Order; if the gateway never returned success, the order sits in `pending_payment` indefinitely. There's nothing to ship because no money was taken. Use [Pending Payment Orders](/nerve-centre/adobe_commerce/pending_payment_orders) for that backlog separately. | | **Multi-currency `grand_total` vs `base_grand_total`** | n/a for the count; the card is currency-agnostic. The companion *Unfulfilled Order Value* card uses `grand_total` (display currency, mixed without FX) by default. | | **Store View scope (`store_id`)** | **All Store Views summed.** US, UK, DE, B2B portal, and headless storefronts all contribute to the same unfulfilled backlog count. Most warehouses pick from a unified queue regardless of Store View, so the cross-Store-View total usually matches what the operations team actually owes. | | **Time window** | `RT` (real-time snapshot, not a windowed sum). The number reflects the index's most recent sync of `state`. | | **Alert trigger** | `>24h ageing or >50 unfulfilled`, driven by `sentiment_key: unfulfilled_count`. Triggers when the oldest unfulfilled order is more than 24 hours old, OR the absolute count crosses 50. | | **Roles** | owner, operations | ## Calculation Calculated automatically from your Adobe Commerce 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 multi-region homewares brand on Adobe Commerce 2.4.6, snapshot taken at 09:00 GMT on 12 Apr 26. The store ships from a single UK warehouse for UK/EU and from a US 3PL for US/CA orders. | `store_id` | Store View | `new` | `processing` | `holded` | `payment_review` | Total unfulfilled | | ------------- | ---------------------------- | ------ | ------------ | -------- | ---------------- | ----------------- | | `1` | US storefront (3PL Ohio) | 14 | 31 | 2 | 1 | **48** | | `2` | UK storefront (UK warehouse) | 8 | 22 | 11 | 0 | **41** | | `3` | B2B wholesale portal | 0 | 4 | 0 | 0 | **4** | | **This card** | | **22** | **57** | **13** | **1** | **93** | The headline reads **93 unfulfilled orders**, the alert is **firing** because it crossed the 50 threshold. What's happening: 1. **The `holded` cluster on the UK Store View is 11 orders, way above its usual 2-3.** Hover the breakdown and these are all flagged by the merchant's fraud rule (high-value first orders shipping to a freight-forwarder address). The fraud officer is on leave; the queue is backing up. Operations needs to triage them, not the warehouse. 2. **The US Store View has 31 in `processing`, which is normal.** Their 3PL has a 24-hour SLA and processes overnight. None are ageing past 36 hours. Healthy. 3. **The 1 order in `payment_review` is a US AmEx transaction that Stripe Radar flagged.** It's been sitting 18 hours. If unresolved by the 24h threshold the ageing alert will fire on top. 4. **`pending_payment` does not appear on this card** even though Adobe Commerce shows 17 orders in that state right now. They were never paid for; there's nothing to ship. They live on the [Pending Payment Orders](/nerve-centre/adobe_commerce/pending_payment_orders) card instead. Important to keep these straight: a merchant who looks at the order grid in admin sees them mixed in and wonders why this card differs. 5. **The B2B portal contributes only 4 orders but they're worth \$58k.** Order Count says "small problem"; pair with [Unfulfilled Order Value](/nerve-centre/adobe_commerce/unfulfilled_orders_value) for the cash-impact view, the operations team should pick those first. ## Sibling cards merchants should reference together Unfulfilled Orders is an operational card. Pair it with these to make decisions: | Card | Why pair it with Unfulfilled Orders | | ---------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Order State Distribution](/nerve-centre/kpi-cards/adobe-commerce/order-state-breakdown) | The full breakdown including `complete`, `closed`, `canceled`, and `pending_payment`. Tells you whether the unfulfilled spike is real growth or a state-machine bottleneck. | | [Fulfillment Rate](/nerve-centre/kpi-cards/adobe-commerce/fulfillment-rate) | The proportion of orders reaching `state = complete`. If unfulfilled count rises *and* fulfillment rate falls, the warehouse is genuinely behind. | | [Fulfillment Breakdown](/nerve-centre/kpi-cards/adobe-commerce/fulfillment-status) | Per-`state` slice, surfaces whether the issue is `holded` (admin/fraud), `payment_review` (gateway), or genuine `processing` queue. | | [Pending Payment Orders](/nerve-centre/adobe_commerce/pending_payment_orders) | Sister card, NOT included here. Counts the `pending_payment` backlog (gateway-fail orders) which look unfulfilled but never paid. | | [Total Orders](/nerve-centre/kpi-cards/adobe-commerce/total-orders) | Denominator. 93 unfulfilled out of 50 daily orders is a crisis; 93 out of 5,000 weekly orders is normal. | | [Revenue by Store View](/nerve-centre/adobe_commerce/revenue_by_store_id) | Combines with this to spot per-region SLA breaches. | | [`stripe.stripe_charge_count`](/nerve-centre/stripe/stripe_charge_count) | Stripe charges align with `processing`+`complete`+`closed` (i.e. paid). A growing gap between Stripe charges and `complete` orders = unfulfilled backlog. | ## Reconciling against the vendor's own dashboard **Where to look in Adobe Commerce Admin:** The closest Adobe Commerce Admin view is: > **Sales > Orders**, then in the *Status* filter dropdown select `Processing`, `Pending`, `Holded`, and `Payment Review` (multi-select). Set the Status scope to *All Store Views* in the top-left scope dropdown. The order grid row count at the bottom should match this card. For a per-state slice rather than the combined count: > **Sales > Orders**, filter Status to a single value (e.g. `Holded`), and read the row count for that state. Repeat per state to see the breakdown that matches our [Fulfillment Breakdown](/nerve-centre/kpi-cards/adobe-commerce/fulfillment-status) card. Other Adobe Commerce Admin views that *look* like the same number but aren't: * **Sales > Shipments**: lists shipments created, not orders awaiting shipment. The opposite question. * **Sales > Invoices > Pending**: invoices that haven't been paid yet, a different concept (Adobe Commerce can invoice pre-payment in some workflows). * **Reports > Sales > Orders**: a windowed sum, not a real-time backlog. * **Stores > Currency Symbols** and shipping config screens: irrelevant. * **System > Tools > Cache Management** "stale" indicators: completely unrelated. **Why our number may legitimately differ from Adobe Commerce Admin:** | Reason | Direction of divergence | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- | | **Time-zone**. Adobe Commerce Admin renders the order grid in the Store View timezone configured under *Stores > Configuration > General > Locale Options*. The "ageing" sub-metric (oldest unfulfilled order) uses UTC by default in Vortex IQ. The count itself is unaffected because `state` is a real-time enum, not date-bound. | No divergence on count, ±1 hour on ageing | | **Custom statuses**. Merchants can rename `processing` to "Order Confirmed" or add custom statuses like "Awaiting Drop-Ship" that map onto `state = processing`. The Admin grid shows the renamed labels; this card uses the underlying `state` enum, so renamed statuses still count correctly. | No divergence (handled via `state`) | | **Store View scope**. The order grid filter typically defaults to the admin user's assigned scope. Vortex IQ sums every Store View. Set the scope to *All Store Views* in admin for a like-for-like read. | Vortex IQ higher than per-view admin filter | | **`pending_payment` exclusion**. The Adobe Commerce admin grid Status filter includes `pending` (which is `pending_payment` underneath). This card excludes them by design. | Vortex IQ lower than admin grid if `pending` is selected | | **Sync lag**. The card uses the most recent OpenSearch index sync. State changes in the last 1-5 minutes may not be reflected. The Admin grid is live. | Vortex IQ slightly stale at the 1-5 minute boundary; self-resolves at next sync | **Cross-connector reconciliation (when these connectors are connected for this merchant):** Unfulfilled Orders is an internal-state metric, no payment processor or analytics connector tracks it directly. The closest cross-checks are inferential: | Card | Expected relationship | What causes legitimate divergence | | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`stripe.stripe_charge_count`](/nerve-centre/stripe/stripe_charge_count) over the same period | Stripe charges - completed orders ≈ unfulfilled count (for Stripe-paid stores) | Multi-processor stores: Stripe is one of several processors, so this only works if Stripe handles \~100% of payments. Also fails for B2B stores where the order is created on net-30 invoice terms before any payment. | | [`google_analytics.ga_purchases_trend`](/nerve-centre/kpi-cards/google-analytics/purchases-trend) | Not directly comparable | GA4 fires on the order-confirmation page; it doesn't know about subsequent state transitions. Useful only for the inflow side, not the backlog. | ***
Same-metric documentation cross-reference (for agencies running multiple platforms) The same operational concept (unfulfilled orders backlog) lives on other commerce platforms with platform-specific definitions. This is **not a reconciliation**; your Adobe Commerce store doesn't have a parallel store on Shopify or BigCommerce. These cross-links exist so agencies running multi-platform client books can navigate between equivalent metrics across the docs. * [`shopify.unfulfilled_orders`](/nerve-centre/kpi-cards/shopify/unfulfilled-orders) * [`bigcommerce.unfulfilled_orders`](/nerve-centre/kpi-cards/bigcommerce/unfulfilled-orders)
## Known limitations / merchant FAQs **The number is bigger than what my warehouse manager says is in the queue, why?** Three usual causes specific to Adobe Commerce: (1) some orders are in `holded` (admin paused for fraud or manual review) and never reached the warehouse, (2) some are in `payment_review` (gateway flagged), and (3) the warehouse may be looking at one Store View while this card sums all Store Views. Pair with [Fulfillment Breakdown](/nerve-centre/kpi-cards/adobe-commerce/fulfillment-status) to split by `state` and surface the real bottleneck. The warehouse only owes you the `processing` count; ops/finance owns the `holded` and `payment_review` queues. **What's the difference between `state` and `status` on an Adobe Commerce order, and which does this card use?** `state` is the system-level lifecycle (8 fixed values: `new`, `pending_payment`, `processing`, `complete`, `closed`, `canceled`, `holded`, `payment_review`). `status` is a configurable, user-facing label that maps onto `state`. This card uses `state` only. If you've renamed your statuses in the Adobe Commerce Admin (e.g. "Order Confirmed" instead of "Processing") the count is unaffected, we look at the underlying `state`. **Why are `pending_payment` orders excluded?** They were never paid for. Adobe Commerce creates the order skeleton when the shopper hits Place Order, and if the gateway never returned success the order sits in `pending_payment` indefinitely. There's no money taken, no shipment owed. Including them in "unfulfilled" would conflate "we owe a customer a parcel" with "a customer abandoned mid-checkout". They live on a separate [Pending Payment Orders](/nerve-centre/adobe_commerce/pending_payment_orders) card. **My multi-store Adobe Commerce, can I see per-Store-View unfulfilled count?** Not on this card directly. Filter the source data by `store_id`, or use [Fulfillment Breakdown](/nerve-centre/kpi-cards/adobe-commerce/fulfillment-status) which supports per-Store-View slicing. A per-Store-View hero variant is on the roadmap. **Why does the Admin order grid show a different count?** Most commonly: the Admin scope filter is set to a single Store View while this card sums all Store Views. Set the top-left scope dropdown in Admin to *All Store Views*. Second most common: the Status filter in the order grid includes "Pending" (i.e. `pending_payment`), which this card excludes. Match the filter to `Processing + Pending Payment + Holded + Payment Review` minus `Pending Payment` for a like-for-like read. **The payment processor counts don't match, why?** Stripe and PayPal track *successful charges*, not order fulfilment state. A Stripe-paid order in `state = processing` is one Stripe charge AND one row in this card; the same order in `state = complete` is still one Stripe charge but no longer in this card. The payment processor view and this card answer different questions. **Why doesn't Google Analytics match?** GA4 doesn't track fulfilment state at all. The `purchase` event fires once at checkout completion; subsequent state transitions (processing → complete) don't generate GA4 events. GA4 is the wrong tool for this question entirely. **My multi-currency Adobe Commerce, does Unfulfilled Orders care?** No. Unfulfilled Orders is a count, not a money figure, so `grand_total` vs `base_grand_total` is irrelevant. A USD order awaiting shipment and a GBP order awaiting shipment each contribute one. For the cash-impact view, pair with [Unfulfilled Order Value](/nerve-centre/adobe_commerce/unfulfilled_orders_value) which uses `grand_total`. **Why does the count change if no orders were placed?** Two reasons: (1) state transitions, when an order moves from `processing` to `complete` (warehouse confirmed shipment), it leaves this card's set even though no new order was placed; (2) admin actions, when fraud is cleared on a `holded` order it transitions to `processing`, no count change but the breakdown shifts. The card is a snapshot of *current state*, not a windowed sum. *** ### Tracked live in Vortex IQ Nerve Centre *Unfulfilled Orders* is one of hundreds of KPI pulses Vortex IQ tracks across Adobe Commerce 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.