Refunds

The case for binary Yes/No refund columns

There is a tempting moment, early in building a tracking sheet, when you decide your refund column should be smart. Not just a flag — a taxonomy. Full refund, partial refund, refund processing, dispute opened, cancelled before dispatch, returned-then-refunded. You build the dropdown. You feel organised.

Six months and a thousand orders later, that column is a swamp. Half the rows are mislabelled, your formulas choke on edge cases, and you still cannot answer the only question that matters at a glance: did this order cost me money or not? The fix is to go the other way. Make it binary.

Why detailed refund categories rot

The problem with a granular refund column is not that the categories are wrong. It is that they are unstable. A single AliExpress order can pass through several of them in a week — issue_status opens a dispute, then gmt_refund_create fills in, then gmt_refund_payment_finish finalises it. Which label is correct? All of them, in sequence. None of them, right now.

• A "refund processing" order becomes "refunded" — but only if something re-checks it. Most sheets never do, so it freezes on the stale label.
• A delivered order that gets refunded looks like a contradiction, so people invent a special category for it and then forget the rule.
• Partial refunds, child-order refunds, and currency rounding all fight your dropdown. The taxonomy keeps growing.

Every category you add is another state that has to be kept current by hand. Multiply that by your order volume and you have built yourself a part-time job you did not want.

What binary actually buys you

A binary column answers one question and answers it forever: has any money come back on this order? Yes or No. That is the question that drives every decision you actually make — whether to count the sale as profit, whether to chase the supplier, whether to stop re-shipping.

You do not need to know the flavour of a refund to act on it. You need to know it happened. Everything else is detail you can look up on the rare day you need it.

With a clean Refunded: Yes/No column, your profit math becomes trivial: sum the earnings where Refunded = No. Your queue becomes trivial: ignore the Yes rows, they are settled. And the column never lies, because there is no in-between state for it to get stuck in.

But binary only works if detection is bulletproof

Here is the catch, and it is the whole catch. A Yes/No column is only as trustworthy as the logic behind the Yes. If your refund check looks at a single field, binary becomes dangerous — a false No is worse than a vague label, because you will confidently book a loss as profit.

Real AliExpress refunds hide in several places at once. A delivered-then-refunded order will not show up if you only watch the shipping status. A silently cancelled child order will not show up if you only read the parent. To set Yes correctly you have to check, together:

1. issue_status for an open or resolved dispute,
2. the gmt_refund_* timestamps for a completed money-back,
3. child orders, in case the refund landed on a split line rather than the parent.

Get those three right and one flag carries all the meaning you need. This is exactly the refund logic Fetch Order Tracking runs on every fetch — it catches delivered-then-refunded and silently cancelled orders that a single-field check sails straight past, then collapses the result into one honest column you can actually trust.

Keep the detail — just not in the working column

None of this means you should throw away the underlying data. The right pattern is layered: a binary column you live in every day, and the raw fields parked in columns you never look at until an audit or a dispute forces you to. Your eyes work off the flag; the evidence sits one click away.

• Working layer: Refunded: Yes/No. Drives profit, drives the queue, drives your morning scan.
• Evidence layer: raw issue_status, refund timestamps, the carrier delivery-proof link. There when you need to win a case, invisible when you don't.

That split is the whole philosophy: humans need a flag, machines keep the detail. If you want to go deeper on getting the Yes right, read our piece on how proper dropshipping refund detection works, and if you have seen a delivered order marked Cancelled and assumed it was a bug, our mapping guide explains why those edge cases are real. Or skip the spreadsheet engineering entirely and let Fetch Order Tracking populate the column for you.

Frequently asked questions

Is a binary Yes/No refund column really better than detailed categories?

For day-to-day work, yes. A binary column answers the only question that drives your decisions — did money come back on this order — and it never freezes on a stale label the way a granular dropdown does. You can still keep the detailed fields parked in evidence columns for the rare day an audit or dispute needs them, but your eyes and formulas should live off the flag.

How do I set the Yes correctly so the binary column can be trusted?

The flag is only as good as the logic behind it, and a single-field check is not enough. You have to check issue_status for a dispute, the gmt_refund timestamps for a completed money-back, and child orders in case the refund landed on a split line rather than the parent. Fetch Order Tracking runs exactly this multi-field check on every fetch, so it catches delivered-then-refunded and silently cancelled orders a one-field check would miss.

Will a binary column miss partial refunds?

A binary column flags that a refund happened, not how much. For most sellers that is the right trade, because the action — stop counting the sale as clean profit and review it — is the same whether the refund was partial or full. Keep the exact amount in your evidence layer alongside the raw timestamps, so the Yes triggers the review and the detail is one click away when you need it.

Related guides

• Refunds you didn't see: catching cancellations on already-delivered orders
• Refund detection beyond gmt_refund_payment_finish
• Why your refund column shows Cancelled for a delivered order

---