When GA4 Purchase Revenue Doesn't Match Your Payment Report

Somewhere in your company there are two numbers being called revenue for last month. One comes from GA4. The other comes from a payment report. When they don't match, someone senior asks which one is right.

There isn't one right number until you say what you're trying to measure. The two systems have different jobs, and the question as usually asked leaves out what the number is supposed to measure.

The short version of what to do about it: use the finance-approved ledger for reported revenue and keep GA4 for acquisition analysis. To check GA4 coverage, compare it with the same completed online orders in your order system and treat a change in that relationship as an alert.

What GA4 is doing

In a common browser-only ecommerce setup, GA4 depends on client-side collection. A tag has to load, and a purchase event has to fire, usually on a thank-you page, before the visitor closes the tab. It doesn't have to work that way, since GA4 also accepts server-side and offline events through the Measurement Protocol. In a browser-only setup, though, plenty of things can get in the way.

Safari limits script-set first-party storage after seven days of Safari use without interaction with the site. If GA4's client identifier expires, a returning visitor can appear as a new GA4 user. That can fragment identity and attribution; it does not by itself stop a purchase event from being sent, since GA4's tags don't need a cookie to transmit data. Some blockers can stop the tag from sending data at all.

Consent banners are their own case. With basic consent mode, no GA data is sent after a refusal. Advanced consent mode can send cookieless pings. If the property is eligible and its reporting setting includes modeled data, GA4 can add modeled user and session metrics to some reports. Meeting the published traffic thresholds does not guarantee eligibility, and GA4 labels reports that include modeled data. Some GA4 reports can include modeled user and session metrics. That does not establish that the Purchase revenue dollar total itself was modeled.

For this web-order comparison, GA4 Purchase revenue is based on the purchase values sent to the property, minus the refund values sent to GA4. The recommended purchase value is item price times quantity, excluding shipping and tax. That makes it useful for acquisition analysis, not financial reporting.

What the processor is doing

Stripe, or Square, or whoever handles your payments, records payment and balance activity for the transactions it handled. It saw the phone order only if it processed that payment. Refund timing and month-boundary treatment depend on which report you pull, its timestamps, and the timezone it's set to (Stripe, for one, lets you view reports in your account's timezone or UTC), so those definitions have to be aligned before anything gets compared with GA4.

What the processor provides is transaction-level payment evidence that finance can reconcile. What it doesn't natively see is the browsing journey before the payment, unless your integration passes that context into payment metadata. And payment activity isn't recognized revenue either. Charges, refunds, disputes, fees, and payouts are separate measures from the number finance signs off on.

If GA4 is missing half your revenue, check the tag before philosophizing. The structural gap is real, but it doesn't excuse a purchase event that silently stopped firing.

Why the argument survives anyway

I think the monthly argument keeps happening because of incentives more than ignorance. GA4 attributes revenue to campaigns, which makes marketing's work visible, so marketing quotes GA4. Finance has to tie its number to the books. Processor reports help it reconcile payment activity to cash, so that's the report finance brings. Neither side is being dishonest.

So the meeting happens. Both sides walk in with their number and, say, twenty minutes go to the difference before someone gets assigned to "look into the discrepancy." That follow-up is easy to deprioritize. It only helps the next meeting.

Make the gap an alert

Declare a source of truth for each measure, in writing: the finance-approved ledger for reported revenue, the processor's reconciliation report for payment activity, and GA4 for behavioral and attribution analysis. For checking how well GA4 covers your online sales, the comparison source is usually your order or commerce system rather than an undifferentiated processor charge total.

Then build a like-for-like comparison. Start with the same eligible completed web orders from the same store or legal entity, sales channel, processor, and payment status. Use the same currency and currency-conversion rule, timezone, business-day cutoff, and choice of order, capture, or settlement date. Match tax, shipping, gross-versus-net treatment, refunds, cancellations, disputes, and chargebacks, then wait until the period closes and the agreed data lag has passed.

For web streams, GA4 uses transaction_id to deduplicate repeated purchase events from the same user. If your implementation sends the commerce order ID as transaction_id, that shared ID is what you use to match the records between systems. Count eligible orders, matched IDs, and missing IDs, and total the revenue difference among the matched ones. Check duplicate sends separately where purchase events are generated, because GA4 may already have removed them from the report. The aggregate ratio of GA4 revenue to order revenue is a secondary warning signal on top of that, and on its own it can hide missing and duplicated orders that cancel out. In a low-volume month, one large order or refund can move the ratio by itself.

A made-up example: GA4 matches somewhere between 85 and 90 percent of eligible orders for six months, then one month it drops to 70. The ratio changed. Now test measurement, sales mix, timing, and scope before deciding why. The six-month range gives you a baseline. The 70-percent month is an alert, and the transaction list tells you where to look.

Call it a rough hour a month once a simple, already-integrated setup exists. Writing the scope definitions and doing the first reconciliation takes longer than that.

My bet is that the companies still fighting about GA4 versus Stripe in 2028 will be the ones that skipped the step of writing down what each instrument is for.