What should a team validate first when time zone gotchas: why your ga4 days don't match your bookkeeping appears?

Reproduce the problem in the live implementation, isolate whether it is scoped to one report or flow, and compare it against at least one secondary source before changing the setup.

How do I know whether the fix actually worked?

You need before-and-after evidence in the browser and in the downstream report. A clean-looking dashboard without validation is not enough.

When should this become a full GA4 audit instead of a quick fix?

If the issue touches attribution, consent, revenue, campaign quality, or data trust for more than one workflow, it is usually safer to audit the surrounding implementation than patch only the visible symptom.

Time Zone Gotchas: Why Your GA4 Days Don't Match Your Bookkeeping (2026)

Why don't my GA4 days match my finance reports?

GA4 aggregates everything by the property's reporting time zone — set in Admin → Property settings → Time zone. Your finance system aggregates by its own time zone (often the company's HQ zone). When the two differ, day-level revenue numbers disagree by however many transactions cross the day boundary in either direction.

A US e-commerce store with finance in EST but GA4 set to UTC will show different "yesterday's revenue" than the bookkeeping system. Changing GA4's time zone after data exists creates permanent historical discontinuity — past data stays in the old zone, new data uses the new zone.

The standard fix: align GA4's reporting time zone with your finance system on day one, document any later changes carefully, and reconcile differences via BigQuery for periods spanning a time zone change.

How GA4 handles time zones

The reporting time zone setting controls:

The day boundary for daily aggregation (when "today" ends and "tomorrow" begins in reports)
The week boundary for weekly aggregation
The month boundary for monthly aggregation
The hour buckets in hourly reports
BigQuery export's event_date field uses this time zone

What it does NOT control:

The event_timestamp field in BigQuery — that's UTC microseconds since epoch, regardless of property time zone
User-side cookie timestamps (those are user's local time)
Server log timestamps (those are server's time)

The translation between UTC event_timestamp and the reporting time zone is what produces day-boundary effects. A purchase at 23:30 UTC on May 1 is "May 1" in UTC, but "May 2" in Asia/Tokyo (UTC+9). GA4 reports it on whichever day matches the property's reporting time zone.

The four common scenarios

Scenario 1 — GA4 in UTC, finance in local time

Most common in international e-commerce. GA4 was set up by an engineer who picked UTC; finance runs on the company HQ's local time (e.g., America/New_York).

Day-level numbers disagree. End-of-month numbers usually match (transactions average out across the month), but specific daily, weekly, and yesterday's numbers don't.

Fix: Change GA4's time zone to match finance. Accept the historical discontinuity (annotated). Reconcile pre-change data via BigQuery using a custom query that aligns to finance's time zone.

Scenario 2 — Multi-region operations with single time zone

A company with offices in London, New York, and Tokyo. GA4 set to one of them — typically the primary office.

Different regional teams see "today's traffic" differently. London team sees the day starting at midnight UK time; New York team sees a different "today."

Fix: Pick one canonical time zone (usually company HQ) and document. Train regional teams that GA4's "today" is HQ's today, not theirs. Or build BigQuery-backed regional dashboards using each region's local time zone for that team's reports.

Scenario 3 — Daylight Saving Time transitions

When a region transitions to/from DST, the day in question has either 23 or 25 hours. GA4 handles this — but week-over-week comparisons across DST boundaries show one day with abnormal hourly distribution.

Fix: Annotate DST dates on hourly reports. For week-over-week analysis spanning DST, expect 4-7% variance attributable to the hour difference, not actual traffic changes.

Scenario 4 — Server-side events with timestamp manipulation

Want to see which hidden implementation gaps are affecting your GA4 data quality?

Start free audit

Server-side GTM or Measurement Protocol events with custom timestamps can produce events with timestamps that don't match real time. If your sGTM transformation modifies event timestamps, you can shift events into wrong days.

Fix: Don't manipulate event_timestamp unless you understand exactly what you're doing. The default behaviour (server records receipt time) is usually correct.

The "changing time zone" gotcha

Once GA4 has data, changing the reporting time zone has no retroactive effect. Historical data was aggregated under the old zone; new data aggregates under the new zone. Year-over-year reports spanning the change will show artificial discontinuity.

The mechanic: GA4's daily aggregations are computed and stored. Changing time zone doesn't recompute them. So a daily report shows:

Pre-change days: aggregated by old time zone
Post-change days: aggregated by new time zone

Standard reports may show this as a discontinuous line on the change date.

The pragmatic recommendations:

Set the right time zone on day one. Match your finance system's time zone.
If you must change it, annotate the change date prominently in dashboards and ensure all stakeholders understand the discontinuity.
For pre-change data analysis, use BigQuery with a custom day-boundary that matches the new time zone. The event_timestamp UTC field lets you re-aggregate to any time zone.

The reconciliation pattern

When finance asks "why does GA4 show £100k for May but bookkeeping shows £95k?":

Step 1 — Confirm the discrepancy is time-zone, not data quality

Use BigQuery to recompute revenue for the period using finance's time zone:

Compare this BigQuery-computed daily revenue against:

GA4 standard report revenue (aggregated by property time zone)
Finance system revenue (aggregated by their time zone)

If your BigQuery query (using finance's zone) matches finance, the discrepancy is purely time-zone. If it still doesn't match finance, you have a data-quality issue (duplicate transactions, missing refunds, etc. — see those posts).

Step 2 — Standardise on one time zone going forward

If GA4 and finance use different zones, decide which is canonical. Usually finance wins because they're the source of truth for revenue numbers.

Either change GA4's time zone (with the discontinuity caveat above) or build BigQuery-backed reports using finance's time zone for stakeholder consumption.

Step 3 — Document the chosen time zone everywhere

Every dashboard, every export, every report should show the time zone explicitly: "All numbers in America/New_York time zone unless otherwise specified." Removes future ambiguity.