What closing does to your books

Closing a month is not a label you put on it — it changes how the rest of SKU.io behaves for every date in that month. This page explains the lock closing puts in place, and what happens to any document dated behind it.

The life of a month

On the Close tab a month runs Open → In Review → Closing… → Closed, and either reopening it or a close that doesn't finish sends it back to In Review. The earliest month not yet closed is the one whose turn it is, marked Open — up next in the Periods rail; a closed month carries its lock date beside its dates. For what each status means and which buttons it enables, see Statuses in the close. The rest of this page is about the lock a close leaves behind.

What actually happens when a month closes

Close period does not tick a box and walk away. It runs one all-or-nothing piece of work, and everything in it either lands together or none of it does:

1. Every automated check is run again from scratch, so the close is decided on the state of the books at that moment, not on the counts you were looking at a minute ago.
2. The close rules are re-applied — anything still Blocking and not overridden stops the close here.
3. Any override you were permitted to make is recorded against the month.
4. All nine reports in the Report pack are frozen as saved copies.
5. A lock is added at the last day of the month.
6. Every outstanding item you ticked in the dialog is stamped Acknowledged at close.
7. The month is marked Closed, with who closed it, when, and your Close notes.

If any part of that fails, none of it happens: no lock, no frozen reports, no acknowledgements, and the month goes back to In Review so you can fix what went wrong and try again. A close you cancel from the job tray behaves the same way.

The Report pack is built inside the same step as the lock, on purpose. All nine reports and the lock decision therefore read one consistent view of the books — you can't end up with an Income Statement taken a few seconds before a Balance Sheet.

note

Because the checks are re-run at this point, a close can still be refused after you confirm the dialog — someone else may have changed something while you were reading it. See Fix a failing check.

The books lock at the month end

Closing June adds a lock dated Jun 30, 2026 — the last day of the month. The lock date itself is closed, so the first open day is the day after it.

That is not the only lock that can be in force. Go to Accounting → Settings → General and you'll find them gathered together:

Where it comes from	What it is
Accounting Lock Date	A date you set by hand. The field's own description says it locks transactions dated on or before this date — the lock date itself is closed, so the first open day is the day after.
Provider lock dates	The lock your accounting provider reports, imported for each connection and listed with its date. Each one has an Enforce locally switch.
A month's close	The lock a close writes at the month end.

Only one date is actually enforced: the Effective lock date shown on that same screen, described there as the later of your lock date and enforced provider lock dates. Every lock in force is folded into it, and the latest one wins.

Three consequences worth knowing:

• The lock is a single high-water mark, not one gate per month. If you could close August while June was still open, the effective lock would jump to Aug 31 and quietly lock June and July too. That is exactly why SKU.io makes you close months oldest first, and why only the most recently closed month can be reopened. See Which months you can close, and in what order.
• Reopening a month doesn't always unlock it. The close's own lock goes away, but a provider lock or a hand-set Accounting Lock Date can still cover the month. The reopen tells you when that happens, naming each one — a hand-set lock that isn't tied to any connection is listed as Internal lock (unassigned). See Reopen a closed month.
• Closed and locked are two different things, and they can come apart. A month you close and leave alone is both: the close writes the lock at the month end. But the lock is that one effective date, and it stays editable afterwards — clear Accounting Lock Date, or move it back behind the month end, and the lock the close wrote goes with it. The month still reads Closed on the Close tab, with its sign-off, acknowledgements and frozen report pack intact, but its dates accept postings again. That is what closed but not locked means wherever you meet it in SKU.io — on Inventory → Cost Changes, for instance. Effective lock date on the settings screen tells you which of the two you have: None, or a date earlier than the month end, means closed but not locked.

warning

The lock protects everything that posts through SKU.io. It cannot protect against a repair applied to your data outside the app entirely — a support engineer fixing something at your request, for example. That is precisely what Verify exists to catch afterwards; see Frozen figures, staleness and drift.

What happens when something dated in a closed month changes

Work doesn't stop because a month is closed. A supplier bill for June arrives in July; a June order gets edited. SKU.io still has to record it — the question is where.

The default: booked forward, and flagged

Out of the box, an entry that would land on or before the lock date is booked on the first open day instead, and its intended date is kept on the record. You see this in three places:

• In Accounting → Transactions, the Date column shows the day the entry actually posted on, with its original, locked date struck through underneath. An amber calendar-lock icon appears in that row's Sync column; hover it for Displaced from locked period — original date Jun 12, 2026.
• On the entry itself, an information panel headed Displaced from a locked period spells out both dates — This entry was posted on … Its source document is dated …, which falls in a locked accounting period — and offers a Lock settings button that takes you straight to the lock.
• Across the whole ledger, the Lock date exceptions card on the Accounting Dashboard carries the running count, with N entries displaced · amount net beneath it. The card is hidden entirely when there are none. Clicking it opens the Lock exceptions report, whose Displaced entries summary repeats the count and breaks it down by source type; the Exceptions table below lists Original date, Posted date, Days displaced, Type, Reference, Amount and Sync status.

To pull the same list out of Transactions yourself, open Advanced Filters and add the Displaced from locked period condition, which sits under Dates alongside Date, Posted At and Created At.

Two things to be clear about while you're looking at that screen:

• An entry dated inside the lock carries no marker of its own. There is no Locked badge on the rows the lock covers. Displacement is the only thing flagged, because displacement is the only thing that happened to an entry — one that was already sitting in the month before you closed it was never touched, and looks it. To see what a lock covers, read the month's dates on the Close tab, not the ledger rows.
• Synced, Locked in the Sync column has nothing to do with your lock date. It means your accounting provider has settled that document — paid or fully credited — and won't accept edits to it. The similar wording is a coincidence.

The alternative: refuse it outright

Under Accounting → Settings → General → Locked-period events you choose between two behaviours:

• Post on first open day, flagged — the default described above. On screen: Late events are booked on the first open day, keep their original date, and are flagged.
• Block until resolved — Postings dated in a locked period fail until the lock is moved or the policy changed.

With Block until resolved on, nothing is quietly moved. A document dated in the locked month is refused with a message naming both dates — Journal entry dated 2025-07-09 falls within a locked period (locked through 2026-06-29) — and if you generate entries by hand you get told how many were turned away: N documents could not be generated — each is dated in a locked period. Unlock the period or change their dates, then try again. Refusals of this kind are grouped under the Locked period cause when you review sync failures, so they never get mistaken for a genuine fault.

Editing a document that already posted

Posted entries are never rewritten. Editing a document whose entry is already on the books produces two new entries — a reversal that cancels the original out, and a replacement carrying the new figures. When the original sits in a closed month, both of them are booked on the first open day and flagged as displaced, so the closed month's totals do not move at all. The old entry is marked as superseded and no longer affects your books.

The one thing that stays put

If your accounting provider already holds that document, at that exact date, the entry is left where it is rather than being moved forward. The provider's own books already contain it there — moving SKU.io's copy is what would create a mismatch between the two, which the reconciliation reports would then report as a real difference. See How SKU.io reconciles with Xero and QuickBooks.

Things a person does are refused, not moved

Booking forward is for postings SKU.io generates on its own. When you are the one choosing the date, SKU.io refuses instead of quietly picking a different day — whichever Locked-period events setting you have:

• Re-dating a stock take into a locked period is turned down.
• A cost reallocation that would change cost of goods sold inside a locked period is turned down.
• An inventory revaluation's Effective Date field won't let you pick a locked day at all: the earliest selectable day is the day after the lock, and the field's hint says Books are locked through …; a revaluation dated in a locked period posts to the first open period.

Moving the lock date moves the entries with it

Displacement isn't permanent. Whenever the effective lock changes — you edit the Accounting Lock Date, apply a provider's date with Apply as lock date, or turn Enforce locally on or off — every previously displaced entry is re-evaluated against the lock that is now in force:

• If the lock moved back (or you cleared it), an entry whose intended date is open again returns to that date and stops being flagged as displaced.
• If the lock moved forward past the day an entry was displaced onto, it moves again, to the new first open day, and stays flagged.

The result is that your ledger always reads as though the current lock date had been the only lock date that ever mattered.

That re-evaluation runs in the background, and it announces itself nowhere: no notification, no entry in the job tray. Read the ledger instead. The Lock date exceptions card on the Accounting Dashboard is the quickest check — it counts only the entries that are displaced now, so an entry the new lock lets back onto its intended date drops off the card, out of the Lock exceptions report and out of the Displaced from locked period filter, and loses the struck-through date in Transactions. When the count reaches zero the card disappears altogether. Give it a moment after saving the lock: the pass runs a beat behind the setting.

Cost changes dated inside a closed month

Cost changes get their own treatment, because restating one deliberately rewrites earlier months. On Inventory → Cost Changes, a change is chipped by what it would touch:

• Closed — The original month has been closed off in your accounting periods. Restating changes numbers that may already have been reported. This is information, not a refusal in itself: unless the month is Locked as well, Restate is still available, and it will restate that month.
• Locked — The original month is locked to further postings, so restating would post on the first open day instead. Here Restate is switched off. The review panel explains why: Its original months are locked — restate would post on the first open day instead. Apply it going forward.

The two chips answer different questions — Closed is the month's status on the Close tab, Locked is whether the effective lock date still covers it — and a month you closed and left alone carries both. A change chipped Closed without Locked reaches into a month whose lock has since been cleared or moved back, which is why restating it is offered rather than refused. See The books lock at the month end.

Filter for either with the Locked period and Closed period options.

If you apply a change Going forward instead, the day you pick has to satisfy three rules, and the date field enforces all of them:

• It cannot be on or before the lock date — The books are locked through … Choose a day after the lock, or restate. The earliest day the picker offers is the first open day after the lock.
• It cannot precede the stock it re-costs — Going forward cannot be dated before the stock was received. The latest original receipt in this change is …
• It cannot be in the future — Going forward cannot be dated in the future.

Choosing a day inside a month that is closed but not locked is allowed — the lock is what the picker enforces, and that month no longer has one — but you are warned before you commit: That month is closed. Posting there changes numbers that were already reported. More on the inventory side of this in Inventory and the close.

Remapping an Amazon FNSKU can restate a closed month

Re-pointing an FNSKU at a different product re-attributes its history, which can reach back into months you have already signed off. The remap dialog tells you before you commit, in the Accounting row of the preview:

• Closed months are listed as May 2026 closed — will be restated, one chip per month, and repeated in the warnings as 2 closed periods (May 2026, Jun 2026) will be restated. This is a warning, not a refusal — you can go ahead.
• Locked months are reported separately, and they do stop you. The chip reads May 2026 locked · 3 ledgers, and the dialog is headed Blocked, with the fix spelled out: N ledgers fall in a locked period (May 2026). Unlock the period or choose a date after …
• When neither applies you get No closed or locked periods, or No locked periods when only closed ones are affected.

Next steps

• Close a month — walk a month from Open to Closed.
• Frozen figures, staleness and drift — what closing freezes, and why a closed month can still move.
• Reopen a closed month — remove the lock and record why.
• Which months you can close, and in what order — why closes run oldest first.
• Review the ledger — find the entries the lock moved.