Clarvivo

Free tool by Clarvivo · no login

Check whether refunds still reconcile to your orders

Upload matching order and refund exports to find identifier gaps before gross revenue is mistaken for net revenue.

Orders and refunds exports

Upload matching order and refund exports. We compare order IDs and refund totals; this does not by itself prove an analytics refund event fired.

This tool answers: Do the refunds in this export still match known orders, or is revenue likely overstated?

Enable JavaScript to run the check — the diagnosis itself is free and needs no account.

Why this happens

Analytics records a purchase when the order is placed. If the order is later refunded, most setups never tell analytics or the ad platforms. Revenue stays in GA4, return on ad spend stays inflated, and campaigns that drive high-refund customers look better than they are.

The first step to fixing that is knowing how big the gap is and whether your refund data can be matched to orders at all. If refunds use different IDs from orders, or reference orders that aren't in your export, you can't send refund events or adjust revenue reliably.

This checker compares an orders export with a refunds export: it matches refunds to orders by ID, totals the refunded amount, and lists refunds that don't match any known order.

Next checks

These answer the questions this one tends to raise.

How this check works

So you can trust the result — and your developer can verify it.

  1. Upload orders and refunds

    An orders export with an order or transaction ID, and a refunds export with the same ID and the refund amount.

  2. We match refunds to orders

    Each refund is looked up by ID in the orders export. Unmatched refunds are listed, because they can't be pushed to analytics or reconciled.

  3. We total refunded revenue

    The refund total over the period shows how much revenue in your reports may already be gone.

Common causes and fixes

Refund events never sent to analytics
GA4 supports a refund event with transaction_id. Send it from your backend when a refund is processed, or import refund data.
Refund IDs differ from order IDs
Payment processors often use their own IDs for refunds. Keep the original order ID on the refund record so they can be matched.
Exports cover different periods
A refund for an order placed before the export window won't match. Use an orders window that starts earlier than the refunds window.
Partial refunds
Partial refunds reduce revenue without cancelling the order. Send the refunded value, not the full order total.

Frequently asked questions

Does this prove GA4 received refund events?
No. It checks whether refunds can be matched to orders and how much revenue they represent. Whether a refund event fired is a separate check.
Why do some refunds not match any order?
Usually different IDs between systems, or orders placed before the export's start date.
Should refunds be removed from ad platform conversion value?
Google Ads supports conversion adjustments for retractions and restatements. Meta doesn't subtract refunds from reported value, so account for them in your own reporting.
Is my data stored?
No. Both exports are parsed for the result only.
What should I check next?
The Shopify vs GA4 Revenue tool, which compares paid, refunded and analytics-reported revenue over a period.

Use net payment truth for revenue decisions.

Clarvivo keeps refunds and acquisition claims in one revenue picture.

Reconcile net revenue

What this tool reads, and what it keeps