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) |
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) | The trend behind the snapshot. | A rising avg time + rising unfulfilled count = warehouse capacity ceiling reached. |
| 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 | 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) | 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 | The downstream consequence. | Persistent unfulfilled buildup eventually shows up as a refund spike (cancelled-by-buyer) and a revenue drop. |
| Refund Rate | The downstream quality signal. | Late dispatch correlates strongly with refund rate 7 to 14 days later. |
| Inventory Alerts (OOS) | 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 | 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. |
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.
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. Onlypaid and partially_paid orders count. Orders in pending or unpaid are not yet a fulfilment obligation, see shopline_paid_lag_hours 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.