To keep on top of returns and refunds in Linnworks, open the Actionable Refunds list every morning and work through it oldest first: a refund you have booked does nothing until someone actions it, and until then it doesn't appear in any refund report. A person approves each refund; an assistant can build the list, pull up each order and draft the notes. Record a reason every time, and once a week look at which reasons and items keep coming back.
This post covers where returns and refunds live in Linnworks, what makes a good morning routine, who should decide what, and the weekly review that turns a pile of refunds into something you can act on.
Where do returns and refunds live in Linnworks?
Both start from an order that has already been processed, but they are separate records that do different jobs.
- A refund is money going back to the buyer. You add it on the order in Processed Orders: right-click the order, choose Action, then Refunds, and add either a full refund or one line at a time with an amount and a reason. Each item gets its own refund line, so you can refund a single item from a larger order (Linnworks help: Refunds).
- A return (an RMA booking in the Linnworks API) records goods coming back. A booking can be a return, an exchange or a resend, and it records which location the returned stock goes back to and how many units are scrapped instead of restocked (Linnworks API: ActionRMABooking).
Accepting a return booking can create a refund, but the two are not the same thing. A buyer can be refunded without sending anything back, and an exchange can come back with no refund at all. That is why a daily routine needs to look at both.
Booked is not the same as actioned
Adding a refund on the order books it. It is only processed once someone actions it from Orders, then Returns & Refunds, then Actionable Refunds, using View/Action and then Action. Linnworks is clear that a refund which hasn't been actioned won't appear in any refund-related report (Linnworks help: Refunds). Booked-but-forgotten refunds are the easiest thing to lose track of, and the reason the morning list matters.
Actioning sends the refund to the sales channel where the channel supports it, along with the free-text reason, which is passed to the channel (Linnworks API: ActionRefund). In most cases, refunding in Linnworks does not cancel the order on the channel itself; that still has to be done on the channel (Linnworks help: Refunds).
How to keep on top of returns and refunds in Linnworks every day
A routine that takes a few minutes a day beats a long session once a fortnight, because the oldest refunds are the ones customers chase. Here is one that works from what Linnworks shows you.
1. Start with the Actionable Refunds list
Open Actionable Refunds first thing. It lists the booked refunds still waiting, and each one carries a status: Linnworks uses Open, Pending, Processed, Error and Error Acknowledged (Linnworks API: GetActionableRefundHeaders). Each refund carries the date it was created, so work from the oldest. Anything in an error state goes to the top, because it needs a person to read the error before it can move.
2. Check each refund against the order
Before you action anything, open the processed order and look at the refunds already on it. Two errors come up often enough that Linnworks documents them (Linnworks help: refund amount and already-refunded errors):
- "Already refunded on the channel". The line was refunded directly on the marketplace, by a member of staff or through a buyer's claim. Linnworks won't create a duplicate.
- "Amount exceeds the amount available to refund". Earlier refund requests count against the line even if nobody has actioned them yet, so a second booking can push it over.
Both point to the same habit: one person owns each refund, and they check what is already on the order before adding anything.
3. Book in what has come back
Next, deal with returns that have physically arrived. Accept the booking, send good stock back to the right location and record anything that can't be resold as scrapped. If the stock count is wrong after a return, it will show up later as an oversell, so this step protects tomorrow's orders as well as today's customer.
4. Write the reason down every time
Linnworks asks for a reason when you add a refund. Treat it as a field that matters, not a box to tick. "Customer changed mind", "arrived damaged" and "wrong item sent" lead to very different fixes, and a vague reason tells you nothing at the end of the week. Agree a short list of reasons with whoever handles refunds, so the same problem is always described the same way.
Who decides: people approve, assistants prepare
Refunds move money, so a person should action every one. Linnworks' own API lists approving refunds as a separate permission from viewing them (compare GetActionableRefundHeaders with ActionRefund), so seeing the list and approving a refund are not the same right.
An AI assistant fits on the preparing side of that line. It can produce the morning list, fetch each order and the refunds already on it, flag the ones in error, and draft a note to the customer for a person to check and send. It should not action the refund. If you are deciding where else to draw that line, how much an AI agent should be allowed to do sets out a simple act, draft or escalate test.
The Hosted MCP Server for Linnworks is built that way. Its returns and refunds tools only read: they search the returns or refunds history between two dates, show every refund on a processed order, and list the refunds still waiting for action. It has no tool that creates or actions a refund. One of the example questions on the Hosted MCP Server for Linnworks page is "Give me this morning's list of refunds that need action."
A weekly look at repeat reasons and SKUs
The daily routine clears the queue. The weekly review is where you find out why it filled up. Once a week, pull the refunds and returns from the last seven days and group them two ways:
- By reason. Which reasons came up most? A rise in "arrived damaged" is a packing question; a rise in "not as described" is a listing question.
- By SKU. Which items appear more than once? One product with repeated returns for the same reason is usually worth a look at the photos, the description or the supplier.
Linnworks' Query Data includes ready-made scripts for this, among them "Order item returns - Grouped by Return Category", "Refunds - Order Item Refunds (Actioned)" and "Order item return,resend,refund - Details" (Linnworks help: list of Query Data scripts). Because unactioned refunds don't appear in refund reports, run the daily routine before the weekly one, or the numbers will be short.
If you search the history through the API, or through the Hosted MCP Server, each search covers at most three months, so a longer look back means several searches. You can search by the date a return or refund was received, processed, booked or actioned.
Repeat refunds also say something about customers. If the same buyers keep coming up, building a customer database from your Linnworks orders shows how to see the full picture of who is buying and how often.
A short checklist
- Every morning: open Actionable Refunds, errors first, then oldest first.
- Before actioning: check the refunds already on the order and on the channel.
- Book in arrived returns, to the right location, with scrapped units recorded.
- Give every refund a clear reason from an agreed list.
- Remember the channel: cancel there if the order needs cancelling.
- Once a week: group by reason and by SKU, and pick one thing to fix.
Start tomorrow with one list: the refunds still waiting for action. Clear it oldest first, write a reason for each one, and by the end of the week you'll know which problem to fix first.