GA4 revenue does not match your shop platform

Start with refunds, because it is usually refunds

If your revenue number only ever goes up, refunds are not coming back.

An order is created. It flows to fulfilment, to analytics, to the email tool, to the CRM. Everyone agrees. Then it is refunded, and that refund is recorded in exactly one system.

From that moment every downstream number is wrong in the same direction. Revenue only climbs. Lifetime value inflates. A customer who returned everything they ever bought sits in a high value segment receiving a loyalty campaign.

This is worth checking before anything else because it is quick to confirm and it accounts for more mismatches than the other four causes combined.

---

The purchase event firing twice

If your confirmation page can be reloaded, refreshed, or reached again from an email link, the purchase event can fire more than once for the same order.

The symptom is analytics revenue running above the shop platform rather than below it, often by an oddly consistent proportion. The fix is to deduplicate on transaction ID, which every serious analytics platform supports and which is skipped surprisingly often.

---

Tax, shipping and discounts counted differently

Your shop platform has a defined position on whether revenue includes tax, whether shipping is revenue, and how a discount is applied. Your analytics has its own position, set by whoever configured the tag.

Neither is wrong. They are answers to different questions, and the gap between them is stable and explainable once you know which is which. This one rarely needs fixing so much as documenting.

---

Currency converted on different dates

If you sell in more than one currency, the shop platform and analytics almost certainly convert at different moments using different rates. For a business with meaningful non-domestic sales this alone can account for a few per cent.

---

Consent, which you cannot see in the report

Visitors who decline analytics are not counted the way accepting visitors are. If consent was implemented recently, part of your gap appeared on a specific date, and that date is usually visible in the trend if you look for a step change rather than a slope.

This is not a fault to fix. It is a number to quantify, so that nobody spends a quarter hunting for a traffic problem that is actually a consent implementation.

---

How to check all five in about an hour

None of this needs a project. It needs an export and a quiet hour.

• Pull last month orders from the shop platform, and last month revenue from analytics. Write both numbers down before you start, so you are measuring against something.
• Subtract refunds from the shop platform figure. If the gap closes substantially, you have found it, and the fix is to propagate refunds rather than to change the report.
• Sort analytics transactions by transaction ID and look for duplicates. Any repeats mean the purchase event is firing more than once.
• Check one order end to end. Take a single order value and follow it through both systems, watching what happens to tax, shipping and any discount at each step.
• Look at the trend for a step change rather than a slope. A sharp drop on a specific date is usually a consent implementation or a tag change, not a demand problem.

At the end of that hour you will usually be able to attribute most of the gap. What remains is worth documenting rather than chasing.

---

The test that matters

Does the revenue figure in your dashboard match the one finance uses, and if not, can you explain the gap in one sentence?

That is the whole standard. Not a perfect match, which is not achievable, but a small gap with a known cause. Once the definitions agree, the dashboard becomes something people act on instead of something they argue about.

If you cannot explain the gap today, start with refunds.