Why is my GA4 revenue wrong?
GA4 revenue goes wrong in four ways: the value is sent as a formatted string so GA4 discards it, tax and shipping are included in one system and not the other, the currency parameter is missing so multi-currency orders are read as account currency, or refunds are never sent so the figure only climbs. Reconcile GA4 revenue against your store's net revenue for one closed week — the direction and size of the difference identifies which of the four you have without any further investigation.
Free30 minutesNo obligation
GA4 revenue incorrect · what breaks
What this looks like when it's happening to you — GA4 revenue incorrect
- 01
Revenue consistently above or below your store
A stable difference, which points to definition rather than duplication.
- 02
Some orders contribute nothing to revenue
The event is recorded and the value is empty.
- 03
Revenue looks wrong only in certain markets
Currency or decimal formatting.
GA4 revenue incorrect · the fix
What changes once it's fixed — GA4 revenue incorrect
Revenue equals what customers were charged
With one documented rule for tax and shipping.
Multi-currency orders read correctly
Currency sent explicitly on every purchase.
Refunds reduce the figure
So reported revenue tracks what you kept.
GA4 revenue incorrect · architecture
Why your conversion data was wrong in the first place — GA4 revenue incorrect
Fixing this specific fault is worth doing. But it is worth understanding why it happened, because the same underlying weakness produces a different symptom every few months — and the reason your conversion data is wrong is almost never the tag itself.
- 1
Your conversion depends on a browser that is being restricted on purpose
A browser-side tag has to survive the page loading, the visitor staying, the script executing and the request leaving. Every one of those is now contested. The order in your database is certain; the browser event reporting it is not, and that gap is where wrong numbers come from.
- 2
Safari caps the cookie your attribution depends on
Intelligent Tracking Prevention limits cookies written by JavaScript to seven days, whatever expiry you set. Any customer who takes longer than a week to decide comes back as a stranger, so the sale is recorded and credited to nobody. A cookie your own server writes in an HTTP response is not subject to that cap — which is the single largest practical difference between browser-side and first-party server-side tracking.
- 3
Ad blockers remove the tag before it can run
A blocked pixel does not error, retry or warn anyone. The visitor buys, the order lands in your store, and no platform ever hears about it. First-party events sent from your own subdomain aren't filtered the same way, because they are not a third-party request.
- 4
Consent banners stop tags, sometimes when they didn't need to
Where consent is genuinely required, losing the event is correct. What is not correct — and what we find repeatedly on US-majority accounts — is an EU-style prior-consent banner applied to every visitor, discarding conversions no law asked you to discard. A server container enforces the real decision at the container rather than hoping each vendor script honours a flag.
- 5
The checkout can end somewhere your tag isn't
Wallets and hosted payment pages can be abandoned after the money moves. The customer paid; the confirmation page never rendered; the browser event never fired. Sending the purchase from the order record instead means the conversion arrives whether or not anyone came back to your site.
- 6
What that adds up to
Each of these is a separate route to ga4 revenue incorrect, and they compound. First-party server-side tracking doesn't patch them one at a time — it moves the money event off the browser entirely, so the order in your backend is what gets reported. That is why we reconcile against your own order records and put 95%+ accuracy in writing: with the event sourced from the order, the number is checkable rather than hopeful.
GA4 revenue incorrect · normal or broken
Some of this is supposed to happen — GA4 revenue incorrect
Half the time nothing is broken and the number is being read wrong. Knowing which is which stops you paying to fix something that was never a fault.
Normal, not a fault
GA4 slightly below your store
Consent denial and blockers. Expected.
Revenue excluding tax if you configured it that way
Correct, provided it's consistent everywhere.
Actually broken
Value sent as a formatted string
"1.089,00" is not a number. GA4 discards it silently.
Tax and shipping inconsistently included
A stable gap that looks like a fault and is actually a definition.
Currency parameter missing
Multi-currency revenue read as account currency, inflating or deflating whole markets.
Refunds never sent
Revenue only accumulates and drifts further from reality every month.
GA4 revenue incorrect · diagnose
How we find out why is my ga4 revenue wrong
Always in this order. Each step eliminates a class of cause, so by the last one there is usually a single explanation standing.
- 01
Reconcile against net store revenue
One closed week. Direction and size narrow it to one cause.
- 02
Read the value type in a live payload
Number or string is the fastest single check available.
- 03
Test each currency you sell in
Decimal separators differ and break parsers that work elsewhere.
- 04
Confirm the tax and shipping rule on both sides
And that the same rule is used on every other platform.
- 05
Check whether refund events exist at all
Most properties have never sent one.
GA4 revenue incorrect · prove
How we prove it's actually fixed — GA4 revenue incorrect
The tag firing again proves the tag fires. These prove the numbers are right.
Source of truth
Your store or payment processor net revenue
- Value numeric on every purchase, verified in a live payload.
- Currency present and correct, verified in at least two markets.
- Refunds confirmed reducing revenue, tested with a real refund.
- Reconciled against your store or payment processor net revenue for a fully closed window, matched on ID rather than on totals.
- No record counted twice, checked across the whole window rather than spot-checked.
- The same check repeated 30 days later, because a fix that holds once and drifts is the harder failure to catch.
GA4 revenue incorrect · free audit
What we check in the free audit
- Reconcile against net store revenue
- Read the value type in a live payload
- Test each currency you sell in
- Confirm the tax and shipping rule on both sides
- Check whether refund events exist at all
Checked against
Your store or payment processor net revenue
Free30 minutesNo obligation
GA4 revenue incorrect · when not to buy
When you don't need us for this — GA4 revenue incorrect
Most of these you can do yourself, and we would rather you did.
- You sell in one currency with no returns — the value is probably fine.
- You already know tax is the difference and it's consistent. That's a definition, not a fault.
- You use your store for revenue reporting and GA4 only for behaviour.
GA4 revenue incorrect · what we deliver
What we do about it — GA4 revenue incorrect
Numeric value from the order record
Not scraped from rendered page text, which changes with locale and theme.
Currency sent on every purchase
Explicitly, per order, rather than assumed from the property setting.
Refund events implemented
So returns are reflected instead of ignored.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
We fix the fault in your existing browser-side setup and verify it on a live transaction. Honest disclosure: this repairs what you have, it does not make it durable. If you spend $1K+/month on paid media, the fault will recur the next time Safari, a consent banner or a checkout change moves under you — the server-side tier is what stops that.
- Root cause found and fixed, not worked around
- Verified on a live transaction, not in preview
- Reconciled against your own order records
- Written handover documenting what changed and why
1st-party server-side
Recommended$800One-time fee · most popular
The tier that removes the whole class of failure rather than this instance of it. Your money events stop depending on the browser: they are sent from your order records through a first-party server container on your own subdomain, so iOS, ad blockers, consent banners and interrupted payment redirects can no longer take them away. Built in 2–4 days. You own the stack outright — no monthly SaaS.
- First-party server container on your own subdomain
- Purchases sent from your order records, not the browser
- Meta, Google, TikTok, Microsoft and LinkedIn all fed server-side
- Deduplicated on a shared event ID, verified at every destination
- First-party cookies beyond Safari's 7-day cap on JavaScript-set cookies
- 95%+ conversion accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid-media channel server-side, end to end, plus the offline loop. For advertisers whose spend makes an attribution leak more expensive than the build. Pay once, own everything.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop, so closed revenue reaches bidding
- Refunds and cancellations reversed at every destination
- Klaviyo identity stitching, BigQuery and Looker Studio
- Monitoring, so the next break surfaces in days rather than a quarter
FAQ
GA4 revenue incorrect questions, answered
No. GA4 measures web sessions; your accounting measures money. Use your store or processor for revenue and GA4 for behaviour.
Usually a value sent as a string, or a malformed items array which causes GA4 to discard the ecommerce payload entirely.
Fire a refund event with the original transaction_id. Without that ID the refund can't be matched to anything.
Yes if you sell in more than one. Without it GA4 assumes the property currency and whole markets read wrong.
Free · 30 min
Get ga4 revenue incorrect diagnosed properly
Free30 minutesNo obligation
