Refunds inflate attributed revenue because conversion tracking only fires in one direction. Your pixel and your server-side events fire when the order is created. Nothing fires when the money goes back. The refund lands on a different webhook, on a different day, and most attribution reports never subtract it — so every ROAS number you scale on is gross.
On a 2% return rate that gap is a rounding error. On apparel, footwear, supplements or anything sold on a “try it, send it back free” promise, it is the difference between a channel you should double and a channel you should cut. And the gap is never evenly spread: the audiences that return the most are usually the cheapest ones to acquire.
Why doesn’t a refund ever reach your attribution report?
Because the refund arrives as a separate event that most tracking setups never subscribe to. Order creation and order refund are different topics in Shopify, WooCommerce, Stripe and every CRM that touches money. A tool built to listen for “new order” hears nothing when that order is reversed, and the attribution row it wrote days earlier is never revisited.
Four mechanics stack on top of each other.
Conversion events are fire-and-forget. A Purchase event sent to a pixel or to the Conversions API is accepted, deduplicated and written into the platform’s dataset. There is no second call that takes it back. The platform’s record of that sale is permanent.
Attribution rows are snapshots. When a purchase is matched to a session, the tool writes a row — source, campaign, click ID, value, timestamp. That row is a photograph of the moment of sale. Unless something explicitly goes back and amends it, the value stays whatever it was the day the order landed.
Partial refunds hide inside “paid” orders. A full refund at least flips an order status somewhere. A partial one — a returned item from a three-item order, a shipping credit, a goodwill discount after a complaint — often leaves the order sitting in a paid or partially-refunded state with its original total still attached. Any report that counts orders rather than money movements keeps the full amount.
The lag puts the refund in a different reporting period. Return windows are measured in weeks. By the time the refund posts, the month has closed, the report has been sent to the client, and the budget decision it justified has already been made. This is the same structural problem as trying to attribute ecommerce revenue to the ad that started it weeks after the click — except running in reverse.
What does gross-revenue reporting actually cost you?
It costs you the ranking, not just the number. Overstating total revenue by a fixed percentage is annoying; overstating it unevenly across channels is what makes you spend money badly.
Take a simple illustration. Two channels each return $50,000 in gross attributed revenue on $12,500 of spend — both report 4× ROAS, so you split the increase between them. Now apply real return behaviour: the branded search channel gives back 5% and the broad prospecting channel gives back 22%. Net, one channel did 3.8× and the other did 3.1×. You just funded the worse one as if it were the better one.
That pattern is not hypothetical in shape, only in the figures. Discount-led and impulse-led traffic returns at a higher rate than intent-led traffic, because the reason people bought was weaker to begin with. Free returns are, for a chunk of your audience, a fitting-room policy — the order is a try-on, not a purchase.
The second cost is trust. When finance closes the month on settled cash and marketing reports on gross attributed revenue, the two numbers never agree, and the marketing number is always the optimistic one. That is a bad position to argue a budget from, and it is the fastest way to have your attribution tool declared unreliable in a meeting you are not in. Deciding which channel to scale on numbers your CFO can disprove is worse than not reporting at all.
Why can’t you just retract the conversion you already sent to Meta?
Because the platform’s event vocabulary has no reversal. Meta’s standard events are Purchase, Lead, Subscribe, StartTrial, InitiateCheckout and the rest of a fixed list — there is no Refund or Return event, and the Conversions API has no call that withdraws an event it already accepted. Once a Purchase with a value and a currency is in the dataset, it stays.
Do not reach for the obvious hack. Sending a Purchase with a negative value does not cancel the first event; it adds a second one. Meta’s value parameter is documented as the monetary value of the event, and the optimiser is being trained on the events you send. A negative Purchase pollutes both your own deduplication and the signal you are paying the platform to learn from.
Google Ads is the one major exception worth knowing about: it supports conversion adjustments, where a previously uploaded conversion can be restated at a lower value or retracted entirely. It requires the original conversion to carry an order ID or a click identifier you can match on, and there is an upload window after which an adjustment is no longer accepted — check the current requirements against your own account before you build on it.
The practical conclusion is uncomfortable but clarifying: the ad platforms’ reported revenue is gross by design, and it is not going to become net. Platform numbers are an optimisation signal. Net revenue by channel is a reporting job you have to own somewhere else.
How do you net refunds without building a data warehouse?
Four options, honestly ranked, with what each one actually costs.
Subscribe to the refund event and write it against the original order. The correct fix. Your store already emits one — a refund topic in Shopify, a refunded order status in WooCommerce, a charge refund in Stripe. You catch it, look up the original order, and post a negative row keyed to the same order ID. The cost is engineering: a webhook endpoint, retries, idempotency so a redelivered refund doesn’t double-subtract, and handling for partial amounts, restocking fees, shipping and tax.
Report from the store admin instead of the ad platform. Shopify and WooCommerce already know net sales. The limit is that they know almost nothing about where the order came from — you get a correct total with no channel breakdown, which solves the finance argument and none of the media-buying one.
Reconcile in a spreadsheet each month. Export orders, export refunds, join on order ID. It works, it is free, and it dies the moment you need channel-level detail across five sources and two currencies — which is exactly when you need it most.
Apply a blended hold-back. Discount every channel’s ROAS by your historical return rate before you make decisions. Crude, instant, and better than nothing — but it applies one average to channels whose return behaviour is the thing you were trying to measure. Use it as a stopgap, not as a system.
Should a refund be subtracted on the refund date or the order date?
Subtract it against the order — the date it was placed and the channel that earned it. Netting on the refund date answers a cash question, not a marketing one, and it produces a specific failure: a campaign you switched off in March keeps its inflated March revenue forever, while April’s report absorbs a debit for traffic April never bought.
Finance will want the cash view, and finance is right for their purpose. The two views are reconcilable as long as your reporting layer keeps the link between the refund and the original order — the same join that lets you reverse the credit at the channel level lets you also roll it up by settlement date when the accountant asks.
Two details that bite. First, restating a closed period means last month’s number changes after you reported it; say so up front, in the report, rather than letting a client discover it. Second, if the refund posts at a different exchange rate than the order, netting across a mixed-currency book needs a stated conversion rule — the same problem as reporting attribution across multiple currencies, and it deserves the same footnote.
How does PartialLeads handle refunds in attributed revenue?
Every purchase PartialLeads receives — Shopify, WooCommerce, Stripe, GoHighLevel, or any system that can POST to the universal webhook — runs through one inbound pipeline. Deduplication in that pipeline is idempotent on client, source, order ID and status phase. That last part is the whole mechanism: a refund is not treated as a duplicate of the paid order, it gets its own row, and that row nets against revenue.
Because the refund carries the same order ID, it resolves to the same matched session and the same first-touch and last-touch attribution rows the original sale wrote. The credit is reversed exactly where it was given: the campaign that earned the order is the campaign that gets debited, not whatever traffic happened to be running the week the customer shipped the box back.
That flows through the reports without extra configuration. The Purchases ledger carries the paid row and its refund row. The Attribution report’s revenue, AOV and ROAS columns per channel are net figures, and the Revenue by Match Quality donut splits net revenue across partial-captured, submit-completed and unmatched. If you are reading the report alongside a platform’s own dashboard, the section on how to read an attribution report covers why the two disagree and which one to argue from.
Three honest constraints.
PartialLeads does not un-send the conversion. The event Meta already accepted stays in Meta’s dataset at its original value. Your PartialLeads reports go net; Ads Manager stays gross. That is two sets of books on purpose — the platform number is the optimisation signal, the net number is the one you make budget decisions on.
A refund has to arrive from a connected source. Refunds issued through Shopify, WooCommerce, Stripe or GoHighLevel come in as events. A cash refund at a counter, a manual bank transfer, or a dispute settled entirely outside your store is invisible to any tool that only sees your store’s event stream, including this one.
Matching still governs channel-level accuracy. A refund on an order that was never matched to a session nets your total revenue correctly but has no channel to debit. The fix is upstream: more matched purchases, which is an identity problem rather than a refund problem.
| What breaks | The mechanism | Where you see it in the dashboard |
|---|---|---|
| Refunded orders still counted at full value | Refund rows keyed on status phase, netted against the paid order | Purchases ledger |
| Refund credited to the wrong period or channel | Same order ID resolves to the original matched session and its first/last-touch rows | Attribution report, channels table |
| Partial refunds hidden inside a “paid” order | Each status phase is its own row rather than a mutation of the order | Purchases ledger |
| ROAS overstated per channel | Revenue, AOV and ROAS computed on net revenue | Attribution report KPI strip |
| Refunds landing in a different currency period | Multi-currency normalisation with a stated rate and date | Attribution report currency selector |
| Refund on an order with no session match | Nets total revenue; channel credit needs the purchase matched first | Purchases ledger, matched/unmatched wedge |
Tell us what's broken. We'll fix your tracking — free.
Describe the tracking/attribution problem you're stuck on and we'll map it to a fix: server-side conversions to Meta, Google, TikTok and Pinterest, plus first-party tracking that survives Safari. No code required.
Sources
https://developers.facebook.com/docs/meta-pixel/reference https://developers.facebook.com/docs/marketing-api/conversions-api/parameters/custom-data https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events