Settlement Cutoffs and Time Zones: Matching the Right Reporting Day

Header image: conceptual illustration.

A merchant counts a payment in Sunday's report, while the provider includes it in Monday's settlement batch. Both records can be internally correct because they use different time zones, cutoff rules or date definitions.

Settlement matching needs more than converting a timestamp for display. The team must define what each date means, where the reporting interval begins and ends, and which calendar determines availability or bank processing.

Name each time boundary

Distinguish payment initiation, successful completion, provider balance availability, settlement creation, expected bank arrival and actual bank posting. A record can have several valid dates across these stages.

Do not use the bank posting date as if it were the customer payment time. Do not assume the provider's report date equals the merchant's local business day. The settlement cycles guide explains the broader lifecycle; this article addresses the date-boundary mismatch inside that lifecycle.

Store timestamps in an unambiguous form with a time-zone offset or UTC representation. Store the business-day definition separately. A time-zone-aware display helps a human read the record, but a report filter must also use the correct interval semantics.

Agree the reporting calendar

Define the local business day, provider reporting zone, settlement cutoff, holiday calendar and the report's start/end inclusion rules. Use named time zones where seasonal clock changes may apply rather than assuming one fixed offset forever.

The seasonal-clock caution concerns reporting zones that change their clocks; the Dhaka calculations below consistently use UTC+6. A cross-border provider may report in another zone. The merchant must verify the actual contractual and technical rules; no particular cutoff or settlement speed should be inferred from geography alone.

Stripe's payout report schema exposes report interval and time-zone parameters. That is an example of why the precise report definition matters. Different report versions or providers may represent the boundary differently.

Worked hypothetical day boundary

Invented example: A payment completes at 23:50 UTC on 11 October. In Dhaka that is 05:50 on 12 October. A UTC calendar-day collection report places it on the 11th; a Dhaka calendar-day report places it on the 12th.

Neither date alone determines its bank settlement date. The provider's documented availability and batch rules determine whether it is included in the next settlement. Finance therefore compares the payment timestamp, reporting-day conversion and actual batch identifier separately.

For a Dhaka calendar day from 00:00 to the next 00:00, the equivalent UTC interval starts at 18:00 on the preceding date and ends at 18:00 on the named date. This is arithmetic for the hypothetical report definition, not a claim that any provider uses that cutoff.

Prevent gaps and double inclusion

When building adjacent reports, define one consistent boundary convention, such as including the start and excluding the end if the source system supports that meaning. Then test a transaction exactly on the boundary. Do not assume every API uses the same convention.

Retain the selected time zone and interval in report metadata. Without them, two exports named daily settlement can contain different populations while looking identical to finance.

Re-exporting an earlier period after late adjustments may legitimately change the result. Label the report version and generation time, and decide whether the close process permits revisions or records later adjustments in a subsequent period. Never erase the earlier export simply because the new total differs.

Handle weekends and holidays without promises

Ask the provider which calendar governs settlement availability and which governs bank movement. Confirm whether calendar days or business days apply to each stage. A customer payment accepted on a weekend does not establish that merchant funds will arrive at the bank that day.

Keep the expected date qualified until the actual bank record is available. If an expected movement is late, compare the relevant cutoff, holiday and provider status before declaring a missing settlement. The provider selection guide includes service-commitment questions that can be made precise with these definitions.

Boundary test checklist

• One record immediately before and one after the reporting cutoff.
• One record exactly on the cutoff.
• Adjacent exports with no unexplained gap or duplicate row.
• A timezone display different from the provider's reporting zone.
• A weekend and a documented local bank holiday.
• A later refund or adjustment relating to an earlier payment.
• A regenerated export with clear version and generation metadata.

Frequently asked questions

Should all systems use the merchant's local time?

They need consistent, explicit representations, not necessarily one display zone. Preserve source timestamps and apply the correct business-day definition when reporting.

Does T+1 always mean tomorrow?

No. The contract and payment method determine what T represents, whether business days apply and how cutoffs affect inclusion. Confirm those definitions before giving an expected date.