Your shop takes payment in pounds, but Google Analytics 4 shows revenue in dollars. Or the report shows a pound sign while the amount still looks wrong. Before changing anything, separate the currency used to display reports from the currency sent with each purchase.
Those are different checks. Start with one traceable order, establish what the website actually sent, then decide whether the repair belongs in GA4, your ecommerce integration or a separate reporting dashboard. This guide covers website purchase reporting for UK businesses.
Establish where the wrong currency appears
Open GA4 itself and compare the affected figure with the report your team normally uses. Record the property name, date range, metric and currency symbol. If the discrepancy appears only in a spreadsheet or connected dashboard, investigate that report’s data source and formatting before editing website tags.
Next, choose a completed order whose amount you can explain. Record its reference, payment currency, discounted product subtotal, delivery charge and tax. Keep customer names and contact details out of the troubleshooting evidence.
Use that order to answer three questions:
- What currency did the customer actually pay in?
- What amount and currency did the website send to GA4?
- What reporting currency is the property using?
A UK business address does not answer all three. An overseas customer may pay in another currency, and the analytics configuration needs to describe that transaction accurately.
Check the GA4 reporting currency
Google’s currency reference explains that the property’s currency determines how monetary values appear in reports. It also confirms that changing this setting affects historical as well as future data. Treat it as a reporting change with consequences for previous comparisons.
If your business reports in sterling, the relevant code is GBP. Google’s current property-editing instructions place the setting under Admin > Property > Property details. Someone with Editor access or above can change Currency and save.
Before an authorised colleague makes that change, save a reference export of the affected report and record its existing currency. Tell whoever prepares management reporting when the setting changes, so they can explain differences from earlier exports.
If the website sent a correctly labelled sterling purchase and the property displayed it in dollars, changing the reporting currency addresses the display and conversion choice. If the website labelled a sterling amount as dollars, investigate the transaction data too. A different report symbol is insufficient evidence that the underlying problem is fixed.
Inspect the currency sent with the purchase
Ask your developer or analytics specialist to trace the purchase through the integration that sends it. That might be an ecommerce plugin, tag-management setup or server integration. Establish which route is responsible before installing another tracking tool.
Google’s missing-revenue troubleshooting guidance specifies an event-level currency using a three-letter ISO 4217 code and a numeric value. Parameter names are lowercase; the sterling currency code is uppercase GBP. The value must exclude currency symbols.
For an illustrative purchase value of £85.50, the relevant pair would be currency: 'GBP' and value: 85.50. Sending '£85.50' as the value gives the integration a formatted text amount rather than the required number. Sending 8550 would describe a very different amount.
Look for a fixed USD copied from an example, a missing currency variable or an amount taken from a different stage of checkout. For Tag Manager implementations, Google advises checking both the website’s data layer and the Analytics event tag. A correct value in the data layer still needs the right mapping into the event.
If you sell in more than one currency
Keep each transaction’s amount and currency together. Google supports sending local transaction currencies and converts them into the property’s reporting currency using the previous day’s exchange rate. It follows that an order genuinely paid in euros should retain its euro amount and EUR code.
A blanket replacement of every currency with GBP would misdescribe those overseas purchases. Test a sterling checkout and each other supported currency separately. Ask the integration owner to show which order field supplies the amount and which supplies its currency.
Check the amount before blaming exchange rates
Currency may be correct while the purchase amount is wrong. Google’s purchase-event reference defines value as the sum of item price multiplied by quantity, excluding shipping and tax. Item prices use units of the specified currency, with discounted unit prices where a discount applies.
For example, take two items with a discounted unit price of £30 excluding tax, plus £12 tax and £5 delivery. The example’s purchase value is 60, with tax and shipping supplied separately. Comparing that value directly with the customer’s £77 payment would create an apparent £17 shortfall.
Ask your developer to reconcile a real order on the same basis. Check whether the integration uses the discounted subtotal, includes delivery twice, handles quantities incorrectly or sends pence where pounds are expected. Write down the calculation so another person can reproduce it.
Keep the investigation focused. If individual amounts and currencies are correct but the same order appears repeatedly, follow our separate guide to duplicate purchases in GA4.
Check imported advertising costs before changing reporting
If you combine sales with imported advertising spend, check the cost side too. A revenue repair alone leaves the commercial comparison unfinished.
Google’s current campaign-data import documentation requires a currency when an import includes cost. It supports mapping that currency from the source data or assigning a static currency to the import.
Confirm that a static choice matches every cost amount covered by it. Where the source contains multiple currencies, review the mapping with the person responsible for the import. Record any uncertainty about older imports before comparing the revised figures with previous reports.
Verify a complete purchase after the repair
Agree a controlled test with the shop owner and developer. Use an appropriate test environment or an agreed live test that can be reconciled afterwards. Identify the expected amount and currency before completing checkout.
Google’s DebugView guidance explains how to enable debug mode for your test device and inspect an event’s parameters. Check the received purchase for the expected currency and value. If events are absent, investigate privacy controls and Analytics-cookie consent as well as the tracking implementation; Google identifies both as reasons debug events may be invisible.
Keep the existing consent choices working during testing. Then review processed reporting separately, allowing time for the test data to appear. A purchase visible in a debugging tool is one stage of verification.
Ask for evidence that:
- The completed order has the expected amount and payment currency.
- The received purchase event describes that same order correctly.
- The property reports monetary values in the agreed currency.
- A discounted basket and a basket with delivery follow the agreed value calculation.
- Any additional checkout currencies and imported costs remain correctly labelled.
Explain the affected reporting period
Record when the fault began, what caused it, what changed and when the repaired journey passed testing. Separate a reporting-currency change from incorrectly submitted transaction data. Do not assume that correcting future events makes the affected historical period dependable.
Keep reconciled shop records as your reference for actual orders and payments. Annotate affected marketing reports, explain any estimates and postpone decisions that depend on unreliable revenue figures. Our guide to connecting conversion reporting with sales sets out the wider discipline of comparing platform activity with business outcomes.
If your shop, GA4 and marketing reports disagree about revenue, talk to BuzzBoost. We can help trace the order data, agree the right reporting basis and verify the customer journey before you rely on the figures.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
