Which day was it? Timezones, currencies and the numbers that never reconcile
Short answer:if your tool decides what counts as “today” using a timezone that is not yours, every daily number is cut in the wrong place. Sales made in your evening land on the wrong day, and comparing yesterday against last Tuesday quietly stops meaning anything. It is the least glamorous reason a dashboard disagrees with reality, and one of the most common.
Where the day actually gets cut
Every daily figure depends on a boundary: the moment one day ends and the next begins. Set that boundary in the wrong timezone and a sale at 11pm in Riyadh is recorded as the following day, or the previous one.
On its own that is a small distortion. It compounds in three places that matter:
- Day-on-day comparisons. Both days are mis-cut, so the change between them is measuring the boundary as much as the business.
- Peak-hour analysis. Your busiest hour appears at a time nobody was in the shop, which quietly misinforms staffing and scheduling.
- Month end. The last evening of the month falls into the next month, so both months are wrong and the year-on-year comparison inherits it.
And the same for currency
A store selling in more than one currency, or a business in the Gulf that is not in Saudi Arabia, hits the second half of this. If figures are converted at the wrong moment, or assumed to be in a currency they are not, the total is not slightly off, it is a mix of units added together.
The tell is a revenue number that cannot be reconciled with the bank no matter how the periods are sliced. That is usually not a tracking problem at all; it is an arithmetic one.
Where MIQAS comes in
Every workspace carries its own timezone and its own currency, and the day boundary is computed from the workspace’s timezone rather than from a fixed one. A business in Riyadh, Dubai or Cairo each gets days cut where its own days actually end.
Order values are converted on arrival into the workspace currency, so reports stay in one unit and a store selling in another currency does not corrupt the total.
It applies everywhere the same way: website orders, uploads and API. There is no surface that quietly uses a different clock, which is the failure people usually discover by finding two screens that disagree.
This is not a paid upgrade. It works from Starter, because a wrong day boundary is not a premium problem.
Check yours in five minutes
- Take yesterday’s order count in your store and in your dashboard. If they differ by a handful, look at what time those orders were placed.
- Open your peak-hours view. If the busiest hour is one you know is quiet, the day is being cut in the wrong timezone.
- Compare a full month against your accounting. A gap that lands entirely on the first and last days is a boundary problem, not a tracking one.
Most measurement arguments are about attribution. Some are just about which day it was.