Start with the question behind the gap
A shop reports 120 orders while GA4 shows 103 purchases. The gap is 17, but that subtraction does not tell you why they differ. It also does not prove that 17 customers failed to pay or that 14.2% of revenue disappeared. The shop records operational events; analytics receives measurement events. Before changing a tag, establish which business question the comparison should answer.
For a new setup, agree the reconciliation method before launch. For an existing site, choose a completed reporting period and preserve the original exports. A useful first question is: of the paid website orders we expect this implementation to measure, which can we identify in the relevant analytics dataset? Revenue, attribution and advertising-platform discrepancies can then receive their own comparisons.
Make the two totals comparable
Write a definition beside each total. For the shop, record included statuses, sales channels, timezone and the treatment of test orders. Name the GA4 metric and report precisely. A purchase count and an item quantity answer different questions. Likewise, paid orders and orders created can differ without either report being wrong. Save the filters so another person can reproduce your comparison.
Consider an illustrative worksheet. The shop's 120 orders contain five staff tests, four unpaid orders and three orders entered by the sales team outside the website checkout. If the agreed scope is paid website orders excluding tests, the comparable shop total is 108. GA4 still contains 103 purchases, leaving five to investigate. None of those exclusions should be assumed on a real account: each needs a documented rule and supporting records.
Keep a separate row for unresolved scope questions. For example, if subscriptions renew through a billing platform, decide whether renewals belong in this website measurement comparison. Do not quietly change the denominator until the discrepancy looks acceptable.
Check timing before diagnosing collection
Google's data-freshness documentation says GA4 processing can take 24–48 hours and figures may change during processing. A comparison made halfway through today is provisional. Reports also have different freshness characteristics, so record when each export was taken and repeat the comparison after the relevant processing window. This is a timing check, not a promise that every discrepancy will resolve after two days.
The business timestamp matters too. An order created at 23:58 may be paid at 00:03. If the shop groups by creation time and the purchase event represents payment confirmation, the records can land on different dates. Use a boundary transaction to test the rule explicitly, including timezone. For the first investigation, a complete week can reduce midnight noise, but it does not replace agreeing the correct timestamp.
Documentation: Google Analytics: data freshness
Reconcile identifiers before percentages
Create a small worksheet with order reference, order status, expected measurement moment, observed purchase identifier, checkout route and evidence note. Use references that do not contain customer names or email addresses. Where access permits, match records by transaction identifier rather than trying to infer matches from similar amounts. Mark unavailable identifiers as unavailable; an aggregate report is not an order-level receipt log.
Continue the illustrative example. Suppose 101 identifiers match, seven eligible shop orders have no match, and two GA4 identifiers do not appear in the eligible shop set. The aggregate difference is still five, but there are nine records requiring explanation. Looking only at the difference would conceal the two unexpected analytics records and understate the number of unmatched shop records.
For each unmatched record, investigate its own history. A missing match may reflect a different identifier format, scope exclusion, delayed observation or absent collection. Keep those explanations separate. This worksheet describes the records examined; a small convenience sample cannot establish a site-wide loss rate.
Test the checkout conditions that matter
Build a test matrix from the actual checkout: standard card payment, express wallet, redirect to a payment provider, payment failure, retry and confirmation-page reload. Add the browsers and devices that matter to the business. Record the expected event moment before testing. A test purchase should produce evidence at the relevant implementation and reporting stages, with screenshots or traces labelled by environment and time.
Consent choices belong in that matrix. Google's Consent Mode overview distinguishes basic mode, which blocks Google tags until the relevant consent interaction, from advanced mode, which can send measurements without cookies while storage consent is denied. A network request after rejection therefore needs inspection in context; its presence alone is not a failure verdict. The configured consent behaviour and the actual request contents both matter.
If one payment route repeatedly misses the purchase while another works under comparable conditions, write that narrow finding. Include the reproduction steps and observed evidence. Do not turn a failed test on one route into a claim about every checkout, and do not describe unobserved purchases as failed payments.
Documentation: Google: Consent Mode overview
Reconcile money separately from order counts
Google's ecommerce guide defines purchase and refund events separately and provides transaction, currency, item, tax and shipping fields. Inspect how your implementation populates them. A refund recorded in the shop is not evidence that analytics received a refund. Similarly, two systems can count the same transactions while reporting different values because they include different components.
Use a hypothetical order to make the calculation reviewable: items total 80, shipping is 5 and tax is 16, all in the same currency. Write which amount each metric is supposed to represent, then compare the actual payload with that definition. Repeat for a discount and a partial refund. Check count and value independently; a correct purchase count cannot validate the revenue calculation.
Documentation: Google Analytics: measure ecommerce
Turn the findings into a repair and verification brief
Group the reconciliation into definition differences, timing differences, observed collection limits, reproducible defects and unresolved questions. Each proposed repair needs an owner, the affected path and a verification method. For example: confirm that the wallet return route emits the agreed purchase event, then repeat the same successful-payment, failed-payment and reload tests after the change.
Keep the original evidence alongside the new results. Compare an equivalent period after release, allowing processing time and recording changes in payment mix or consent behaviour. Do not declare the problem solved solely because one test appeared in a debugging tool. The useful deliverable is a reproducible reconciliation, a set of verified fixes and a clear statement of what remains outside the measurement's reach.