GA4 ecommerce revenue is built from browser and app events, not from bank settlements. A purchase event records a transaction_id and item values when the tag fires; a refund event later reduces that revenue only if it carries the matching transaction_id. Bank deposits follow payment-processor timing, fees, chargebacks and settlement rules, so the two numbers measure different things and rarely match exactly.
What GA4 actually records when a purchase happens
Google's ecommerce documentation describes a purchase event as a user action that carries an items array, a currency, and a transaction_id. The value is whatever the implementation sends at the moment the tag fires — typically the order total shown to the customer. That is an event record, not an accounting entry. Official source
Three practical consequences follow. First, the event can fire before payment authorisation completes, so a declined card may still produce a purchase event. Second, the value may exclude or include tax, shipping and discounts depending on how the data layer is built. Third, if the tag is blocked or the user closes the tab, the event never arrives and the revenue is invisible in GA4 even though the order exists in the store backend.
How GA4 refunds reduce revenue
The same documentation states that refunds are measured by sending a refund event with the relevant transaction_id and one or more items defined with item_id and quantity. The purchase event replaces ecommerce_purchase and is different from the in_app_purchase event, which is reported automatically. Official source
This is the mechanism that matters for reconciliation. A refund event does not automatically know which purchase it belongs to unless the transaction_id matches. If your store sends a refund with a different ID format, or sends only a partial item list, GA4 may record the refund without correctly offsetting the original purchase. The result is tracked revenue that looks higher than net revenue after returns.
A second subtlety: refunds can be partial. If a customer returns one item from a three-item order, the refund event should carry that item_id and quantity. Sending the full order value as a refund overstates the reduction. Sending no items at all may leave the refund unattributed.
Why bank deposits follow a different timeline
Banks and payment processors settle on their own schedule. Card networks batch transactions, hold funds for risk checks, and deduct fees before depositing. A sale recorded in GA4 on Monday may appear in the bank on Wednesday, or later. A refund recorded in GA4 on Friday may not leave the bank until the next settlement cycle.
Chargebacks add another layer. A chargeback is not the same as a merchant-initiated refund. It is a dispute raised by the cardholder's bank, and it may never appear as a GA4 refund event unless your store explicitly sends one. That means GA4 revenue can stay high while bank deposits fall.
Currency conversion is a third source of divergence. GA4 records values in the currency you set for the event. The bank converts at its own rate and may apply cross-border fees. For UK and US merchants selling internationally, the gap between the two numbers can be partly explained by exchange rates alone.
A diagnostic method you can run
Start with a small sample. Pick one day and export three lists: GA4 purchase events with transaction_id and value, your store's order records for the same day, and the bank or processor settlement report. Match them by transaction_id where possible.
Then classify each mismatch into one of five buckets: event missing, value mismatch, timing difference, refund not matched, or chargeback. This is a classification exercise, not a search for a single bug. Most discrepancies fall into more than one bucket.
A hypothetical example: a store records 100 purchase events in GA4 on a given day, totalling 10,000 in the store's currency. The bank deposit for the same period shows 9,200. The difference might be 300 in processor fees, 200 in a refund that was sent without a matching transaction_id, and 300 in a purchase event that fired before a payment failed. These figures are illustrative only and not a benchmark.
For a broader look at how store structure affects what analytics can see, see Ecommerce SEO: build a store people can actually find.
What the evidence supports and what it does not
The official documentation supports the event mechanics: purchase and refund events, transaction_id, item_id, quantity, and the fact that the purchase event replaces ecommerce_purchase. It does not provide a reconciliation formula, a fee model, or a settlement timetable. Those depend on your payment provider, your bank, and your local market.
In the UK and US, card settlement practices and fee structures differ. In France, Belgium and Switzerland, local payment methods and VAT treatment can change both the amount and the timing. Do not transfer one country's assumptions to another. The correct approach is to document your own provider's settlement rules and compare them against your event data.
What you can verify without guessing: whether your refund events carry the same transaction_id format as your purchase events, whether partial refunds include item_id and quantity, and whether your data layer sends value before or after payment authorisation. Those are implementation checks, not accounting opinions.
When to treat the gap as expected
Some divergence is normal. Fees, timing, currency conversion and chargebacks all create legitimate differences. The goal is not to force GA4 to equal the bank. The goal is to know which differences are explainable and which point to a tracking defect.
A useful rule: if every mismatch can be classified into a known bucket, the gap is understood. If a large unexplained residual remains after classification, investigate the tag implementation and the refund event payload. For related measurement questions, see One-Click YouTube Shorts Ads: Measuring the Path From Discovery to Site.
Follow-up questions
Does GA4 revenue ever match bank deposits exactly?
Rarely, and only by coincidence. GA4 measures events; the bank measures settled money after fees, timing and disputes. A close match is possible for simple, domestic, card-only stores with immediate settlement, but it is not a reliable expectation.
Should I change my refund event to fix the gap?
Only if the refund event is missing a matching transaction_id or item details. Fixing the event improves attribution, but it will not remove fees, settlement delays or chargebacks. Treat the event fix and the reconciliation exercise as separate tasks.