Why GA4 revenue never matches your backend

The gap is normal. GA4 and your commerce platform will never agree, and they were never designed to. What matters is knowing how large the gap should be, what causes it, and which decisions each number is allowed to inform.

Your commerce platform records every completed transaction from the server, after payment authorisation. It has no dependency on a browser executing a script, on a user accepting cookies, or on a tag firing before someone closes the tab.

GA4 depends on all three. It is a behavioural measurement system, not a financial one, and it will always report less revenue than the ledger.

So the answer to “which number goes in the board deck” is the backend, without exception. The useful question is a different one: is GA4 close enough, and consistent enough, to be trusted for the decisions you’re actually using it for — channel mix, funnel diagnosis, campaign performance.

It’s worth separating the causes into two groups, because they behave very differently.

Systematic differences — a fixed, explainable offset.

• Tax and shipping. The most common single cause. GA4 reports whatever value your dataLayer sends. If that value is gross and your finance reporting is net of VAT, a Portuguese store carries a 23% structural gap that has nothing to do with tracking quality.
• Refunds and cancellations. Your backend nets them off. GA4 only does if refund events are implemented, and in most setups they aren’t.
• Timezone. A GA4 property set to a different timezone than your commerce reporting will shift revenue across day and month boundaries. Small in a month, very visible at month-end.
• Currency conversion. Multi-currency stores are converted at Google’s daily rate, not your payment provider’s.

These are reconcilable. Once you know the basis, the gap becomes a number you can explain and predict.

Collection loss — variable, and the one that actually causes damage.

• Consent denial. Users who reject analytics cookies aren’t measured. Depending on your CMP design and market, that’s a meaningful share of EU traffic. Consent Mode modelling fills part of the hole, but only when the property clears Google’s data thresholds.
• Ad blockers, ITP, and script failures. Browser-side collection loses transactions that the server has already recorded.
• Duplicate or missing purchase events. A thank-you page that fires on refresh inflates revenue; a redirect that skips it loses revenue entirely. Both depend on transaction_id being present and correct.
• Payment methods that leave the site. Wallets and bank redirects that return users somewhere other than the confirmation page drop the purchase event.

This is the part that gets missed, and it’s the part that costs money.

Teams accept that GA4 undercounts and then reason that it doesn’t matter, because the loss applies evenly and the relative comparisons still hold. Paid social versus paid search, mobile versus desktop, Germany versus Spain — the ranking survives even if the absolute numbers don’t.

The loss is not even.

Consent denial rates differ by market and by traffic source. Ad blocker usage differs sharply by device and by audience. In-app browsers behave differently from Chrome. A channel bringing you younger, mobile, technically literate traffic will lose a larger share of its conversions than a channel bringing older desktop users — and GA4 will show it converting worse.

That distortion doesn’t sit in a reconciliation spreadsheet. It sits in your channel report, and it moves budget.

A healthy setup isn’t one where the numbers match. It’s one where the gap is understood, documented, and stable.

• The basis is written down. Whether GA4 revenue includes tax and shipping, and whether refunds are captured, should be a known fact your analyst can state immediately — not something rediscovered every quarter.
• The gap is monitored monthly as a percentage. A steady variance is a reconciliation exercise. A variance that moved from 8% to 19% between March and April is an incident, and it usually has a date attached to a site release or a consent banner change.
• The gap is checked per channel and per device, not just in total. This is what surfaces the bias. A flat headline variance can conceal one channel losing three times as much as another.
• Server-side tagging where the loss justifies it. Moving collection server-side recovers transactions lost to browser-side failures and gives you control over what’s sent. It does not, and must not, bypass consent — a user who refused analytics stays unmeasured. Server-side tagging is a durability fix, not a consent workaround, and anyone selling it as the latter is selling you a compliance problem.

• Pull last month’s revenue from GA4 and from your backend on the same timezone and the same date range. Write down the percentage gap.
• Confirm whether your purchase event sends tax and shipping. This one check explains most large gaps.
• Repeat the comparison for the previous five months. You’re looking for movement, not size.
• Break the current month’s gap down by channel and by device, and check whether any single channel is losing disproportionately.

If the variance is stable and explainable, GA4 is doing its job and you can stop arguing about it in meetings. If it’s drifting, or if it’s concentrated in one channel, you have a measurement problem that is currently informing budget decisions.