The refund button does not have an undo

Most things in a business system can be corrected. You edit the invoice, you change the address, you delete the duplicate. Refunds are the exception, and almost nobody finds that out at a calm moment.

Shopify's documentation is blunt about it: "You can't cancel or reverse a refund after you initiate a refund from your Shopify admin." Not "contact support". Not "within an hour". The money has left, and getting it back is now a conversation with the customer rather than an action in your admin.

That asymmetry deserves more respect than it usually gets, because refunds are also the operation people are most eager to automate. Returns are tedious, the customer is already unhappy, and a workflow that pays them back the moment the parcel is scanned looks like an obvious win.

What the click does besides moving money

A refund is at least three actions wearing one button.

It moves money. The obvious part, and the part everyone tests.

It moves stock. On Shopify the restock option "is selected by default and is available only when you track inventory for the items included in the order". So if you track inventory, the default behaviour of a refund is to put the item back on the shelf — whether or not it has physically come back. Refund a customer before the return arrives and your stock count now says you have something you do not have. Somebody will sell it.

It moves your fees. Fees come back in proportion: "If you refund 50% of an order's cost, then you're credited with 50% of the transaction fee to your account", and a full refund credits 100%. Useful to know, and it means the common assumption — that partial refunds are somehow worse value on fees — is not true on this platform. What is true is that your fee line moves whenever a refund does, which matters when you are reconciling a month rather than a sale.

That is one vendor's design. The point is not to memorise Shopify's rules but to ask the same three questions of whatever you use: does a refund touch stock, does it touch fees, and can it be undone.

Where automated refunds go wrong

The failure is rarely a wrong amount. It is a refund that is correct and duplicated, or correct and premature.

The duplicate. Someone refunds by hand while the workflow is also refunding, because the customer emailed and phoned. Two part-refunds, two stock movements, one very confusing statement line. This is the general problem of an automation doing the job twice, except here the second run cannot be rolled back.

The premature. The workflow triggers on "return label created" rather than "parcel received". Most customers post the parcel. Some do not, and you have paid them for goods you still do not have.

The invisible. The refund succeeded, the accounting sync did not, and the month's revenue is overstated by the amount you gave back. Nothing errored, because nothing failed — the two systems simply hold different facts, which is the everyday version of two systems disagreeing about the same field.

Rules worth having before you automate this

Automate the decision, not the payment, first. Let the workflow gather everything — order, return status, photos, policy check — and produce a one-line recommendation for a person. You keep the reversibility and lose almost none of the time saving. If refunds are rare, this is where to stop.

Trigger on the physical event. Parcel scanned as received, not label created, not customer said. The gap between those two states is where money leaves without goods arriving.

Decide the restock behaviour deliberately. If refunds happen before goods come back, the restock default is wrong for you and should be switched off, with a separate step when the item is actually inspected.

Put a ceiling on it. Automatic below an amount you can afford to be wrong about, a human above it. Most businesses know that number instinctively and never write it down.

Make double refunds impossible rather than unlikely. The workflow should check for an existing refund on the order immediately before acting, and stop if it finds one. This is the one guard that pays for itself, because it is the failure that cannot be undone.

Log every automatic refund somewhere a human reads. Not an alert per refund — a daily list. The point is that a wrong pattern gets noticed within a day rather than at month end.

The reconciliation question nobody asks first

Refunds are also the operation most likely to break your books quietly, because they move money in the opposite direction to everything else your automation was designed around.

Ask, for each refund path: which system learns about it, in what order, and what happens if the last one in the chain misses it. If the answer involves a person noticing a discrepancy at month end, the automation has moved work rather than removed it.

Working out where refunds touch stock, fees and the ledger — and which of those your current setup gets wrong — is one of the things a process audit covers: $299, three business days, and a written list of what happens on each path.

Related: what happens when an automation runs the same job twice covers duplicate runs in general. Refunds are the case where the duplicate cannot be taken back.