Orders that get stuck
An order that has not moved for a week is either waiting for somebody or waiting for something that will never come. This is how to tell which, in the order that costs the least time.
Find them
There is no "stuck" filter, and there should not be one — stuck is a judgement about time. Build the queues instead, on Order Management › Orders:
| Queue | Filter | Who acts |
|---|---|---|
| Awaiting approval too long | status = pending | Whoever approves |
| Placed but never picked | status = placed | The warehouse |
| Part-shipped and idle | fulfillment_status = partial | Purchasing |
| Held | On hold = yes | Whoever set the hold |
| Delivered but unpaid | fulfillment_status = fulfilled, payment_status = open | Accounting |
The dashboard's Awaiting approval and Orders on hold counters cover the first and fourth. The others are worth saving as a filter your team opens every morning.
The six causes, in the order to check them
1. It is on hold. Open the order and look for the banner. It names the reason and the time since. If the reason has been resolved, Release hold. This is the cheapest check and it is the answer more often than people expect.
2. It is waiting for approval. status = pending, placed_at empty. Either
somebody has to release it, or your approval threshold is set so low that
ordinary orders queue. Check the threshold before you blame the approver — a
threshold of €500 in a business whose average order is €800 puts everything in
the queue.
3. Stock is not there. Open the positions and check the articles under
Order Management › Stock › Stock levels. Watch for the specific case where
on_hand looks fine but available is zero: that is reservations, not stock.
See When stock numbers drift.
4. The ERP never took it. acknowledged_at empty on an order that is days
old means the acknowledgement never came back. That is an integration failure,
not an order failure — see
Reconcile orders with your ERP.
5. It shipped, but not through the platform. The order reads placed /
unfulfilled and the customer already has the goods. Somebody shipped from the
warehouse system and never recorded the shipment. Record it now — the order will
not correct itself, and every report you run until then is wrong.
6. Nobody owns it. The order is fine and has no queue. This is the most common cause in practice, and the only fix is process: one named queue, one named person, checked daily.
Reading the History tab
The History tab on the order detail page is every transition, with the actor and the payload. Read it from the bottom.
The last entry tells you what the order is waiting for:
| Last entry | Waiting for |
|---|---|
| The order was placed | Acknowledgement, or picking |
| Acknowledged | A shipment |
| A shipment, with quantity still open | The next shipment |
| Put on hold | Whoever set the hold |
| A payment status change | Nothing on this side |
If the History tab shows an action that the status does not reflect, stop and treat that as a data problem rather than a process one.
The combinations that mean something is wrong
| Combination | What it means |
|---|---|
cancelled / paid | Money taken for goods that will not ship. A refund is owed |
in_fulfillment / failed | Goods left on a payment that did not go through |
placed / any / partial | Impossible from inside. A shipment happened outside the platform |
completed / unfulfilled | Completed by hand without shipping. Correct for a service, a mistake otherwise |
pending for more than a few days | The approval queue is not being worked |
Run these as periodic checks rather than waiting for a customer to find them. The first two cost money; the third makes every report unreliable.
Freeing an order
The action depends on what it is waiting for, and there are only four:
- Release hold — the block is resolved.
- Create shipment — record what actually left, including retroactively.
- Cancel positions — the remainder is never coming; close it so the order can complete.
- Complete — everything that will happen has happened, and the order should not stay open.
Whatever you do, write a comment. The next person to open this order needs to know why it sat for three weeks, and the History tab records what changed but not why you decided it.
Prevention
- Give every queue in the table above a named owner and a daily rhythm.
- Set an approval threshold that matches your real order values.
- Make sure every shipment goes through the platform — a warehouse that ships from its own system without recording it produces cause 5 forever.
- Set a reservation lifetime so abandoned checkouts release stock on their own.
- Watch acknowledgement lag. Orders unacknowledged after a day are an integration alarm.
Next
- Reconcile orders with your ERP — when the two systems disagree.
- When stock numbers drift — the cause behind most "cannot ship" cases.