Month boundaries and timezones

At month end the awkward transactions are the ones near a boundary: the order that shipped at 11 PM on the 30th, the marketplace event stamped a few minutes after midnight, the invoice your accounting provider thinks belongs to the following day. This page explains which date decides a month, why the ordinary near-midnight cases need nothing from you, and which boundary cases genuinely do.

A month is a calendar month in your business timezone

Every month on the Close tab is a plain calendar month, shown under the month name as its first and last day — for example Jun 1, 2026 – Jun 30, 2026. Those two dates are days in your business timezone, the one set in Settings → General under Date & Time → Timezone. They are not days in UTC, and they are not tied to where the person running the close happens to be sitting.

That single decision drives everything else. The month's checks count the entries dated in those days, the nine reports in the report pack cover those days, and closing the month locks the books through that last day — the closed month reads books locked through Jun 30, 2026 next to its dates.

Which date decides the month

"Dated in June" is doing a lot of work in that sentence, so it's worth being exact about which date is meant. For an accounting entry it is the entry's Effective date — the one the entry page labels that way, with the tooltip Accounting effective date — the date this entry posts to in your books, and the one the Date column shows in Accounting → Transactions. It is not the Created At column beside it, which is the moment the entry was generated, and not the Posted at timestamp on the entry page, which is the moment it reached the books. Both of those are housekeeping; only the Effective date decides a month. The date filters under Advanced Filters → Dates keep the three apart in the same way — Date, Posted At and Created At are separate conditions, and Date is the one you want.

Not everything on the checklist is an entry, though, and the parts that aren't go by a date of their own. This is the whole map:

On the checklist or in the pack	The date it goes by
All entries balanced, Entries synced, Needs-attention inbox clear	Each entry's Effective date, inside the month's window.
Income Statement, COGS	The same window — every entry whose Effective date falls in the month, and nothing outside it.
Trial Balance	Both at once. Its debit and credit columns are the month's window; its opening and closing balance columns carry everything before the window and everything up to the end of it.
Balance Sheet, Inventory Valuation, GINR Balance	Not a window at all: the position as at the last instant of the month's last day, carrying everything before it.
Ledger generation — batches	The batch's own period end, not the dates of the entries inside it. Every unposted batch whose period ended on or before this month's last day counts here — including ones left over from earlier months.
Cost changes resolved	The dates of the original stock the change re-costs, not the date the change itself was raised. A landed-cost bill entered in August is June's business if the stock it re-prices was received in June.
Inventory debt settled	The moment the debt was incurred — the shipment that went out with no costed stock behind it. The check counts everything still outstanding as at the month end, so debt carried in from an earlier month is counted here too, not only debt this month created.
Inventory reconciled to GL	The most recent reconciliation point dated on or before the month's last day.
Provider documents reconciled, Trial balance reconciled to provider	Your side, the Effective date window. Your provider's side, the same calendar dates read in the provider's own timezone — which is where the mismatch below comes from.
Provider lock aligned	The lock date your provider reports, compared with the month's last day.
Ledger generation — individual entries, Amazon settlements mapped	No date at all. Both are whole-business checks, and their own descriptions say so — generation work "cannot be scoped to one month". A backlog anywhere holds up every month's close, not only the month it belongs to.

Three of those are worth reading twice, because they are the ones that surprise people: batches go by the batch's period end, cost changes by the stock's dates, and inventory debt is cumulative rather than month-by-month.

A sale on the last evening of the month

An order fulfilled at 11 PM on June 30 belongs to June, because 11 PM on June 30 is still June 30 where your business is. Its entries count towards June's checks, appear in June's Income Statement, Balance Sheet and Trial Balance, and are frozen with June's numbers when you close it.

An entry stamped ten minutes after midnight on July 1 belongs to July, for the same reason, even though the sale it came from feels like part of the same evening's trading.

This holds all the way through the close, not only in the reports:

• The checks use the same boundary. A check that counts entries in the month counts that 11 PM entry, and stops before the first instant of the next month.
• Inventory debt follows it too. Stock that shipped on the final evening without costed stock behind it counts as debt incurred that day, so it is already inside the month when Inventory debt settled runs — it does not slide into the next month to become someone else's problem. (That check also picks up older debt still outstanding; see the map above.) See close over inventory debt.
• The report pack agrees with the checklist. Both read the same month window, so a figure you can see in a check's detail is a figure you can find in the reports.

You don't need to juggle a cut-off. There's no "post everything before 5 PM on the last day" rule to enforce, no manual cut-off time to set, and no reason to hold the last evening's fulfillments back. The boundary already follows your own calendar day. Work through the month end at whatever hour suits you.

Once the month is closed, that evening is locked with it

Closing the month locks the books through its last day: new entries can no longer post on or before that date. The 11 PM entry from the last evening is inside the lock, along with everything else in the month.

If the underlying document changes afterwards — an order is edited, a return comes back — the correction is not written back into the closed month. It posts on the first open day after the lock instead, and the entry says so, with an alert reading Displaced from a locked period naming both the date it posted on and the earlier date its source document carries. Your closed month keeps the numbers you signed off, and the correction lands in the month that is still open. See what closing does to your books.

The month that contains a clock change

Twice a year a month contains a day that isn't 24 hours long. Nothing about the close changes for it.

The month's boundary is midnight-to-midnight in your business timezone, and midnight is still midnight on a day the clocks move. A month that ends on a spring-forward day is an hour short and a month that ends on a fall-back day is an hour long; both still begin at the first instant of their first day and end at the last instant of their last day, and every check and every report in the pack uses that same window. There is no hour that falls between two months, and no hour counted twice.

The same holds for the lock a close leaves behind. The first open day is the calendar day after the lock date, starting at that day's local midnight — whatever the clocks did overnight.

What you don't have to do: nothing. There's no setting for it, no adjustment to make, and no reason to avoid closing a month with a clock change in it.

Timestamps that arrive from a marketplace

Orders and settlements that come in from a sales channel arrive stamped in the channel's own terms, and most channels stamp in UTC. SKU.io keeps the exact instant and converts it to your business timezone before deciding which day — and therefore which month — it lands in. You never have to do that arithmetic yourself, and the date you see on the entry is already the converted one.

The practical consequence is that a marketplace event can read as a different day at the marketplace than it does in SKU.io, and SKU.io's version is the one your books use. A channel event stamped 03:30 UTC on July 1 is 11:30 PM on June 30 for a business set to New York, so it is June's — even though the marketplace's own report files it under July 1. That's not a discrepancy to fix; it's the same instant described from two places.

Where it does matter is when you're checking SKU.io's figures against a marketplace report at month end. Reconcile on the marketplace's own totals for its own window and they won't tie out to the day, because the two are cut in different timezones. Compare whole months, expect the edges to move, and treat the entry's Effective date as the answer for anything that has to agree with your books.

When your provider's timezone isn't yours

Your accounting provider keeps a timezone of its own, on its own organisation or company settings, and SKU.io has no say in it. That is fine until the two disagree — and if they do, it is a permanent, every-month source of variance rather than a one-off.

Here is how it plays out. When the close reconciles against your provider, SKU.io selects its own entries by your business timezone, then asks the provider for the same calendar month by date, which the provider reads in its timezone. A transaction near midnight can therefore be a June 30 entry in SKU.io and a July 1 document at the provider. Nothing is wrong with either record; they simply drew the boundary in different places.

Two checks report it, and both are warnings rather than blockers:

• Provider documents reconciled turns up an unmatched document on one side and a matching orphan on the other.
• Trial balance reconciled to provider shows an account out by exactly the value of the transactions that crossed the boundary.

The tell is the pattern rather than the amount. A boundary mismatch appears at the very start or the very end of the month, is made of a small number of transactions timed close to midnight, and reverses itself the following month — the June shortfall shows up as a July surplus. A genuine difference does none of those things. When you see that shape, check the timezone on your provider's organisation settings against Settings → General → Date & Time → Timezone before going looking for a missing document.

The fix is to make them the same, and to do it before your first close if you can — the same advice as the caution below, for the same reason. See how SKU.io reconciles with Xero and QuickBooks for what those two checks compare, and fix a failing check for working one of them down.

Changing your business timezone part-way through the year

Month boundaries are worked out from the timezone in force when the figures are produced, not the one in force when each transaction happened. There is no per-entry memory of the old timezone.

So if you change Timezone in Settings → General → Date & Time mid-year, the effect is not cosmetic:

• A handful of edge-of-midnight entries change month. Move the business a few hours east or west and entries that were the last thing in June become the first thing in July, or the other way round. Only entries close to midnight are affected — everything in the body of the month stays where it was.
• Closed months keep the figures they were closed with. Closing snapshots the report pack as the month's numbers of record, and those snapshots don't move when the timezone does. A closed month's reports keep saying what they said at close.
• Verify can then report drift. Running Verify on a closed month recomputes each report live and compares it with the close snapshot, under the columns At close and Live now. Because the live recomputation uses the new timezone and the snapshot used the old one, an authoritative report can come back drifted even though nobody touched a transaction. Reconciliation reports come back changed (informational) and don't count as drift. See verify a closed month and frozen figures and drift.

caution

Set your business timezone once, during setup, and before your first close. Changing it later is legitimate when the business genuinely moves, but expect to explain the drift it puts on already-closed months — record the change in the close notes or the reopen reason so the audit trail says why the numbers shifted.

Next steps

• Which months you can close, and in what order — where the month list starts and ends.
• Close a month — run the close on the month whose turn it is.
• Verify a closed month — prove a closed month's numbers still match what you signed off.
• How SKU.io reconciles with Xero and QuickBooks — what the two provider checks compare, and what a real variance looks like.
• Review the ledger — find an individual entry and the date it posted on.