How do I fix GA4 revenue not matching Shopify?

The store admin records every order it processed. Analytics records the events a browser managed to send. Those are two different things, and they will never produce identical totals.

So start by setting a tolerance. Pick a percentage difference that you consider acceptable, write it down, and stop investigating when you are inside it. Without that line, a store can spend months chasing the last few percent of a number that is not meant to be exact.

Then understand what each system is for. The admin is the ledger. It is what you pay tax on, what you reconcile against the bank, and the only number that should ever appear in a board report. Analytics is for proportions and behaviour: which sources bring buyers, which pages lose them, how the mix changes over time. Those questions are answered fine by a dataset that is slightly incomplete, provided the incompleteness is roughly even.

That last point is the real risk. A gap is harmless when it is spread evenly across sources. It is harmful when it is concentrated, for example when one payment method or one country loses most of its events, because then the proportions you are reading are wrong and you will move budget in the wrong direction.

So the diagnostic question is not how big is the gap. It is whether the gap is even. Compare the difference by device, by country and by payment method before you conclude anything.

Check these in sequence, because the early ones explain most gaps and the later ones are fiddly.

First, analytics missing lower than the admin. Consent banners that block measurement until a click, browser and network blocking, and privacy settings all remove events. Check whether the gap changed on the day a consent tool was installed or updated.

Second, purchase events that never fire. The usual culprits are express wallet payments, payment methods that redirect to an external site and return, orders completed from an email link days later, and any custom or headless checkout. Test each payment route yourself and watch for the event.

Third, duplicate events, which show analytics higher than the admin. Two installations of the same measurement tag, a purchase event that fires again when someone refreshes or revisits the confirmation page, or an app that adds its own tag on top of the platform integration.

Fourth, orders that exist in the admin and were never meant to be in analytics: point of sale orders, draft and manual orders, wholesale channel orders and subscription renewals that do not pass through the storefront. Those inflate the admin side legitimately.

Fifth, currency. Multi currency stores can report in the presentment currency in one system and the store currency in the other, which produces a stable percentage gap that moves with exchange rates.

Work down the list and record which ones you ruled out, because next quarter somebody will ask again.

Once the technical causes are handled, the rest is usually the two systems counting different things, and no amount of tag fixing will close it.

Tax and shipping are the biggest. Depending on how the purchase event is built, the value sent may include tax and shipping, exclude both, or include one. The admin can be read either way too, depending on which report you open. Decide which definition you want, configure the event to match, and always compare like with like: a total that includes shipping against another total that includes shipping.

Discounts behave similarly. A discount applied at checkout, a gift card redemption, or store credit can reduce the amount charged without reducing the item level values sent in the event.

Refunds and cancellations are next. Analytics records the purchase when it happens. Unless refunds are sent back as events, the analytics total keeps a sale the admin has already reversed. In a category with a high return rate that difference alone can be substantial, and it grows through the month.

Time zones create a smaller but very persistent gap. If the analytics property and the store are set to different zones, orders near midnight fall into different days, so daily figures disagree while monthly figures nearly agree. Set both to the same zone, and be aware that changing it does not rewrite history.

Finally, the reporting window. Analytics attributes a purchase to the session or the campaign, and reports built around attribution windows can shift as data settles over the following days.

The repairs are the same ones that make advertising work better, which is why this is worth doing properly rather than explaining away.

Install the purchase event through the platform's supported route rather than through theme edits, so it survives checkout changes. Add a server side connection where the platform supports it, with the order identifier passed on both sides so nothing is counted twice. Implement consent signalling correctly so declined visitors are handled properly rather than silently dropped. Send refunds as events if you want the totals to stay honest over time.

Then exclude the noise: internal traffic, staging environments, and test orders on both sides.

After that, publish the rule. The store admin is the source of truth for revenue and orders. Analytics is the source of truth for traffic sources, on site behaviour and conversion rates. Ad platforms are the source of truth for spend and for nothing else. Write that on the dashboard so nobody quotes the wrong system in a meeting.

Keep a single reconciliation view: admin revenue, analytics revenue, and the percentage difference, tracked monthly. The absolute gap matters far less than a change in it. A stable difference means the setup is working within its limits. A gap that suddenly widens means something broke, and you will know which month to look at.

Check it after every theme update, app install, payment method change and platform update, because those are when tracking quietly stops.