GA4 purchases and your store's order records can disagree because of event collection, report definitions or the way an order changes after checkout. Start by matching individual orders and comparable amounts. Comparing two dashboard totals first often mixes several differences into one number.
We use a reconciliation worksheet to separate missing purchases, repeated events, value errors and reporting boundaries. The aim is a documented explanation of the gap, including any part the available evidence cannot explain.
In this guide
- Define the order population before exporting
- Choose the GA4 metric that matches the question
- Put order values on a common basis
- Build an order-level reconciliation worksheet
- Align timing, currency and refund handling
- Illustrative worked example: a small net gap hides two issues
- Turn exceptions into specific next checks
Define the order population before exporting
Choose one website journey, a fixed period and an explicit order status. Decide whether your business comparison means created orders, paid orders or another confirmed milestone. Record the choice before examining the result.
Exclude test, pending and cancelled records only when your chosen definition calls for it. Keep an exclusion list with reasons rather than silently removing inconvenient rows. An order created on Monday and paid on Tuesday also needs a stated date basis. Neither timestamp should be silently substituted for the other.
Export only the fields needed for the comparison. A non-identifying order reference, status, timestamps, currency and amounts are usually more useful than customer names, addresses or payment details. Save the export time because refunds and order edits can change the source records later.
Choose the GA4 metric that matches the question
GA4 contains several similarly named measures. Google's ecommerce metrics reference distinguishes these counting units:
- Ecommerce purchases counts the purchase event.
- Purchases includes multiple purchase-related event types, which matters for properties containing app activity.
- Items purchased measures item quantities, so a multi-item basket can exceed one.
- Transactions can include refund events and other transaction-related events.
For a website-order check, begin with a comparable purchase measure and the relevant stream. Do not use item quantities as an order count. Keep this first pass independent of campaign attribution; investigate advertising credit after the underlying purchase records are understood. Our Google Ads and GA4 comparison guide covers that separate step.
Put order values on a common basis
Write down exactly what each revenue column includes. Store labels such as sales, net sales and total paid may have different definitions. Separate merchandise, discounts, tax, shipping, refunds and payment-provider fees before combining anything.
The GA4 purchase specification defines event value as the sum of item price multiplied by quantity, excluding shipping and tax. It requires currency when value is supplied and describes discounted unit price separately from the discount parameter. Check the actual payload; a coupon label alone does not prove that the numeric amount reflects the discount.
Also distinguish gross and net metrics. The GA4 metric definitions describe Purchase revenue as purchase revenue less refunded transaction revenue, while Gross purchase revenue is the purchase sum before that refund subtraction. Total revenue can include other revenue sources. A merchant payout after processing fees is a separate financial measure.
Build an order-level reconciliation worksheet
Use one row per source order and maintain a separate refund log if orders can have several refunds. Add GA4-only transaction IDs as exception rows. This prevents a match rate from hiding extra measurement records.
| Field group | Columns to capture | Decision supported |
|---|---|---|
| Identity | Order reference, GA4 transaction ID, stream | Matches the same purchase across systems |
| Eligibility | Status, test flag, inclusion reason | Defines which orders belong in the comparison |
| Time | Created, paid and event timestamps; time zones | Finds date-boundary differences |
| Purchase amounts | Discounted merchandise, tax, shipping, currency | Creates comparable revenue values |
| Refunds | Refund date, merchandise amount, tax/shipping components | Separates gross purchases from later reductions |
| GA4 evidence | Observed ID, value, currency and refund evidence | Distinguishes matched, missing and conflicting records |
| Resolution | Explanation, supporting record, owner, next check | Leaves a usable action list |
Mark each order as matched, source-only, GA4-only or value mismatch. Add a separate flag when identity is unavailable. A plausible amount and nearby timestamp can suggest a match, but should not be presented as an exact match without supporting evidence.
Align timing, currency and refund handling
Use a shared reporting boundary
Check the store's export time zone and GA4's reporting time zone. Normalize timestamps in the worksheet rather than changing a live property's settings to force a match. Identify orders close to midnight and purchases confirmed after a payment redirect.
Allow for GA4 processing delays; Google says processing can take 24–48 hours and reports can change. Record when each report was downloaded. A recent gap can remain pending until the comparison has sufficiently mature data.
Compare original currencies before converted totals
Keep USD, EUR and other currencies separate on the first pass. Google's currency reference says Analytics converts local currency using the prior day's exchange rate for reporting. Your store or payment provider may use another rate or settlement date. Compare the original amounts before interpreting a converted-currency difference as lost revenue.
Verify the refund event path
A refund in the store does not by itself demonstrate that your current integration sent a refund to Analytics. Google's ecommerce implementation guidance uses a refund event tied to the relevant transaction ID and recommends item information for item-level refund reporting.
Check full and partial refunds separately. Keep an activity-period view of purchases and refunds alongside an order-cohort view that follows later refunds for those orders. Those two views answer different business questions and can legitimately produce different net amounts.
Illustrative worked example: a small net gap hides two issues
This constructed example is a worksheet exercise, not a client result or a platform test. Assume one currency, a mature reporting period, the same time boundary and all refunds in that period.
- Four paid orders contain US$120, US$80, US$60 and US$40 of discounted merchandise: US$300 in total.
- Shipping is US$15 and tax is US$30, making the original amount paid US$345.
- A US$20 merchandise refund reduces comparable net merchandise revenue to US$280.
- GA4 contains three purchases totaling US$240. The US$60 order is absent, and the US$20 refund has no recorded event.
The raw comparison, US$345 against US$240, suggests a US$105 gap. Removing shipping and tax from the business-side amount reduces it to US$60. Accounting for the business refund leaves a US$40 net gap.
That final US$40 still contains two opposing issues: US$60 of missing purchase value and US$20 of missing refund reduction. Fixing only one would leave the comparison wrong. Order-level evidence makes both visible.
Turn exceptions into specific next checks
For source-only orders, trace the completion event and collection path. For repeated IDs or apparent extra purchases, use our duplicate-conversion investigation. For matched orders with different values, inspect the merchandise calculation, currency and refund components.
Preserve unresolved exceptions rather than manufacturing matching totals. Do not delete live conversion actions or filters simply to improve agreement. Once the purchase baseline is understood, review the diagnostic scope to decide whether a focused investigation fits the remaining uncertainty.