Amazon Tutorials

Amazon FBA Returns Data in Google Sheets: What It Shows and What to Do With It

Last updated -

May 8, 2026

Article Summary

✅ FBA customer return data does two jobs: it identifies which refunded units qualify for a reimbursement claim, and it surfaces ASIN-level return rate problems before Amazon flags your account.

‍

✅ The data you need for both jobs sits in three Amazon reports. Cross-referencing all three manually against stale CSVs is where teams miss claims and miss product problems.

‍

✅ When FBA returns data lives in a live Google Sheet, your team catches unfiled claims, spots return rate trends by SKU, and stops learning about product problems from account health warnings.

Since 2012, for the first few years, we treated return data the way most sellers do: a number you check when something feels off. We weren't tracking return rates by ASIN on any schedule. We weren't cross-referencing refunds against what actually came back to our inventory. We were reacting.

Then one product started returning at double the rate of everything else in our catalog. We found out from an account health notification, not from our own data. By then we'd shipped two more inbound orders of the same unit. The return data was sitting in Seller Central the whole time. We just weren't looking at it on a schedule.

That's the real cost of not having FBA returns data in front of your team. Not just missed reimbursement claims. The early warning system you didn't use.

Where Sellers Lose Money on FBA Returns

| Root Cause | What Happens | What It Costs | |---|---|---| | Not checking if refunded items came back | Customer return claim window passes unfiled | Full refund value absorbed, no recovery | | Reviewing return data quarterly | Return rate spikes go unnoticed until account health flags them | Suppressed listings, lost Buy Box, emergency decisions | | No SKU-level return rate tracking | High-return ASINs stay in rotation alongside healthy ones | Compounding refund costs on a product that should be fixed or pulled | | Cross-referencing three reports by CSV | Data is stale by the time the team reviews it | Claims filed on wrong data, units already restored or reversed | | Treating all return reasons the same | Defective vs. not as described vs. unwanted need different responses | Wrong fix applied, return rate does not improve |

Return Data Is Not a Reimbursement Tool

You're looking at return data to find claims. That's the wrong starting point.

Reimbursement claims are the output of a return that went wrong in a specific way: Amazon refunded the customer and either failed to recover the unit within 60 days, or recovered it in unsellable condition through Amazon's fault. That's one scenario inside a larger dataset.

The full return dataset tells you something more valuable: which products your customers are rejecting and why. A 3% return rate on one ASIN and a 14% rate on another is not a reimbursement problem. It is a product problem that costs you on every unit sold and will eventually cost you the listing. The teams who catch that at 14% fix it. The teams reviewing data quarterly catch it at 22% after Amazon has already taken action.

Return data in a live sheet catches the product problem and the claims opportunity at the same time. Running them as separate processes means doing the same data work twice.

What FBA Customer Return Data Actually Contains

When FBA customer return data flows into Google Sheets through Gorilla ROI, your team works from structured columns updated on a set schedule. Here is what the data contains and what each field does:

| Column | What It Shows | How Your Team Uses It | |---|---|---| | return_date | Date Amazon processed the customer return | Cross-reference against the 60-day reimbursement window | | order_id | The original customer order ID | Link returns to specific transactions for claim filing | | sku | Your seller SKU | Filter by SKU to calculate return rate per product | | asin | Amazon product identifier | Spot ASINs with abnormal return rates across your catalog | | fnsku | Fulfillment network unit identifier | Required field for any reimbursement claim submission | | quantity | Units returned in this transaction | Track return volume trends over time | | return_reason | Customer-stated reason: DEFECTIVE, NOT_AS_DESCRIBED, UNWANTED_ITEM, etc. | Identifies fixable product or listing problems vs. buyer behavior | | status | UNIT_RETURNED_TO_INVENTORY, UNIT_DAMAGED, REIMBURSED | Shows disposition: sellable return vs. reimbursable event | | reimbursement_id | Populated if Amazon already paid a claim | Prevents duplicate filing on units already settled |

The status column is where most teams leave money. UNIT_RETURNED_TO_INVENTORY means the unit came back sellable and Amazon put it back in your stock: no claim needed. UNIT_DAMAGED means it came back unsellable. REIMBURSED means Amazon already settled it. The unclaimed value sits in the rows where no reimbursement_id exists and the unit never came back to inventory. Those are your open customer return claims.

The Two Jobs This Data Does

Job 1: Feed the Reimbursement Claim Process

Per Amazon's FBA customer returns policy, you can file a customer return claim no sooner than 60 days and no later than 18 months after the customer refund. Amazon uses the 60-day window to attempt to recover the item from the customer.

The five-step eligibility check before filing any customer return claim:

| Step | What to Confirm | Where to Find It | |---|---|---| | 1 | Amazon refunded or replaced the item on your behalf | Manage FBA Returns report | | 2 | Unit was not returned to your inventory in sellable condition | FBA Customer Returns report, status column | | 3 | No existing reimbursement on record for this unit | Reimbursements report, reimbursement_id column blank | | 4 | Return date is more than 60 days ago | return_date column vs. today's date | | 5 | Return date is within 18 months | return_date column vs. claim window cutoff |

This five-step check takes under 10 minutes per batch when the data is already in your sheet. Running it against exported CSVs means re-downloading three separate reports, aligning date columns, and doing cross-sheet lookups before you can identify a single claimable unit.

Job 2: Surface ASIN-Level Return Rate Problems

This is the job return data does that most teams ignore. The return_reason column is a product feedback system that bypasses the review process entirely. Customers who return items do not always leave reviews. They always select a return reason.

When you filter return data by ASIN and group by return_reason, patterns surface fast. Five returns citing NOT_AS_DESCRIBED on the same ASIN in one month points to a listing problem. Eight returns citing DEFECTIVE points to a manufacturing or packaging issue. Twelve returns citing UNWANTED_ITEM on a product with clear purchase intent points to a traffic problem: wrong customers finding the listing.

None of that shows up in your sales report. All of it shows up in your return data. Teams who review return rates by ASIN weekly catch these patterns at 8 to 10 units returned. Teams who don't catch them after Amazon has already factored the return rate into the listing's performance metrics and account health score.

Manual CSV vs. Live Sheet

| Task | Manual CSV Method | Gorilla ROI in Google Sheets | |---|---|---| | Identifying unclaimed return events | Download 3 reports, align dates, cross-reference status column | Filter status column in-sheet: reimbursement_id blank = open claim | | Tracking return rate by ASIN | Export returns CSV, build pivot table manually each review cycle | ASIN column already structured, filter by date range in-sheet | | Catching the 60-day claim window | Manual date calculation against return_date column | return_date visible in-sheet, flag rows approaching the window | | Spotting return reason trends | Re-download and reformat reports each time | return_reason column filters by ASIN on any date range | | Confirming no duplicate claims | Open Reimbursements report separately from returns data | reimbursement_id column cross-referenced in the same sheet |

Key Terms

| Term | Definition | |---|---| | FBA Customer Return | A unit your customer returned on an FBA order. Amazon processes the return, determines the unit's condition, and either restores it to your inventory, marks it unfulfillable, or reimburses you. Not all customer returns result in a reimbursement claim. | | Return Reason Code | The reason the customer selected when initiating the return: DEFECTIVE, NOT_AS_DESCRIBED, UNWANTED_ITEM, WRONG_ITEM, and others. Grouped by ASIN, return reason codes identify product or listing problems before they affect account health metrics. | | Return Disposition | The status Amazon assigns to a returned unit. UNIT_RETURNED_TO_INVENTORY means the unit is sellable and back in your stock. UNIT_DAMAGED means it came back unsellable. REIMBURSED means Amazon already settled a claim. Rows with no reimbursement_id and no inventory restoration are open claim opportunities. | | 60-Day Window | The minimum waiting period before filing a customer return reimbursement claim. Amazon uses this period to recover the item from the customer. Filing before 60 days results in automatic rejection. | | Return Rate | The percentage of units sold that are returned by customers, calculated per ASIN. Amazon monitors return rates as part of listing and account health evaluation. A rising return rate flagged by your own data is recoverable. A rising return rate flagged by an Amazon account health notification is not. |

FAQ

What is FBA returns data in Google Sheets?

‍FBA returns data in Google Sheets is Amazon's record of every customer return on your FBA orders, including return date, reason, quantity, ASIN, and disposition status, connected to a live spreadsheet that refreshes on a schedule. When this data is in Google Sheets, your team reviews return events, identifies open reimbursement claims, and tracks return rates by SKU without downloading separate reports from Seller Central.

Which Amazon reports contain FBA customer return data?

‍Three reports cover customer return data: the FBA Customer Returns report shows unit-level disposition and return reasons, the Manage FBA Returns report shows refund and replacement status by order, and the Reimbursements report shows whether Amazon has already paid a claim for the unit. All three are required for the pre-filing eligibility check on any customer return reimbursement claim.

How do I track FBA return rates by SKU in Google Sheets?

‍Filter your return data by ASIN or SKU column and group by date range. Return rate per ASIN is the number of units returned divided by units sold in the same period. When both your sales data and return data are in the same Google Sheet on a shared refresh schedule, you build this view once and it updates automatically. Tracking it manually means re-downloading both datasets every review cycle.

How do I know if a returned FBA unit qualifies for a reimbursement claim?

‍Four conditions must all be true: Amazon refunded or replaced the item on your behalf, the unit was not returned to your inventory in sellable condition within 60 days of the refund, you have not already been reimbursed for that unit, and you are filing between 60 days and 18 months after the refund date. The full eligibility rules and claim windows for all four reimbursement claim types are in the FBA inventory reimbursement policy guide.

What return reasons should I act on first?

‍DEFECTIVE and NOT_AS_DESCRIBED require the fastest response because they signal a product or listing issue that compounds with every additional unit sold. UNWANTED_ITEM at a high rate on a product with clear purchase intent signals a traffic or targeting problem. WRONG_ITEM in volume signals a fulfillment or labeling error. Act on reason codes that cluster on the same ASIN within a short window. Isolated returns across different reason codes rarely indicate a systemic problem.

How does FBA returns data connect to the reimbursement recovery system?

‍FBA returns data is the input to the customer return claim type within the broader reimbursement recovery system. Identifying which return events are claimable is the detection step. Filing and following up on those claims is the case management step. The full recovery system covering all four claim types and how to structure it at scale is in the Amazon FBA reimbursement recovery guide.

Returns Data Review Checklist

Run this weekly alongside your reimbursement review:

Filter FBA Customer Returns data by the past 7 days and confirm all new return events are captured
Check status column: flag rows showing no reimbursement_id and unit not restored to inventory
Confirm return_date on flagged rows is past 60 days and eligible for customer return claim filing
Confirm return_date on flagged rows is within 18 months and still inside the claim window
Group return_reason by ASIN for the past 30 days and flag any ASIN with 5 or more returns citing the same reason code
Cross-reference flagged ASINs against active listings and confirm no suppression or account health action is already in progress

A return rate problem caught at 8 units is a listing fix. Caught at 40 units it is an account health event.

FBA customer return data in Google Sheets does two jobs no other report does at the same time: it feeds the reimbursement claim process with the unit-level detail Amazon requires, and it surfaces ASIN return rate problems before they reach account health thresholds. Both jobs require the same data, refreshed on the same schedule, reviewed by the same person every week.