Refunds and Conversion Adjustments

A canceled order should no longer contribute conversion count or value in Google Ads. A partially refunded order should retain its conversion but use the final corrected value. GA4 needs a refund tied to the original transaction so reporting can connect the reversal to the purchase.

Adjusted attributed ROAS = corrected attributed conversion value / matched ad spend

Keep an idempotent adjustment ledger keyed to the original transaction and platform conversion identifiers. Record the initial value, adjustment type, final value, refund items, event time, upload status, and store control amount. Retries must not create a second economic refund.

Platform correction and economic loss are related but different. This page fixes platform transaction reporting. The returns guide models refunded margin, reverse logistics, fees, and inventory recovery; the revenue-basis guide defines the numerator; the Google target guide sets the required profitability threshold.

Adjustment	Use when	Effect
RETRACTION	The conversion should no longer count, such as a fully canceled or invalid transaction	Removes conversion count and value
RESTATEMENT	The conversion remains valid but its value changed, such as a partial refund	Replaces value; conversion count stays

For a RESTATEMENT, upload the conversion's final adjusted value after the refund. Do not upload the refund delta. If an order originally carried $500 of value and $100 is refunded, the adjusted value is $400, not -$100 and not $100.

A RETRACTION removes both value and count. After a conversion is retracted, it cannot be adjusted further, so do not retract a still-valid partially refunded transaction. Match the adjustment to the original conversion action and identifiers required by the upload method, and preserve the platform response for reconciliation.

1. Lock the original transaction or order ID to one adjustment record.
2. Classify full cancellation versus final reduced value from the commerce ledger.
3. Submit RETRACTION or RESTATEMENT with a deterministic adjustment timestamp.
4. Record success, partial failure, and retry state without generating a second adjustment.
5. Wait for reporting to process before recalculating the Ads numerator.

Send the GA4 refund event with the original purchase transaction_id. For a partial item refund, include the affected items and refunded quantities so item reporting can identify what was reversed. Keep the currency and value treatment consistent with the purchase implementation.

Do not invent a new transaction ID for the refund, and do not resend the same refund as a new economic event during a retry. Store an event key or equivalent delivery state so the pipeline can distinguish a retry from another refund against the same order.

In the GA4 Data API schema, purchaseRevenue already subtracts revenue from refunded transactions. If a control table starts from purchaseRevenue, do not subtract refund revenue again. Other revenue fields can use different definitions, so select the metric deliberately and label it in the reconciliation.

Processing boundary: A successful request does not guarantee that every reporting surface updates immediately. Reconcile after processing delay, using the same dates, timezone, currency, transaction population, and revenue field.

A frozen cohort initially shows $40,000 of attributed conversion value on $10,000 of spend, or 4.00x. The store later identifies fully refunded or canceled transactions with $5,000 of original credited value and partial refunds that reduce valid transaction values by another $1,000.

In Google Ads, retract the fully refunded conversions. Restate each partially refunded conversion to its final value; the aggregate $1,000 is the reduction across those final values, not the number sent as every RESTATEMENT. Corrected Ads value is $40,000 - $5,000 - $1,000 = $34,000, so adjusted attributed ROAS is 3.40x.

GA4 receives refund events against the corresponding original transaction IDs, including affected items for partial item refunds. The store control report currently shows $33,000 of net revenue. The remaining $1,000 gap is a reconciliation queue item: it can be timing, scope, identity, or value treatment. Do not hide it with an unverified second adjustment.

Scenario	Revenue	ROAS	Normalized orders	Contribution profit at 40%
Stale initial	$40,000	4.00x	400	$40,000 x 40% - $10,000 = $6,000
Ads adjusted	$34,000	3.40x	340	$34,000 x 40% - $10,000 = $3,600
Store control	$33,000	3.30x	330	$33,000 x 40% - $10,000 = $3,200

Orders are normalization only: The planner calculates revenue / $100 AOV to make scenarios comparable. Those 400, 340, and 330 figures are not Google Ads conversion counts. A RESTATEMENT leaves conversion count unchanged; a RETRACTION removes the retracted conversion count and value.

Compare stale, adjusted, and store-control value

1. Freeze the cohort: Match ad spend, original purchases, report dates, timezone, currency, and conversion action.
2. Export the store ledger: Separate full cancellations, partial refunds, shipping, tax, discounts, and unsettled cases.
3. Adjust Google Ads: Retract invalid conversions and restate still-valid conversions to their final values.
4. Emit GA4 refunds: Reuse original transaction IDs and include affected items for partial item refunds.
5. Wait and re-export: Allow both systems to process, then compare the same cohort again.
6. Classify every gap: Resolve timing, missing IDs, failed uploads, metric definition, currency, or late refunds instead of forcing equality.

A matched store number is a control, not proof that ad attribution is incremental. Once the transaction values reconcile, calculate profit with the correct cost boundary and compare the resulting mature ROAS with the business target.

Google documents conversion adjustments in Google Ads and the API, ecommerce and refund events in GA4, and reporting metric definitions in the Data API schema. Product and method availability can vary. ROAS Break supplies the fictional cohort, shared 40% contribution assumption, reconciliation control, and scenario comparison.

• Google Ads: About conversion adjustmentsOfficial retraction and restatement workflow. Checked August 21, 2026.
• Google Ads API: Upload conversion adjustmentsOfficial API adjustment types, identifiers, and upload behavior. Checked August 21, 2026.
• Google Analytics: Measure ecommerceOfficial purchase and ecommerce event implementation context. Checked August 21, 2026.
• Google Analytics: refund eventOfficial refund transaction and item parameter reference. Checked August 21, 2026.
• Google Analytics Data API schemaOfficial reporting metric definitions, including purchaseRevenue. Checked August 21, 2026.