Why is my conversion value or currency wrong?
A wrong conversion value has four causes and the ratio between your two numbers usually identifies which: the currency parameter is missing so the platform applies an account default, the store reports in the customer's presentment currency while you compare against settlement currency, tax and shipping are included on one side and not the other, or the value is being sent in the wrong unit — cents where the platform expects whole units, or the reverse. Divide the platform's reported revenue by your store's for the same window before doing anything else. A factor of 100 is a units bug, an exchange rate is a currency bug, and a small stable percentage is tax or shipping.
Free30 minutesNo obligation
Wrong currency or value sent · what breaks
What this looks like when it's happening to you — Wrong currency or value sent
- 01
Reported revenue off by a factor of 100
A cents-versus-units mistake. Unmistakable once you look at the ratio.
- 02
Revenue off by something that looks like an exchange rate
Missing currency, or presentment against settlement.
- 03
A small, stable percentage gap
Tax or shipping treated differently on the two sides.
- 04
Multi-currency stores where only some markets are wrong
The account default happens to match one currency and not the others.
Wrong currency or value sent · the fix
What changes once it's fixed — Wrong currency or value sent
Currency sent explicitly on every conversion
Read from the order, never inherited from an account setting.
The value unit confirmed against each destination's expectation
They do not all agree, and the assumption is rarely written down.
An agreed and documented definition of value
Gross, net of tax, net of shipping — chosen once and used on both sides of every comparison.
Presentment and settlement currency explicitly distinguished
So everyone knows which question a number is answering.
Wrong currency or value sent · architecture
Why your conversion data was wrong in the first place
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 wrong currency or value sent, 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.
Wrong currency or value sent · normal or broken
Some of this is supposed to happen — Wrong currency or value sent
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
Working
Every conversion carries its own value and currency from the order record, in the unit the destination expects, at a definition both sides agreed.
Broken
A gap that recurs every month, which everyone has learned to mentally adjust for and nobody has diagnosed.
Broken in one market only
Domestic orders reconcile and international ones do not, because the account default is right for one currency.
Actually broken
Currency parameter missing
The platform applies the account default and silently misinterprets every non-default order.
Value sent in cents where whole units are expected
Produces a hundredfold error that is comically obvious in the ratio and surprisingly easy to miss in a dashboard.
Presentment versus settlement confusion
The store shows what the customer paid in their currency; the finance report shows what was settled. Both are correct and they are not the same number.
Tax and shipping inconsistently included
The most common cause of a persistent small gap, and the one most likely to be argued about rather than checked.
A hardcoded currency left from the original build
Correct on launch day, wrong from the first international sale onward.
Wrong currency or value sent · diagnose
How we find out why is my conversion value or currency 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
Divide the platform's revenue by the store's for the same window
The ratio names the cause. Do this first, always.
- 02
Open one conversion and read its raw value and currency
Not the dashboard's formatted display — the actual payload.
- 03
Check a single order in a non-default currency
Single-currency testing cannot find a currency bug.
- 04
Confirm what the destination expects as a unit
Against its current documentation, per destination.
- 05
Ask both parties what number they mean
Gross or net, presentment or settlement. This resolves a large share of these disputes with no code change at all.
- 06
Check the timezone on both reports
A day-boundary mismatch produces a gap that looks like a value problem and is not.
Wrong currency or value sent · prove
How we prove it's actually fixed — Wrong currency or value sent
The tag firing again proves the tag fires. These prove the numbers are right.
Source of truth
Your store's order records, with the currency and the value definition stated explicitly
- One non-default-currency order followed end to end, with the raw payload value and currency read directly.
- Reconciliation per order over a closed window at the agreed value definition, in a single stated currency.
- Reconciled against your store's order records, with the currency and the value definition stated explicitly 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.
Wrong currency or value sent · free audit
What we check in the free audit
- Divide the platform's revenue by the store's for the same window
- Open one conversion and read its raw value and currency
- Check a single order in a non-default currency
- Confirm what the destination expects as a unit
- Ask both parties what number they mean
- Check the timezone on both reports
Checked against
Your store's order records, with the currency and the value definition stated explicitly
Free30 minutesNo obligation
Wrong currency or value sent · when not to buy
When you don't need us for this — Wrong currency or value sent
Most of these you can do yourself, and we would rather you did.
- Divide the platform's reported revenue by your store's for the same week. The ratio usually names the cause immediately.
- Find an order in a currency that isn't your default and check what value and currency were actually sent for it.
- Ask whoever is comparing whether they mean gross or net, presentment or settlement. Often that ends the discussion.
Wrong currency or value sent · what we deliver
What we do about it — Wrong currency or value sent
Send the currency parameter from the order record
Per order. Never rely on a platform default, even with one selling currency today.
Check the unit each destination expects
Some APIs take whole units, some take minor units. Verify against current documentation rather than assuming consistency.
Pick one value definition and write it down
Then make sure whoever is comparing the numbers is using the same one.
Decide presentment or settlement and be consistent
A store selling in twelve currencies and reporting in one has two legitimate revenue figures. Say which you mean.
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
Wrong currency or value sent questions, answered
Generally no. Send the order's own value and its own currency, and let the platform convert with its own rates. Converting yourself introduces a rate and a timing decision that will not match theirs, which creates a new discrepancy in place of the one you removed.
Presentment is what the customer saw and paid in. Settlement is what landed in your account after conversion. Both are legitimate figures answering different questions, and comparing one against the other produces a gap that looks like a bug. State which you are using.
There is no universal answer, only a consistent one. Pick the definition that matches how your business talks about revenue, write it down, and use it on both sides of every comparison.
Usually one of four things: Shopify's order total includes shipping and tax while your comparison does not, the timezones differ, Meta's attribution window credits purchases outside your date range, or deduplication is broken and orders are counted twice. Check the ratio first — it will point at which.
Free · 30 min
Get wrong currency or value sent diagnosed properly
WhatsAppFree30 minutesNo obligation
