> ## 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, Shopline > Paid orders with fulfillment_status != fulfilled. The number ops should clear by EOD. 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) > Paid orders with fulfillment\_status != fulfilled. The number ops should clear by EOD. ## At a glance > Real-time count of paid orders not yet marked as fulfilled. The actionable to-do list ops should clear by end of day before SLA breaches kick in or buyer complaints land in customer service. | | | | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | `COUNT(orders WHERE financial_status IN ['paid', 'partially_paid'] AND fulfillment_status != 'fulfilled')`. Counts orders, not line items, so a multi-line order with one shipped line still counts as unfulfilled if any line is outstanding. | | **API endpoint** | `GET /v1/orders?fulfillment_status=unfulfilled&financial_status=paid` polled every 5 minutes; webhook-driven updates fire on `fulfillment.created` and `order.cancelled`. | | **What "unfulfilled" includes** | `pending`, `partial`, `unfulfilled`, NULL fulfillment status. APAC stores often see `partial` for split-shipment orders where one warehouse has shipped but a second has not. | | **What it excludes** | `cancelled` orders (regardless of paid status), `refunded` orders, and unpaid/`pending` financial-status orders (those are not yet revenue, so not yet a fulfilment obligation). | | **Pre-orders** | Orders with `tags` containing `pre-order` are excluded if the merchant has set the convention; otherwise they count and inflate the number until the pre-order release date. Check the `pre_order_until` metafield to filter manually. | | **APAC same-day expectation** | HK and TW merchants typically promise same-day dispatch on orders before 3pm local time. Crossing the 3pm boundary with this number above the alert threshold = SLA risk for tomorrow. | | **Currency** | Not relevant; this is a count, not a value. The drill-down view shows order values per row to let ops triage by basket size. | | **Time window** | `RT` (real-time, refreshed every 5 minutes via polling, instantly via webhook). | | **Alert trigger** | `>10` orders unfulfilled. The threshold reflects "actionable backlog" rather than SLA breach; a small APAC store with 30 orders / day can clear 10 in an hour, a larger store may set the threshold higher in manifest config. | | **Roles** | owner, operations. | ## Calculation Calculated automatically from your Shopline data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example **An APAC fashion brand running a Hong Kong Shopline store, snapshot at 14:30 HKT on 27 Apr 26 (a Monday).** The brand promises same-day dispatch for orders placed before 3pm. Ops have a 30-minute window before the cut-off where this card is the only thing they should be looking at. | Order ID | Created | Paid at | Lines | Value | Status | Why unfulfilled | | ------------ | ------------ | ------------ | ----- | ---------- | ----------------- | ---------------------------------------------- | | SL-2204891 | 26 Apr 18:42 | 26 Apr 18:43 | 3 | HK\$ 1,420 | paid, unfulfilled | Sunday-evening order, queued for Monday | | SL-2205001 | 27 Apr 09:14 | 27 Apr 09:14 | 1 | HK\$ 380 | paid, unfulfilled | Single-SKU, easy pick | | SL-2205012 | 27 Apr 10:02 | 27 Apr 10:02 | 4 | HK\$ 2,180 | paid, partial | One line shipped, three waiting on warehouse 2 | | SL-2205028 | 27 Apr 11:18 | 27 Apr 11:18 | 2 | HK\$ 760 | paid, unfulfilled | | | SL-2205044 | 27 Apr 12:01 | 27 Apr 12:04 | 1 | HK\$ 240 | paid, unfulfilled | | | SL-2205058 | 27 Apr 12:30 | 27 Apr 12:30 | 5 | HK\$ 3,180 | paid, unfulfilled | High-value order; prioritise | | SL-2205073 | 27 Apr 13:08 | 27 Apr 13:08 | 2 | HK\$ 540 | paid, unfulfilled | | | SL-2205089 | 27 Apr 13:52 | 27 Apr 13:52 | 1 | HK\$ 320 | paid, unfulfilled | | | SL-2205101 | 27 Apr 14:14 | 27 Apr 14:15 | 3 | HK\$ 1,180 | paid, unfulfilled | | | SL-2205112 | 27 Apr 14:21 | 27 Apr 14:22 | 1 | HK\$ 420 | paid, unfulfilled | | | SL-2205118 | 27 Apr 14:27 | 27 Apr 14:27 | 2 | HK\$ 680 | paid, unfulfilled | Just landed | | (... 1 more) | | | | | | | ```text theme={null} Total unfulfilled 12 Above 3pm cut-off risk: 10 (must dispatch by 15:00 to honour same-day) Total value at risk: HK$ 11,300 ``` **What it means.** 12 unfulfilled is above the alert (>10). Of those, 10 must be dispatched in the next 30 minutes to honour same-day SLA. The HK\$ 3,180 order (SL-2205058, 5 lines) is the value priority; the high-value cluster between 12:01 and 14:27 is the time priority. **The action.** Ops splits into two: pick-pack runs the 14 single and double-line orders (fastest), warehouse-2 rep finishes the partial order from 10:02 (the brand's cross-warehouse split is a known weak spot for delays). The 18:42 Sunday-night order is already late by brand standards but not by Shopline-system standards (Shopline sets no contractual SLA); the brand should send a "shipping today" courtesy message to the buyer to manage expectation. If the count is still >10 at 15:00 HKT, the day is officially behind on SLA; the brand should pull cover for the next 2 hours from the marketing team or 3PL handoff, depending on staffing. This card refreshes every 5 minutes; ops should be back below 10 by 15:30 to be on track. ## Sibling cards merchants should reference together This is the most-actionable real-time card on the Shopline dashboard. Its natural pairings: | Card | Why it matters next to Unfulfilled | What the combination tells you | | --------------------------------------------------------------------------------------- | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | [Avg Time to Fulfil (hrs)](/nerve-centre/kpi-cards/shopline/avg-time-to-fulfil) | The trend behind the snapshot. | A rising avg time + rising unfulfilled count = warehouse capacity ceiling reached. | | [Fulfillment Rate](/nerve-centre/kpi-cards/shopline/fulfillment-rate) | The 30D outcome. | Persistent unfulfilled spikes drag the 30D rate; check together to see whether today is an exception or the norm. | | [Fulfillment Status Mix](/nerve-centre/kpi-cards/shopline/fulfillment-status-mix) | The mix view. | Lets you see whether the unfulfilled count is mostly `pending` (warehouse not started) or `partial` (started but stuck). | | [Avg Time-to-Paid (hrs)](/nerve-centre/kpi-cards/shopline/avg-time-to-paid) | The upstream lag. | If paid\_lag is high, the unfulfilled count looks worse because orders sit in pending-payment longer before becoming actionable. | | [Total Revenue](/nerve-centre/kpi-cards/shopline/total-revenue) | The downstream consequence. | Persistent unfulfilled buildup eventually shows up as a refund spike (cancelled-by-buyer) and a revenue drop. | | [Refund Rate](/nerve-centre/kpi-cards/shopline/refund-rate) | The downstream quality signal. | Late dispatch correlates strongly with refund rate 7 to 14 days later. | | [Inventory Alerts (OOS)](/nerve-centre/kpi-cards/shopline/zero-negative-stock-variants) | The blocking input. | OOS variants on unfulfilled orders cannot ship; the unfulfilled count has a "stuck on OOS" sub-set that needs separate handling. | | [Shopline Health Score](/nerve-centre/kpi-cards/shopline/shopline-health-score) | Composite view. | Persistent >10 unfulfilled drags the health score; the gauge gives a quicker read for non-ops stakeholders. | ## Reconciling against the vendor's own dashboard **Where to look in Shopline's own dashboard:** The closest Shopline-native view is: > **Shopline Admin (`{shop}.shoplineapp.com/admin`) -> Orders -> Unfulfilled tab** > The tab is the live source of truth and refreshes on page load. For ops use, the Shopline mobile app shows the same count as a badge on the Orders icon, which most APAC merchants check throughout the day. **Why our number may legitimately differ from Shopline's Admin:** | Reason | Direction | Why | | -------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Sync lag** | Ours occasionally lower | Polling runs every 5 minutes, webhook updates within seconds; in the rare case a webhook fails the count can be 5 minutes stale. | | **Pre-order convention** | Ours can include them | If the merchant uses tags inconsistently for pre-order, our exclusion rule cannot cleanly identify them. The Admin Unfulfilled tab does not segment pre-orders either, so on a single-store basis the gap is small. | | **Cancelled orders** | Theirs sometimes higher | A cancelled order can briefly appear in the Unfulfilled tab between cancel-event and Admin-tab refresh; we exclude immediately on the cancellation webhook. | | **Partial vs unfulfilled** | Either | Shopline Admin sometimes counts `partial` separately from `unfulfilled`; we lump them together since both require ops action. The Admin tab can be configured to show both or just one. | | **Multi-warehouse** | Marginal | Multi-warehouse orders show as `partial` until all warehouses ship; the count is the same on both sides but the per-order status text differs slightly. | **Internal identity:** `shopline_unfulfilled = shopline_order_count - SUM(orders WHERE fulfillment_status = 'fulfilled' OR cancelled OR refunded) for orders in the same period` The card is a real-time snapshot, not period-bounded, so the identity is approximate; for an exact rolling reconciliation use [`shopline_fulfillment_rate`](/nerve-centre/kpi-cards/shopline/fulfillment-rate). ***
Documentation cross-reference (for agencies running multiple platforms) The "unfulfilled count" exists on every commerce platform with the same semantic. Reference docs: * [`shopify.unfulfilled_orders`](/nerve-centre/kpi-cards/shopify/unfulfilled-orders) * [`bigcommerce.bigcommerce_unfulfilled`](/nerve-centre/bigcommerce/bigcommerce_unfulfilled) * [`adobe_commerce.unfulfilled`](/nerve-centre/adobe_commerce/unfulfilled)
## Known limitations / merchant FAQs **Why is this count higher on Mondays?** Sunday-night orders queue up overnight in APAC stores. Most fashion and homeware brands see a 2 to 4x Monday spike on the unfulfilled count compared to the rest of the week. Plan warehouse staffing accordingly: an extra 30 to 50% of pick-pack capacity is usually needed on Monday mornings. **Does this include orders waiting on payment?** No. Only `paid` and `partially_paid` orders count. Orders in `pending` or `unpaid` are not yet a fulfilment obligation, see [`shopline_paid_lag_hours`](/nerve-centre/kpi-cards/shopline/avg-time-to-paid) for the upstream payment-clearance lag. **My count says 12 but I just shipped 8 of them. Why hasn't it updated?** Webhook lag, typically under 60 seconds but occasionally up to 5 minutes (the polling fallback). Refresh the card; if the count has not dropped after 5 minutes, raise a sync issue. The Shopline `fulfillment.created` webhook is generally reliable; the most common cause of stuck counts is a webhook receiver outage on our side. **What about pre-orders?** Pre-orders should not count toward this number until their release date, but Shopline does not have a native pre-order field; merchants typically tag the order with `pre-order` or `preorder`. We exclude orders matching this tag pattern. If the merchant uses a different convention (e.g. a metafield), the exclusion rule needs to be configured per-store; otherwise pre-orders will inflate the count until the dispatch date. **Why is the alert at >10 instead of 0?** Because some unfulfilled is normal at any moment. A reasonable APAC store doing 30 to 50 orders / day will always have a few in-flight pick-pack queue at any given snapshot. >10 reflects "actionable backlog" rather than "absolute zero". The threshold is configurable per-store in the manifest if the merchant runs higher volume. **Does this include orders that are in `partial` status (split shipments)?** Yes. Partially-fulfilled orders count as unfulfilled because part of the order is still outstanding. The drill-down view shows which lines are pending so ops can target the correct warehouse. **My count is zero but my Shopline Admin shows 5. What's wrong?** Check whether the 5 in Admin are pre-orders or B2B / wholesale orders that we have excluded. The drill-down view in Nerve Centre shows the exclusion rules applied; reconcile order-by-order if the gap is unexplained. **Why does the count drop on Sundays?** Most APAC merchants do not dispatch on Sundays (Shopline's largest tenant cohort is in HK / TW / SG / JP, where Sunday is the rest day for warehouse staff). Orders accumulate but ops do not act on them until Monday morning, so the Sunday-evening number is a planning preview for Monday rather than a real-time backlog. **Can ops snooze this alert during planned maintenance windows?** Yes; the manifest supports a `quiet_hours` config per-card. APAC merchants typically set 22:00 to 09:00 local-time as quiet hours for this alert so it does not page the on-call ops lead in the middle of the night. **How is this different from the Pending Dispatch card on other connectors?** Same concept, different connector terminology. Shopline calls it "unfulfilled"; Shopify calls it "unfulfilled"; OnBuy calls it "pending dispatch"; Adobe Commerce calls it "pending shipment". The card defines the same operational state across all of them. *** ### Tracked live in Vortex IQ Nerve Centre *Unfulfilled Orders* is one of hundreds of KPI pulses Vortex IQ tracks across Shopline 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.