Refunds

Keeping cancelled and refunded orders from clogging your sheet

Every order tracking sheet has two kinds of rows: orders that are still going somewhere, and orders that are done. The first kind needs to be checked. The second kind never will again — and yet most sheets keep checking it anyway, run after run, forever.

That is the slow leak in a manual or half-automated tracking workflow. A few hundred terminal rows hiding in your working set does not break anything obviously. It just makes every sync slower, every refresh noisier, and every status column a little harder to trust.

What "terminal status" actually means

A terminal status is one an order will never leave. Once a row reaches it, there is no future update worth fetching. The clear cases:

• Delivered — the parcel arrived; the logistics journey is over.
• Cancelled — the order was killed before fulfilment.
• Refunded (including delivered-then-refunded) — the money has gone back; the order is closed.
• Expired — AliExpress aged the order out and it will not progress.

Contrast those with live statuses like Awaiting Dispatch, Shipped, or In Transit, which genuinely change between runs. The whole game is separating the two cleanly and only spending API calls on the live set.

A row that says Cancelled & Refunded is not waiting for news. Re-fetching it is paying the AliExpress API to confirm something that cannot change.

Why re-checking dead rows quietly hurts

It is tempting to shrug — what is the harm in one extra lookup? At volume, the harm compounds:

1. Wasted API budget. The AliExpress Dropshipping API has frequency limits. Every call spent on a Cancelled order is a call you cannot spend on a live one, which is how you end up hitting "Api access frequency exceeds the limit" mid-batch.
2. Slower runs. If a third of your sheet is terminal, a third of every sync is pure waste, and a job that should take two minutes drags out.
3. Noise that hides signal. When dead rows sit mixed in with live ones, the few orders that genuinely need attention — a stuck parcel, a fresh refund — get lost in the crowd.

The delivered-then-refunded trap

The trickiest terminal case is the order that was delivered and then refunded. Naive logic treats Delivered as a happy ending and stops watching — so it never notices the refund that lands afterward. Your sheet still shows a clean sale and a positive margin for an order that actually cost you money.

Catching this means checking more than one field. A single refund flag is not enough; you have to look at issue_status, the gmt_refund_* timestamps, and child orders together. We go deep on this in dropshipping refund detection and on the specific Cancelled-on-delivered case in why your refund column shows Cancelled for a delivered order. The cleanup rule is: a row only becomes terminal once you are confident no refund is still in flight.

The skip-list pattern that keeps the working set clean

The fix is a skip list. Before a run starts, it reads each row's current status and excludes anything already in a terminal state. The sync then touches only live orders, finishes faster, and never re-confirms the dead.

Done by hand, you would manually filter or move closed rows to an archive tab every few days — workable, but it is one more chore that slips. Done properly, it is automatic and invisible.

This is built into Fetch Order Tracking. Its batch processing uses a JS skip-list so terminal-status rows — Delivered, Expired, Cancelled, and Cancelled & Refunded — are never re-fetched. Each click clears around 25 fresh orders with a short delay between calls, and auto-chaining moves straight to the next batch, so a run sweeps your live orders in one pass and leaves the closed ones exactly where they are. Your working set stays the orders that still need you.

A clean sheet is a fast sheet

Refund detection and sheet hygiene are the same discipline seen from two angles. Detect the refund correctly, mark the row terminal, and stop touching it — and your sheet stays small, fast, and honest no matter how many lifetime orders pile up behind it.

If your sync feels like it is grinding through orders that closed weeks ago, the problem is not volume — it is that nothing is telling it to stop. Try Fetch Order Tracking and let the skip-list keep your queue down to the orders that actually still matter.

Frequently asked questions

Which order statuses count as terminal and should be skipped?

A terminal status is one an order will never leave: Delivered, Cancelled, Refunded (including delivered-then-refunded), and Expired. Live statuses like Awaiting Dispatch, Shipped, and In Transit still change between runs and need re-checking. The goal is to spend API calls only on the live set and stop re-confirming the dead.

Why is re-fetching cancelled and refunded orders a problem?

The AliExpress Dropshipping API has frequency limits, so every call spent on a closed order is one you cannot spend on a live one, which is how you hit the access frequency limit mid-batch. It also slows every sync and buries the orders that genuinely need attention. Skipping terminal rows keeps runs fast and your signal clear.

How do I keep terminal orders from clogging the sheet automatically?

Use a skip list that reads each row's current status before a run and excludes anything already terminal, so the sync touches only live orders. Fetch Order Tracking builds this in: its batch processing uses a skip-list so Delivered, Expired, Cancelled, and Cancelled & Refunded rows are never re-fetched, leaving your working set down to the orders that still need you.

Related guides

• Refunds you didn't see: catching cancellations on already-delivered orders
• Why your refund column shows Cancelled for a delivered order
• Why your auto-update keeps looping on the same 25 rows

---