Every number in a store is filed under a day, and days are not a fact of nature but a decision about a clock. An order placed at half past eleven at night in Berlin belongs to that day for the merchant who took it, and can belong to the next one in a system reporting in UTC, or the previous one in a platform reporting in Pacific time. Over a month the edges blur into insignificance; on a single day, or across a month boundary, the same euro legitimately sits in two different periods in two different reports, and everybody spends an afternoon looking for a bug that is not there.
- A day is defined by a timezone, and reports that do not state theirs cannot be reconciled.
- Evening orders near midnight are the ones that move between days, which is why month boundaries are where the confusion lands.
- The store's own timezone is the only defensible convention, because that is the day the merchant experienced.
- Daylight saving makes two days a year 23 or 25 hours long, which is a real thing to handle rather than an edge case to ignore.
Why the store's own clock wins
A merchant reasons in local days: a Saturday is a Saturday, a bank holiday is a quiet Monday, a campaign starts at nine in the morning. A statement in UTC would tell that merchant their best hour happened yesterday, which is technically defensible and operationally useless.
It is also the only convention that stays consistent as a store grows. Selling into three countries does not create three days; it creates one day, in the store's own timezone, containing orders from three places, which is exactly how a merchant thinks about it.
Where it bites: the month boundary
The last two hours of the last day of a month are the whole problem. Those orders sit in either month depending on the clock, and a store comparing a platform's monthly figure with its own will find a difference roughly the size of two hours of trading, appearing and disappearing with no pattern.
This is one of the standard reasons why your Shopify numbers never match, and the fix is not to reconcile it every month but to name it once: state which clock each report uses, and stop expecting two clocks to agree.
The report that has no timezone at all
A surprising number of exports carry a date with no time and no zone, which quietly hands the decision to whichever tool opens the file. A spreadsheet in one locale and a database in another will file the same row differently, and neither will mention it.
The defence is to keep timestamps rather than dates wherever the data allows it, and to convert once, deliberately, at the moment a figure is assigned to a day. Converting twice, or converting a date that was already local, is how a report ends up a day out for exactly the orders near midnight and correct for everything else, which is the hardest kind of error to notice.
Daylight saving, briefly
Twice a year a local day is 23 or 25 hours long. It matters less than people fear for revenue, which simply has an hour more or less to accumulate in, and more than they expect for anything computed per hour or compared with the same weekday a year ago. Handling it correctly means working in the store's timezone with real calendar arithmetic rather than adding 86.400 seconds and hoping.
The platforms will not agree with each other
Ad platforms report in their own account timezone, which is set once at account creation and frequently by somebody who is no longer at the company. So a day of spend on one platform and a day of spend on another can cover different sixteen-hour windows, and neither matches the store.
There is no clean fix, only an honest convention: take spend from the billing side, file it under the store day it was reported for, and accept that a single day can be an hour or two out while a week is exact. Anyone reconciling advertising to the hour is chasing a precision the platforms do not offer.
The rule, and how to keep it
Pick the store's timezone, apply it to every recognition date in the business, and never let a second clock in. Sales on the order day, refunds on the day they were issued, ad spend on the day it ran, fixed costs spread across the days they cover, all in one timezone, which is what makes a statement comparable day to day rather than an interesting collection of numbers.
If you are building this by hand, the daily P&L tracker is one row per day for exactly this reason: the row is the unit, the day is defined once, and every figure on it was filed by the same clock.