Conversion repair · SEM

A partial refund changes the total you send

Follow one purchase through two returns before building a Google Ads adjustment upload.

  1. Send the remaining valueA $120 purchase with a $30 refund becomes a $90 restatement, not a $30 adjustment.
  2. Give the next change its own timeA later $20 refund means a new $70 total and a later adjustment occurrence time.
  3. Do not use zero as pendingRestating to zero ends further adjustments to that conversion; it is not a holding value.

A returns export and an advertising adjustment file answer different questions. Your store may record how much money went back to the customer. Google Ads needs the value that should remain attached to the conversion. Copying one amount into the other field can produce a plausible-looking upload with the wrong meaning.

Google's RestatementValue reference defines the adjusted value as the conversion's value after the change. That small distinction becomes more important when an order has a second return. The example below is synthetic, uses USD throughout and assumes an eligible purchase already recorded by Google Ads. It is not a live campaign test.

Two refunds still belong to one order

Take order EXAMPLE-120, originally measured at $120. A first completed return reduces the value by $30. A later return reduces it by another $20. Assume the original and adjusted values use the same treatment of tax, shipping and discounts. If your conversion value represents something other than revenue, calculate the revised value on that original basis instead.

One synthetic purchase, three value states

EventNew refundValue to report
Original purchaseNone$120 original conversion
First return$30$90 restatement
Second return$20$70 restatement
Illustrative USD values, not measured campaign results. Each restatement replaces the previous total.

The second calculation is $120 − $30 − $20 = $70. Uploading $20 would say the entire remaining conversion is worth $20. Uploading $50 would confuse cumulative refunds with retained value. Neither is a correction merely because it is a number present in the returns database.

Build the export from the authoritative order state, with a record of which returns have already been included. Replaying a refund notification must not subtract that refund again. This is an implementation recommendation derived from replacement semantics, not a claim that Google reconciles your store's refund events for you.

One $120 order becomes a $90 restatement after a $30 refund, then a $70 restatement after another $20 refund.
Read the returned amount and the value to send as different quantities. The large blue total replaces the previous conversion value.

A second restatement needs a later occurrence time

The same API field definition specifies that a second restatement with a different value needs a new, more recent adjustment occurrence time. Reusing the previous time can cause it to be treated as a duplicate and ignored. Consequently, changing the amount alone does not fully describe a new adjustment.

Keep three events separate in your implementation: when the purchase happened, when its value changed, and when the upload ran. A job retry is a transport event; it is not evidence of another refund. Preserve the real change time with its time zone rather than inventing a fresh business event on every retry. Record the response against the adjustment you actually submitted.

The order identifier must survive the original purchase

Google's transaction-ID guidance explains that the name becomes “order ID” in offline conversion adjustments. Use the identifier of the original purchase, not a newly generated return number. IDs should be unique to orders and must not contain information identifying individual customers.

That identity has two jobs: distinguishing one customer's order from other purchases, and finding the already recorded conversion to correct. A constant placeholder reused across orders undermines the first job. Replacing the original ID with the returns system's case number undermines the second. Keep a separate internal return reference if your operations need one.

The API adjustment guide requires an existing recorded conversion and an eligible conversion action. It requires order_id for website conversions and when the original conversion had an order ID. The alternative click-and-time matching route is not permission to repair every website purchase that was originally sent without one. Check the route's prerequisites before preparing a production batch.

Zero closes the existing adjustment path

Google's adjustment overview distinguishes restating value from retracting a conversion. Retraction removes the conversion's count and value. A restatement that reduces the value to zero also prevents further adjustments to that conversion; later attempts can be ignored without an error. A genuinely cancelled order and an unresolved valuation therefore need different treatment.

That makes zero a state transition, not simply the smallest amount in a spreadsheet. Before approving it, someone should be able to explain why this original conversion should leave the reports. This article does not recommend creating replacement conversions to work around that finality.

Verify the correction separately from bidding performance

Google provides a Conversion adjustment reporting segment to compare original values and counts with subsequent changes. Its delay segment measures time from the impression to the conversion and, separately, from the impression to the adjustment. These are useful reconciliation views; a changed total on today's dashboard is not evidence that the same adjustment improved tomorrow's bids.

  1. Match submitted adjustments to per-row results. The API guide requires partial-failure handling: a successful request is not sufficient proof that every item succeeded.
  2. Compare the intended remaining values with adjustment reporting, using a sufficiently mature reporting period. Google's reporting instructions advise an end date at least 30 days ago, or longer for a longer conversion window.
  3. Keep measurement repair separate from changes to bidding targets or campaign goals. Otherwise several simultaneous changes make the outcome harder to interpret.

Timing also limits the claim. The general upload instructions currently describe a 54-day overall adjustment window, but only seven days after first recording for autobidding readability. The overview separately gives Hotel Ads a 55-day overall window. Do not turn either number into a universal promise for every conversion route. The general instructions recommend waiting at least 24 hours after the original conversion for best upload results.

Correct values are only one layer. Our explanation of custom goals and Secondary conversions addresses which actions campaigns use. The target-based bidding change audit separates target decisions from measurement, while the Ask Advisor approval audit distinguishes authorizing a change from verifying its result. None substitutes for reconciling this order's actual value.

Questions before exporting adjustments

Do I upload the refund as a negative conversion?

Not in this restatement example. Send the new remaining total for the existing eligible conversion; do not represent the refund amount as a new purchase.

Are RESTATE and RESTATEMENT the same field value?

They describe the same kind of correction in different interfaces. Google's spreadsheet instructions use RESTATE; the API uses RESTATEMENT. Follow the selected interface's template rather than exchanging the literal strings.

Can I replace a zero-value restatement with the correct amount later?

Do not rely on that. Google documents that zero or retraction stops later adjustments to the same conversion, potentially without an error. Verify the decision before submitting it.

Official Google documentation

Google Ads Help and API references checked 11 September 2026