Ecommerce Return Fraud: Find Repeat Abusers in Your Returns Data

Export your orders and returns, replace customer names with an ID, and ask ChatGPT or Claude to calculate each customer's return rate, value returned and days to return. Flag customers who stand far above your shop's average for a person to review. Never let the analysis, or the AI, ban anyone: it points to who to look at.

Most return problems are not fraud. They are sizing, slow delivery and products that did not match the photos. Abuse is a small slice, often a handful of accounts behind a large share of the lost value. Your job is to separate the slice from the rest, which a returns export lets you do in an afternoon, and to do it fairly enough that you would be comfortable explaining each flag to the customer.

Follow me on Instagram@sagnikteaches

The kinds of return abuse worth looking for

Name the patterns before you search for them, because each leaves a different trace in the data.

Connect on LinkedInSagnik Bhattacharya

• Wardrobing: buying an item, using it once (an outfit for an event, a camera for a trip) and returning it. Traces: returns a few days after delivery, event-type products, items back with signs of use.
• Serial returning: a customer who returns most of what they order, shop after shop. Traces: high return rate over many orders.
• Item-not-received and empty-box claims: saying a parcel never arrived or contained nothing, then keeping the goods. Traces: repeat claims from one customer or address, usually on higher-value items, often with a tracking record that says delivered.
• Swap returns: sending back a different or cheaper item in the box. Traces: warehouse condition notes that say "wrong item received" or serial number mismatches.
• Policy gaming: repeatedly using a free-return window to borrow items, or buying during a promotion and returning for full price. Traces: returns clustered at the end of the window, price differences.

Honest patterns look alike on a first pass. Bracketing (ordering two or three sizes to keep one) produces many returns from a customer who keeps something. Gift returns come from a different person than the buyer. The following sections include a way to tell them apart, which is the difference between a fair flag and an insult.

Subscribe on YouTube@sagnikteaches

The shop and the data

The figures below are illustrative. Imagine a small online clothing and accessories shop with about 1,200 orders a month and a return rate of 14% of orders. Over six months that is 7,200 orders and about 1,010 returns. The owner suspects that a small group is responsible for a share of the losses, because the same few surnames keep appearing in the return emails. She wants to check without accusing anyone.

Two exports are needed. The orders export lists every order line: order number, date, customer identifier, product or SKU, quantity, price, delivery date if you have it. The returns export lists each return: order number, product, return date, reason code, refund amount and, importantly, the warehouse condition note if your team records one. Shopify's help page notes that its order export puts extra line items on their own rows and leaves many fields blank on those rows, so fill the order number down before you join anything.

Join the two into one table with a spreadsheet lookup (match on order number plus SKU). Each row is an order line, with return columns blank when nothing came back. Then replace the customer name and email with a short ID. A simple way: copy the email column to a new sheet, remove duplicates, number the rows, and look the ID up for each order. Delete the name, email, address and phone columns from the file you share, and keep the lookup sheet to yourself, because it is the key that maps IDs back to people.

If the joining step stumbles, the tutorial on cleaning messy data covers duplicate rows and mismatched formats, which are the usual reasons a lookup returns nothing.

Ask for the numbers, one customer per row

The first question is about customers, not orders. Give the assistant the joined, anonymised file and ask for a customer summary table. Both assistants need their file-analysis features for this: ChatGPT's data analysis, which is limited on the Free plan, or Claude's Code execution and file creation setting, which Anthropic's help centre lists on every plan. This prompt works:

The attached file has one row per order line with: customer_id, order_id, order_date, delivery_date, sku, category, price, returned (Y/N), return_date, return_reason, refund_amount, warehouse_condition (blank if not recorded).
Make a table with one row per customer_id showing: number of orders, number of lines, lines returned, return rate (lines returned / lines), value ordered, value refunded, average days from delivery to return, and the count of returns with warehouse_condition mentioning "worn", "used", "marked" or "missing tags".
Also give the shop-wide return rate and the median return rate among customers with 3 or more orders.
Sort by value refunded, show the top 25 customers with at least 3 orders, and state how many customers were excluded for having fewer than 3 orders. Do not guess missing data: say what you could not calculate.

Before you read the result, write down your own guess of which five customers will top the list. Owners are often surprised: the names they remember are the loud ones from the inbox, not the quiet accounts that return a parcel a fortnight without a word. Comparing your guess with the table is a quick way to check whether your memory of difficult customers is steering decisions that the data should make, and it is a reminder that the point of the exercise is to replace impressions with counts you can show to a colleague.

Check the totals first. The sum of all returns across customers should match the number of returned lines in your file, and the shop-wide return rate should match a pivot-table count. If they differ, the join is off, and every later number is wrong. This single check catches most errors before you read the table.

An illustrative extract from the result for the clothing shop:

Against a shop-wide return rate of about 14%, the first three stand out, but they are not the same. C-0412 and C-1534 return quickly, with used-condition notes in most returns: that is the wardrobing pattern, and both deserve a person's attention. C-0987 returns three-quarters of what they buy, but at nine days on average, with no condition issues and a low value: the pattern of a customer with a sizing problem, perhaps bracketing. Treating C-0987 like C-0412 would be a mistake, and probably an unfair one.

Separate fit problems from fraud before you flag anyone

A high rate has three common innocent causes, and your second prompt should test each before anyone is labelled.

Bracketing. Ask whether returned lines are the same style in a different size from a kept line in the same order. If most of a customer's returns are siblings of an item they kept, they are fitting, not abusing. The same logic applies to colour choices.

Product faults. A customer whose returns all carry the reason "faulty" may have received a bad batch. Look at whether the same SKU is returned by many customers for the same reason. If it is, the defect belongs to your supplier, as the tutorial on spotting patterns in complaints, returns and defects shows.

Sizing and listing errors. If one product has a return rate three times its category average, the listing is the problem, and the customers who bought it are not. Remove those lines before ranking customers.

Using the same file, for each of the top 25 customers by value refunded, tell me:
(a) how many returned lines are the same style_id as a kept line in the same order (bracketing);
(b) how many returned lines are SKUs where more than 25 percent of ALL customers returned that SKU (product problem);
(c) how many returned lines are non-excluded, i.e. neither (a) nor (b).
Then re-rank customers by (c). Show the first 10 with their return rate after excluding (a) and (b).

After this step the clothing shop's list shrinks. C-0987 drops out: five of the six returns were bracketing. C-0412 and C-1534 stay, because their returns were mostly single-item, fast and flagged as used. Two more accounts, with similar quick, used-condition returns, stay on the list beside them. What is left is four accounts out of about 3,100 customers, and they account for roughly $1,800 of refunds in six months. That is real money for a small shop, and a far smaller group than the owner feared.

Look at timing, because wardrobing has a calendar

Wardrobing follows events. A customer who buys a dress on a Thursday and returns it the following Tuesday has had it for a weekend. Ask for two timing measures per flagged customer: the days between delivery and return, and the days between the return and the end of your return window. Returns clustered within three days of delivery for event categories, or crowding the last day of the window, suggest borrowing. The tutorial on automating returns and refunds with clear rules shows how to set a window your team can apply without argument.

One more pattern worth asking about: the same customer ordering again right after a return, same category, same style. Returning a dress and buying a similar one is more likely a fit search than fraud. Returning a dress and buying a near-identical dress in a bigger size is bracketing in sequence. Do not flag it.

The condition notes are the strongest evidence, and they come from your warehouse, not from the data. If your team does not record them, start now with a simple dropdown on the returns form: as new, tags missing, worn or marked, damaged, wrong item. A month of those notes makes later analysis much more reliable. Without them, the export shows only that things came back, not what came back.

Item-not-received claims need a different analysis

Everything above works on returns, where the goods come back. A "never arrived" or "box was empty" claim brings nothing back, so the data you need is different: the delivery record, the claim date and the pattern across claims. Add three columns to a separate sheet, one row per claim: order value, carrier status (delivered, signed for, left at address, in transit) and whether a photo or signature exists. Then ask for a pattern check.

Here are 40 item-not-received claims from the last 12 months, with customer_id, order_value, carrier_status, delivery_proof (signature, photo, none), days_from_delivery_to_claim. List customers with 2 or more claims, the share of claims where carrier_status was "delivered" with proof, and the median days to claim. Do not accuse anyone; describe patterns and say which are too few to judge.

A typical honest result is that most repeat claimants have a plausible cause, such as a building with a shared entrance, and only one or two accounts show repeat claims on proof-of-delivery parcels. For those, the response is practical: switch the account to signature-on-delivery for high-value items, or ship to a collection point. These steps cost little, they do not accuse, and they take away the opportunity. Document each claim and each step in the log so you can show your reasoning if a dispute arises later, as covered in the tutorial on a chargeback response template.

A short checklist keeps the review fair: has the customer had a delivery problem before that the carrier confirmed? Is the address one with known access problems? Was the parcel high value and left without a signature? Honest answers to those three often explain a claim better than suspicion does. Fraud exists, but the cost of wrongly refusing an honest customer who truly never received a parcel is a lost customer and a bad review, so build the check to look for reasons as well as red flags.

Flag for review, with a written rule

Turn the analysis into a flag that a person reviews, using a rule you could explain to a customer. For the clothing shop:

• At least three orders and at least four returned lines in six months, after removing bracketing and product-fault lines.
• A return rate above 50% after those removals.
• At least two returns with a worn or marked condition note, or returns within three days of delivery on event categories.

A customer must meet all three before a person looks. The flag does not decide anything. The reviewer opens the account and reads the order history, the notes and the photos taken at the warehouse, and decides one of four things: no action, a friendly reminder of the policy, a limit on future return types (such as store credit instead of refund), or a request that the customer stops buying from the shop. Only the last two change the customer's position, and both should follow a written policy and a chance to reply.

It helps to write the policy so it can bear this weight. A sentence such as the following in your returns page gives you a fair basis, subject to review by a qualified adviser because rules on returns vary by place and by the kind of sale:

Items must be returned unused and in their original condition, with tags attached. Where an item is returned worn, marked or damaged, we may refund a reduced amount or decline the refund. If an account shows a pattern of returns outside these terms, we may offer store credit instead of a refund or decline future orders. This does not affect any rights you have by law.

The last sentence matters because in many places the law gives consumers return rights that a shop's policy cannot remove. A shop that tries to override them with its own wording invites a complaint. If you are unsure what your terms may say, ask a qualified adviser before you publish them.

The first contact: a message that does not accuse

For a flagged account that you have decided to approach, the first message should be factual and brief. Ask the assistant for a draft, then edit it:

Write a short, polite email from a small online shop to a customer whose recent returns have mostly been items marked as used. Do not accuse them. State the facts: number of returns in the period and that some were received worn. Remind them of the return condition in our policy (quote below). Say that for future returns we may offer store credit where an item arrives used, and invite them to reply if anything is incorrect. Under 120 words. Use [first name], [number] and [policy sentence] as placeholders.

A usable result reads: "Hi [first name], we noticed that [number] of your recent returns arrived with signs of use, which our returns policy does not cover: [policy sentence]. For future returns of this kind we may offer store credit instead of a refund. If any of this looks wrong to you, please reply and we will look again. Thanks, [your name]." Send it only after a person has checked that the facts in it are true for that customer.

A flag that turned out wrong

An illustrative case shows how this goes wrong. A shop flagged an account with eight orders and six returns in four months, all quick, with two used-condition notes. The owner was ready to send the warning. A quick look at the order notes before sending showed that the account belonged to a stylist who bought for photo shoots and returned items afterwards, and had spoken to the shop's owner about it at the start. The shop had an informal arrangement that nobody had written down.

The repair was simple: a "known accounts" list in the review sheet, with the reason and the owner's name, checked before any flag goes out. Now the shop also has a formal wholesale-sample route for customers like this, with a short written agreement. The lesson is to have the person who reviews the flag check the account's context, because the data cannot know about arrangements made in conversation.

Keep a log, and measure whether it worked

Record every flag in a simple log: date, customer ID, the numbers that triggered it, what the reviewer decided, and what happened next. After three months compare your key figures with the six months before: return rate across the shop, value refunded on returns with used-condition notes, and the number of customers who ended up restricted. Count appeals, too. A flag that is overturned on appeal tells you your threshold is catching honest customers, and you should raise it.

A small sum shows whether the work pays. If the four flagged accounts cost about $1,800 over six months, then even if the review brings two of them into line and you win back half, you save about $450 over the same period, for roughly three hours of work a quarter. That is not a transformation. It is a tidy gain, and the larger payoff is usually the product and sizing fixes the same data reveals. If you also want the payment side of the shop covered, the tutorial on a DIY fraud review queue uses the same flag-and-review approach before orders ship.

Fix what the data says is not abuse

Most of the surplus returns in the clothing shop's file were not from flagged accounts. They came from three products whose return rate was over 30%, with the reason "too small". Fixing the size charts, with measurements in centimetres and inches and a note on how each style runs, would cut more returns than any amount of policing. Where a category suffers from fit problems, a fit tool may pay for itself, as the example in the tutorial on an AI fit plugin for a shoe shop explores. Do the product fixes first, rerun the returns analysis in a quarter, and you will find the abuse list is shorter and clearer, because the noise around it has gone.

Questions about spotting return abuse

What return rate counts as suspicious?

There is no universal figure. Compare each customer with your shop's own average and with customers who bought similar items. A customer with five orders and four returns is unusual in almost any shop, but a customer buying two sizes to find one that fits can look the same. Use rate as a prompt to look, never as proof.

Is buying two sizes and returning one abuse?

Usually not. It is called bracketing, and it is a normal response to uncertain sizing. Treat it as abuse only when the pattern is extreme and repeated, or combines with signs such as used items. If bracketing is common, fix your size guidance and consider a fit tool rather than penalising customers.

Can I ban customers who abuse returns?

Restricting future orders is a business decision, but it carries risk. Never let a spreadsheet or an AI make it. A person should review the evidence, give the customer a chance to respond, apply a written policy, and keep a record. Ask a qualified adviser about your selling rules, especially where consumer return rights are set by law.

Can I upload my returns export to an AI assistant?

Only after replacing names, emails and addresses with a customer ID, and keeping the order, item, dates, reason and condition columns. Check your assistant's data settings and your privacy notice. If in doubt, run the same counts in a spreadsheet pivot table.

Further reads

• AI Accounting for Ecommerce: Reconciling Payouts and Fees — Match refunds and payouts so losses are visible.
• How to Use Shopify Sidekick to Run Your Store Faster — Ask Shopify's own assistant about orders and returns.
• Your First 30 Days of AI Customer Support for an Online Shop — Handle return questions in your first month of AI support.
• Best AI Tools for a Small Ecommerce Store: 7 Worth Paying For — Which paid tools are worth buying for a small store.
• Best AI for Ecommerce Operations: Orders, Stock, Returns, Suppliers — See where returns analysis sits in daily operations.
• Ecommerce AI Chatbot Examples: 7 Store Conversations to Copy — Return conversations that collect reasons and hand over cleanly.
• AI Voice Agent for Ecommerce: Cost per Order-Status Call — Cost per order-status call from listed per-minute prices, set against a part-time hire, with lookup limits and handover rules.
• Candle Troubleshooting Replies: Tunnelling, Sooting, Weak Scent — Cause lists, care wording, replacement rules and reply templates for tunnelling, sooting and weak scent, drafted with AI.
• PayPal Dispute Response for Sellers: Evidence Pack Drafted With AI — A seller-side PayPal dispute response: evidence by dispute reason, a reply template and AI prompts that keep the pack honest.
• Shopify Profit Report With Claude: Add Ad Spend, COGS and Returns — Join four exports in Claude to see profit per order after ads, costs, shipping and returns, with a full worked month.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Shopify Help Centre page on exporting orders (line-item layout); ChatGPT pricing page and Anthropic help centre on file analysis; no external return-rate statistics are used. Thresholds and all store figures are illustrative and should be set from your own data.