WooPayments reconciliation reports are produced on a defined reporting clock, while a business may close books in America/Chicago, Europe/London, or another local timezone. Transactions near midnight can fall into different calendar months between systems. Without a cutoff bridge, finance may call a timing difference a missing payment or count it in both periods.
Use this for month-end close when the store, processor report, bank account, and accounting ledger do not all use the same timezone. It is most important around daylight-saving changes, late-night sales, refunds, disputes, and multi-day payouts.
Quick answer
Record the exact local close instant and convert it to UTC. Export a buffer window on both sides, identify transactions whose local and UTC dates fall in different months, and post one boundary schedule that moves those rows to the correct accounting period without changing the processor report. Reconcile the adjusted total to the ledger and retain both timestamps.
What to check first
- Document the business timezone, daylight-saving rule, accounting cutoff, report timezone, and bank posting timezone.
- Export transaction, fee, refund, dispute, and payout rows for at least 48 hours around the boundary.
- Preserve event time, available-on time, payout time, UTC offset, currency, and stable transaction identifier.
- Classify each boundary row as current-period activity, next-period activity, in-transit cash, or a true exception.
- Tie the bridge total to both the unadjusted WooPayments report and the local accounting ledger.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze the source exports and record their generated time and filters. | Document the business timezone, daylight-saving rule, accounting cutoff, report timezone, and bank posting timezone. | The unadjusted report plus the documented bridge equals the local-period ledger activity. |
| Convert the approved local cutoff to UTC using the named business timezone. | Export transaction, fee, refund, dispute, and payout rows for at least 48 hours around the boundary. | Every boundary row appears in exactly one accounting month. |
| Build the boundary schedule with both timestamps, IDs, classes, and amounts. | Preserve event time, available-on time, payout time, UTC offset, currency, and stable transaction identifier. | Payout and bank timing differences roll forward and clear with the same stable IDs. |
| Post the controlled period adjustment to the accounting ledger or close workbook. | Classify each boundary row as current-period activity, next-period activity, in-transit cash, or a true exception. | The close package retains source exports, timezone rule, bridge, reviewer, and signoff time. |
Why this usually happens
- Calendar-date filters hide the timestamp and offset that determine period ownership.
- Processor availability, payout creation, and bank settlement are separate dates with different accounting purposes.
- Daylight-saving transitions make a fixed numeric offset unreliable across the year.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
close_timezone: America/Chicago
local_cutoff: 2026-07-31T23:59:59-05:00
utc_cutoff: 2026-08-01T04:59:59Z
bridge_window_start: 2026-07-31T00:00:00Z
bridge_window_end: 2026-08-02T00:00:00Z
unique_key: transaction_id + currency
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Sale before local midnight | Charge at 23:55 local with next-day UTC date | Activity belongs to the local month and appears once in the bridge |
| Refund after local midnight | Refund at 00:05 local with prior processor business date | Refund belongs to the new local month with linked original charge |
| DST boundary | Timestamp during offset change | Stored UTC timestamp and named zone produce one unambiguous local instant |
| Payout in transit | Payout created before cutoff and settled after | Cash clearing entry carries the amount without duplicating revenue |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze the source exports and record their generated time and filters.
- Convert the approved local cutoff to UTC using the named business timezone.
- Build the boundary schedule with both timestamps, IDs, classes, and amounts.
- Post the controlled period adjustment to the accounting ledger or close workbook.
- Reverse or roll the in-transit portion according to policy and obtain controller signoff.
Decision rule
Accept a difference as timing only when every amount maps to a stable processor ID, a specific cutoff rule, and the next expected settlement or reversal. Investigate anything that lacks an ID, appears twice, changes currency, or remains open after the expected window.
Production verification checklist
- The unadjusted report plus the documented bridge equals the local-period ledger activity.
- Every boundary row appears in exactly one accounting month.
- Payout and bank timing differences roll forward and clear with the same stable IDs.
- The close package retains source exports, timezone rule, bridge, reviewer, and signoff time.
Field notes
- Store UTC as the immutable event time and derive the local display with an IANA timezone name.
- Do not edit the WooPayments export to force agreement. Keep the source export and a separate adjustment schedule.
- Use stable IDs to prevent a boundary row from appearing in both the current and next month bridge.
Questions teams ask during testing
Which date should finance use?
Use the accounting policy for revenue and cash, then bridge processor event, availability, payout, and bank dates explicitly.
How large should the buffer window be?
Use enough time to capture every boundary transaction and delayed status change. Forty-eight hours is a practical starting point, not a universal rule.
Does changing the WordPress timezone fix reports?
No. The store display setting does not rewrite processor event timestamps or accounting policy.
Mistakes to avoid
- Do not filter only by date while discarding timestamps and offsets.
- Do not use a fixed UTC offset for a timezone that observes daylight-saving changes.
- Do not post payout timing as new revenue.
- Do not overwrite source exports with adjusted local dates.
What to tell the client or owner
Share the business timezone, local and UTC cutoff, report generation time, boundary row count, bridge amount by currency, open exceptions, clearing date, reviewer, and signoff.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, reconcile WooPayments month-end timing.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references