Refunds

Why your refund column shows Cancelled for a delivered order

You scan your sheet, and one row stops you: tracking status says Delivered, but the refund column says Cancelled. Your first instinct is that the automation glitched. It did not. That row is telling you the truth — this is a delivered-then-refunded order, and it is one of the most important rows in your whole sheet.

The confusion comes from a wrong assumption baked into most spreadsheets: that "delivered" and "refunded/cancelled" are opposite ends of one line. They are not. They are two different facts about the same order, and an order is perfectly capable of being both at once.

Delivery and refund are different axes

Think of every order as having two independent properties:

• Where the parcel is — driven by logistics_status and the carrier's tracking. This answers "did it arrive?"
• What happened to the money — driven by issue_status, the gmt_refund_* fields, child orders, and order_status. This answers "did you keep the cash?"

These move on their own clocks. A parcel can be delivered on Monday and refunded on Thursday. So "Delivered + Cancelled" is not a contradiction — it is the system correctly recording that the goods arrived and the order was reversed. We lay out the underlying detection logic in refund detection beyond gmt_refund_payment_finish.

"Delivered" describes the parcel. "Cancelled" describes the money. The dangerous orders are the ones where those two disagree — because that is your margin walking out the door.

How an order ends up Delivered and Cancelled

There are a handful of common paths to this state, and none of them is rare:

1. Item-not-as-described dispute after delivery. The buyer received it, opened a dispute, and AliExpress sided with them. Parcel kept, money returned.
2. Partial refund on a delivered order. A goodwill or partial refund settles while the order stays delivered — your AE order amount no longer reflects what you actually paid net.
3. Child-order cancellation in a split shipment. One half of a split arrives and the other is cancelled and refunded. The row can read delivered on one leg and cancelled on another.
4. Supplier-initiated cancellation post-dispatch. The supplier cancels and refunds even though the carrier already moved the parcel.

In every case, the honest representation is exactly what surprised you: delivered, and cancelled/refunded, side by side.

Why you must not "fix" it

The tempting move is to write a rule that forces consistency — "if delivered, clear the refund flag" or vice versa. Do not. That rule destroys the one signal you most need. It hides money you lost behind a status that looks healthy, and your profit column quietly overstates the month.

The whole reason this matters is the delivered-but-disputed scenario: an order that looks complete on the surface while cash flowed back out underneath. If you flatten the two axes into one, you can never see it again.

How to model it correctly

Keep delivery and refund in separate columns, and let each tell its own truth. A clean layout looks like this:

• A tracking status column (Awaiting Dispatch, Shipped, Delivered) driven purely by logistics.
• A refund state column (None, Refunded, Cancelled, In Dispute) driven purely by the money signals.
• A net amount that reflects the AE order amount adjusted for any refund, so partial refunds show up in the figure you actually report.

With that structure, "Delivered + Cancelled" stops being alarming and becomes informative. You can filter for it, total the leakage, and spot suppliers or product lines that generate post-delivery refunds. Once those orders hit a terminal state, they should also drop out of your active re-check queue so you are not paying API calls to re-examine settled rows — the cleanup approach we cover in keeping cancelled and refunded orders from clogging your sheet.

Let the fetcher keep the two axes honest

Fetch Order Tracking models delivery and refund as the separate facts they are. It writes the carrier-driven tracking status in one column and a refund state in another, derived from issue_status, the gmt_refund_* fields, and child orders — so a delivered-then-refunded order shows up as exactly that, not as a clean profitable sale.

Because the refund check runs on every batch and re-examines non-terminal orders, a cancellation that lands days after delivery still gets caught and written to the right column. You see the real picture: the parcel arrived, the money left, and your sheet says so plainly.

So the next time a delivered row shows Cancelled, trust it — that is the system earning its keep. If you want a sheet that surfaces those orders automatically instead of hiding them, try Fetch Order Tracking.

Frequently asked questions

Is a Delivered order marked Cancelled a bug in my sheet?

Almost always no. A row that shows Delivered in tracking and Cancelled or Refunded in the refund column is recording a delivered-then-refunded order, which is a real and fairly common state. It happens because delivery and refund are separate facts about the same order, and an order can be both delivered and refunded at once.

How does an order become both Delivered and Cancelled?

There are several common paths: an item-not-as-described dispute settled in the buyer's favour after delivery, a goodwill or partial refund on a delivered order, a child-order cancellation in a split shipment, or a supplier-initiated cancellation after the parcel already moved. In each case the honest representation is delivered and cancelled side by side, because the parcel arrived and the money was still returned.

Should I write a rule to make the two columns agree?

No, and this is the key mistake to avoid. A rule like clear the refund flag if delivered destroys the one signal you most need and lets your profit column quietly overstate the month. Keep a tracking status column driven by logistics and a separate refund state column driven by the money signals, so you can filter for Delivered and Cancelled and total the leakage. Fetch Order Tracking keeps these as separate columns and re-checks non-terminal orders so post-delivery refunds still land in the right place.

Related guides

• Refund detection beyond gmt_refund_payment_finish
• When AliExpress shows Delivered but your buyer disagrees
• Keeping cancelled and refunded orders from clogging your sheet

---