Webclat / Ecommerce
ecomm.webclat.com

Why does Shopify's own revenue total not match what GA4/GTM ecommerce tracking reports for the same period?

Neither number is wrong. They're counting different things under different rules - the useful question isn't "which one is right," it's "is the gap the size it should be."

Quick answer

The two systems are structurally different instruments, not a broken integration. Shopify's revenue is the server-side order ledger, net of refunds, in the store's timezone and currency. GA4 revenue is a client-side event count filtered by consent, ad blockers, browser crashes, and GA4's own timezone and currency-conversion settings. A stable, explained gap between the two is normal; what's worth investigating is an unexplained or growing gap.

Why this happens

Six specific mechanisms drive the majority of the mismatch, and they compound:

  • Consent and blockers. Cookie banners and ad blockers prevent GA4 from firing for a share of visitors before they ever purchase - a population effect, not an error.
  • Refunds and cancellations. Shopify nets refunds out of "net sales." A GA4 purchase event already fired and isn't retroactively removed unless you explicitly send a refund event back.
  • Timezone mismatch. Shopify's admin timezone and GA4's property timezone can differ, shifting orders placed near midnight into a different reporting day on one side but not the other.
  • Currency conversion. Multi-currency stores show Shopify revenue in shop or presentment currency, while GA4 converts to the property's reporting currency using its own daily exchange rate, which drifts from the rate active at checkout.
  • Duplicate or missing purchase events, from the causes covered in the GTM-tag and Trekkie-pixel questions in this same section.
  • Test and draft orders counted in one system and excluded in the other.

Fix it

  1. Match timezones: check Settings > Store details for Shopify's timezone and Admin > Property Settings for GA4's; align them, or accept a boundary skew and don't compare hourly.
  2. Pull the same currency basis: compare shop-currency Shopify revenue to a GA4 report where currency isn't auto-converted, or manually convert Shopify's number using the exchange rate active on the day in question.
  3. Reconcile refunds explicitly: send a refund event through the Web Pixels API when a Shopify refund fires, or accept that GA4 will run slightly above Shopify's net-of-refunds figure and treat that delta as expected rather than a defect.
  4. Rule out consent loss before assuming a tracking bug: compare your cookie-consent acceptance rate to the size of the GA4-vs-Shopify order-count gap. If they're close in magnitude, most of the gap is simply visitors who declined analytics.
  5. Check for duplicate purchase events inflating GA4 above Shopify's gross figure - if GA4 revenue is higher than Shopify's gross (not just net-of-refunds), suspect double-firing before assuming undercounting.
  6. Exclude test and draft orders from both sides. A draft order converted to a real order can double-count if a pixel already fired at the draft stage.

Branch: if GA4 revenue is consistently lower than Shopify's net figure, start with consent/timezone/currency (steps 1-4). If GA4 revenue is consistently higher than Shopify's gross figure, start with duplicate events (step 5) instead - the two symptoms point at almost entirely different causes.

How to verify it worked

Runtime check

Pick one closed calendar day from a few days in the past, so all refunds for it have settled. Pull Shopify's order count and gross/net revenue for that day in shop currency. Then pull GA4's purchase event count and revenue for the same calendar day in the same currency - use an Explore report with an unconverted currency dimension, or query the BigQuery export summing ecommerce.purchase_revenue where event_name = 'purchase'. The two totals should differ only by an amount you can attribute to consent decline, refunds, and timezone edge orders. If the gap changes shape day to day with no consent or refund explanation, that's the signal a tracking fix - not a reporting fix - is still needed.

Find out what your tracking actually reports.

A runtime audit of your store: every tag that fires, every event that reaches your analytics and ad platforms, and where the numbers diverge from the orders table. Evidence first, opinions second.

Request an audit