How do refunds and order cancellations affect the accuracy of my ROAS reporting?

What to check before you touch anything

• Is the moment of refund reflected in the passed conversion value at all? If value is passed once, when the order is placed, and never adjusted afterward, ROAS in Google Ads will be systematically overstated relative to the business's real revenue, by the full amount of refunds.
• Is the conversion action using dynamic (transaction-specific) value rather than a static default? Without that, it's technically impossible to apply a Restatement/Retraction adjustment at all, regardless of intent.
• What's the real refund/cancellation rate by product category? In some categories (apparel, "try before you keep" products), refund rates can be high enough that ignoring them turns into a material distortion of ROAS, not a cosmetic one.
• How quickly, on average, does a refund happen relative to the 54-day window available for adjustments? If the typical refund happens, say, 60–90 days out (common for seasonal goods, gifts, or major appliances), part of your refunds will physically fall outside the adjustment window even with everything set up correctly.
• Is there an actual operational process in place for submitting adjustments (who uploads refund data to Google Ads, and how often — manually, via a scheduled script, via a third-party app)? Without a recurring process, refunds simply won't show up, even if the mechanism itself is technically available.
• Does the refund rate differ meaningfully across segments (product category, geo, device)? If so, ROAS is distorted unevenly across those segments, and the blended aggregate number can mask that some segments are actually less profitable than they appear.

A quick primer: how Google Ads lets you adjust a conversion after the fact

Google Ads supports a dedicated mechanism called Conversion Adjustments (uploaded via the interface, the Google Ads API, or Google Ads Scripts), which lets you retroactively correct an already-reported conversion without creating a new record. It comes in two practical types:

• Retraction — fully zeroes out a conversion, setting both its count and value to zero. Used when an order is fully cancelled or returned.
• Restatement — doesn't remove the conversion entirely, but changes its value to a new figure (say, from 100 down to 70, for a partial refund).

There are two important technical limits worth knowing up front:

1. An adjustment can only be submitted within 54 days of the original conversion — after that, Google won't accept it (the conversion is treated as "expired" for adjustment purposes).
2. An adjustment can't be applied to a conversion action that uses a static default value ("use the same value for each conversion") — the mechanism only works on top of dynamically passed, real transaction amounts. This ties directly back to how your conversion value is set up: if value is passed statically, you have no way to correct it on refund — you need to switch to dynamic value passing first.

Possible approaches

• If refunds aren't being accounted for at all, first make sure the conversion action uses dynamic value (otherwise Conversion Adjustments simply can't be applied), then set up the actual adjustment-upload process (retraction for full refunds, restatement for partial ones) via API, the interface, or Google Ads Scripts.
• Google recommends using Conversion Adjustments as the standard mechanism for these cases — it's considered more accurate than relying only on the original order amount with no follow-up correction.
• If your typical refund cycle is longer than the 54-day window, it's worth explicitly recognizing that some refunds will remain unaccounted for in Google Ads no matter what, and not assuming the adjustments mechanism will fully solve the problem — in that case, it's smarter to apply a correction factor when interpreting reports.
• If the refund rate differs noticeably across categories, factor that in explicitly when evaluating and comparing ROAS between categories (and when assigning different tROAS targets), rather than comparing them on "raw" ROAS with no refund adjustment.
• If technically implementing adjustments isn't feasible yet, as a stopgap, manually reconcile total revenue net of refunds (from your CRM/e-commerce platform) against Google Ads data on a regular basis (say, monthly) and use that reconciliation as a correction factor when interpreting reports, rather than treating Google Ads' numbers as fully accurate.
• For categories/segments with a high and predictable refund rate, you can build in a small buffer on the target tROAS ahead of time (setting the target slightly above the actual desired ROAS "on paper"), knowing that part of the revenue will later be corrected by refunds — this doesn't replace the technical fix, but it reduces the risk of systematically underestimating the real situation in the moment.