Practical framework / 5 MIN READ
Send the correction that matches the original conversion
Build an adjustment ledger before changing platform values or counts.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-06
A refunded or cancelled outcome can remain in an advertising system after the business ledger changes. Correcting it requires the platform’s adjustment operation, a reliable link to the original record and verification of the processed result.
What you will leave with: Prepare a conversion-adjustment queue with original identity, intended final state, approval and reconciliation.
Use this when
- Reported conversion value includes orders later partly refunded.
- A cancellation should change an existing platform conversion rather than create another event.
This lesson governs advertising adjustment records, not the wider reconciliation between analytics revenue and accounting.
Define the intended final state
Start from a verified business change and the agreed conversion definition. Decide whether the action still counts with a lower value or should no longer count at all. A partial refund and a cancelled order often require different treatment.
Record original conversion identity, action type, original value, correction reason and intended final value. Keep currency and time conventions explicit. Do not upload a refund as a fresh positive conversion, and do not assume a negative purchase event will update the original record in every destination.
Choose the supported adjustment operation
Google Ads distinguishes restatement, which changes value, from retraction, which removes a conversion from the count. It also warns that retraction or restatement to zero prevents subsequent ordinary adjustments. Review the current record-matching, eligibility and timing rules before preparing a change.
Treat terminal operations carefully. A reversible-looking upload can have consequences for reporting and bidding. Prepare the exact records and intended effects for the authorized owner, and obtain required approval before submission. Do not experiment on live conversion history to discover how an operation behaves.
Validate identity and update semantics
Match the correction to the original conversion using the supported identifiers and action. Check that the transaction belongs to the intended account and that the original event exists in the relevant processing route. Keep unmatched corrections visible rather than assigning them to a similar-looking order.
Determine whether a restatement expects the new total or a delta. Use an approved synthetic fixture with a partial refund, full cancellation and repeated submission. Record adjustment timestamps and processing results so retries can be evaluated without duplicating or contradicting earlier updates.
Reconcile the processed result
Separate prepared, submitted, accepted, rejected and reflected-in-report states. A successful file upload is not proof that every row found its original conversion. Inspect error details without exposing customer identifiers unnecessarily, then resolve failures through the documented procedure.
Compare final values and counts with the adjustment ledger after appropriate processing time. Annotate material historical changes and explain their effect on reporting. If a correction was sent incorrectly, consult the current recovery procedure with the owner; do not invent new identities or timestamps merely to force a preferred total.
Make the reasoning concrete.
A hypothetical platform conversion originally reports $150. A verified partial refund is $40, leaving a valid $110 purchase. Under a restatement operation that expects the new total, the intended value is $110, not minus $40 and not an additional $110 conversion.
Create another purchase event
Opening: Upload $110 as a new conversion.
Hypothesis: The corrected amount appears somewhere in the account.
Risk: The original $150 may remain and counts may increase.
Restate the matched record
Opening: Submit the supported $110 final value against the original conversion identity.
Hypothesis: The intended count remains one with revised value.
Risk: Eligibility, processing and authorization still need verification.
Prepare a matched restatement and confirm the processed value after approval. Use a retraction only when the intended outcome should no longer count under the agreed definition.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Business change
What verified refund or cancellation occurred?
Identity
Which original conversion and action must change?
Operation
Is the intended result a new value or removal from count?
Queue
What is each record’s processing status?
Verification
Does the final platform state match the approved ledger?
Watch for the wrong conclusion.
- Sending a correction as a new positive conversion.
- Confusing a new total with a delta.
- Treating upload acceptance as row-level success.
- Using terminal operations without reviewing consequences.
Your next action
Create a three-case adjustment fixture and a reviewable ledger before correcting live conversion records.
Sources & scope
Frameworks, worksheets and hypothetical examples are original editorial synthesis. Linked primary sources support only the stated concepts. Source checking is not an independent audit of effectiveness. No named human author or reviewer is claimed.
- Google Ads: About conversion adjustments →Primary technical documentation · Supports: Distinguishes restatement from retraction, identifies supported conversion records and warns about terminal zero/retraction behavior. Upload eligibility and timing must be checked for the current conversion type.