At a glance
Live count of orders sitting instate IN (new, processing, holded, payment_review)that have not reachedcompleteorclosed. 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 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
holdedcluster 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. - 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. - The 1 order in
payment_reviewis 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. pending_paymentdoes 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 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.- The B2B portal contributes only 4 orders but they’re worth $58k. Order Count says “small problem”; pair with Unfulfilled Order 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 | 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 | The proportion of orders reaching state = complete. If unfulfilled count rises and fulfillment rate falls, the warehouse is genuinely behind. |
| Fulfillment Breakdown | Per-state slice, surfaces whether the issue is holded (admin/fraud), payment_review (gateway), or genuine processing queue. |
| Pending Payment Orders | Sister card, NOT included here. Counts the pending_payment backlog (gateway-fail orders) which look unfulfilled but never paid. |
| 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 | Combines with this to spot per-region SLA breaches. |
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 selectFor a per-state slice rather than the combined count:Processing,Pending,Holded, andPayment 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.
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 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.
| 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 |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
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 | 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. |
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 inholded (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 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 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 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 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.