What stops a close, and what only needs a tick
Not every unhappy row on the Close checklist carries the same weight. Some refuse the close until you fix the data; the rest let you close the month as long as you say, on the record, that you know about them. This page explains which is which, and the rules the close itself enforces.
Blocking checks and warnings
A check that fails is either blocking or a warning, and the checklist tells you which by whether the row carries a Blocking chip next to its title.
Blocking. The close is refused while the check fails. There is no tick box and no way to accept it — you go and fix the data, then re-check. The chip's own tooltip puts it plainly: "This check must pass before the period can be closed — while it fails, the close is refused." The month header also shows a red count of them, for example 3 blocking, and Close period stays disabled with the tooltip 3 blocking failures must be resolved before this period can close.
Warning. No chip. The row still shows what is wrong — 4 still in flight, 842.10 divergence (limit 1.00), 2 of 9 accounts out · 1,301.15 total variance — and the month can still close, but only after you acknowledge that item in the close dialog.
Ticking an acknowledgement changes nothing about the underlying data. It records that you closed the month knowing that item was outstanding, and the item is stamped Acknowledged at close on the frozen checklist forever after. The figures stay as they were, the divergence stays divergent, and the entries that had not reached your provider still have not reached it.
Severity is fixed per check and is not something you configure — with one exception. Inventory debt settled follows the Block period close while debt is outstanding setting under Settings → Inventory → Inventory Debt, so the same row is a blocker for one business and a warning for another.
A blocking check that does not apply to the month shows no Blocking chip at all. It is greyed out with its reason underneath, and in that month it blocks nothing — see Why some checks say the check does not apply below.
Which checks can block at all
The set is smaller than the list of failures suggests. Only four of the fourteen automated checks can ever refuse a close: Ledger generation — individual entries, All entries balanced, Opening balance applied — and that one only on the first month you close — plus Inventory debt settled, which blocks or warns depending on the setting above. Every other automated check is a warning.
Of those four, exactly one can be closed over: Inventory debt settled, and only with the override permission and a written reason. The other three cannot be closed over by anyone, at any permission level — see the failures no permission can wave through.
The three review items — Review Income Statement, Review Balance Sheet and Review Inventory Valuation & COGS — and any items in your Custom group are ticked by hand. Left unticked, each behaves like a warning: the close dialog lists it as Review Income Statement — not checked off and asks you to acknowledge it.
If a check cannot finish for some reason, SKU.io reports it as a failure at that check's own level — a blocking check that could not run refuses the close, and a warning-level one asks for an acknowledgement. A check never passes because it failed to run.
For the severity of each row one by one, and what each check actually looks at, see the close checks.
What has to be true before a month will close
Two conditions, both enforced.
No blocking check may be failing. If one is, the close is refused and names the culprits: Blocking checks failing: All entries balanced, Ledger generation — individual entries. The single exception is a failure that can be closed over with a recorded reason, which today means outstanding inventory debt, and only for someone holding the right permission — see the failures no permission can wave through.
Every warning and every unticked manual item must be acknowledged. The close dialog opens with Acknowledge each outstanding item to close the period with it unresolved: and one tick box per item. Miss one, and Close June 2026 stays disabled with Tick every acknowledgement above to confirm you're closing with these items outstanding. If the close is attempted anyway, it comes back with These items need acknowledgement before closing: followed by the titles.
Both conditions are tested twice: once when you press the close button, and again inside the close as it runs, against results evaluated at that moment. The second test is what makes a stale screen harmless — and what can stop a close that looked fine seconds earlier.
Acknowledgements are matched item by item, which has two consequences worth knowing:
- Acknowledging something that has since started passing is harmless. The acknowledgement is ignored, and the item is recorded as a pass.
- An item that has newly failed since you opened the dialog was never acknowledged, so the close stops and asks for it. Re-check, look at what changed, and close again.
If a close stops at this point, nothing has been locked and nothing has been frozen — the month goes back to In Review and you pick up where you were. See fix a failing check.
The failures no permission can wave through
Four checks can block a close. Three of them cannot be closed over by anyone, at any permission level:
- All entries balanced — an entry whose lines disagree with its own totals.
- Ledger generation — individual entries — entries for the month that have not been generated yet, or failed to generate.
- Opening balance applied — the starting positions your books were meant to begin from, not finalized before the very first close.
The distinction is simple: these mean the books are wrong, and no authority can sign for wrong. Everything else on the acknowledge list means the books are provisional — a figure that is right as far as it goes and may be refined later. Provisional is a judgement call, so it is yours to make and yours to sign.
Outstanding inventory debt is the fourth blocking check, and the one provisional
case severe enough to block by default — so it is the one case that offers a
reasoned override.
When it fails and you hold the accounting.period.override permission, the
close dialog gives you a box — Why is this being closed over? — and the
reason is stored with the month alongside the exposure as it stood. Without the
permission, the dialog says so instead: "This normally blocks the close. You
don't have the accounting.period.override permission, so it has to be
resolved before June 2026 can close — or ask someone who holds it to close the
month." Full walkthrough:
close over outstanding inventory debt.
Why some checks say the check does not apply
A greyed-out row means "this does not apply to your setup or to this month" — it never means "the check could not tell". The reason is printed under the title on the row itself, not hidden in a tooltip, so you can read down the list and see why each one stood aside.
The reasons are all absences, never uncertainty: no accounting connection, no Amazon integration, no inventory accounts earmarked for reconciliation, no provider trial balance captured for the month, or an opening balance that either does not exist or belongs to an earlier month. Each row words its own reason; the close checks quotes what every row says under Stands aside when.
Skipped rows count toward the group count and the progress ring as done, and they never need acknowledging. That is the point: a check that cannot say anything about your month should not stand between you and the close.
One case deliberately breaks the pattern. If you have earmarked inventory accounts but nothing has ever been compared for the month, Inventory reconciled to GL warns rather than skipping, and the row reads never compared — no reconciliation points captured. There is a question to answer here and no evidence either way, so the close asks you to acknowledge it rather than passing it off as inapplicable.