What stops a close, and what only needs a tick
Not every failing row on the Close checklist carries the same weight. Some refuse the close until you fix the data. Some block, but let someone with the right permission go over them with a written reason. The rest are warnings: the month can close once you say, on the record, that you know about them. This page explains which is which, and the rules a close and a re-sign-off enforce.
A close never freezes anything, whatever you go over. Closing signs the month off; only your hard close date freezes it.
Blocking checks and warnings
A failing check is either blocking or a warning. The checklist shows which with a Blocking chip next to the title: red while the check fails, grey while it passes. Hover the chip and it tells you which kind of blocking check it is:
- Can't be gone over: "This check must pass before the period can be closed — while it fails, the close is refused."
- Can be gone over: "This check blocks the close, but it can be closed over: you will be asked for a reason, and it is recorded against the period along with the exposure at the time."
A row with no chip is a warning. It still shows what's wrong, for example 4 still in flight, and the month can still close, but only after you acknowledge that item in the close dialog.
The drawer counts every failing blocking check in a red chip beside the month's state, for example 3 blocking, and lists them in a Blocking checks card above the checklist. Close period stays greyed out only while a failure that can't be gone over remains, and its tooltip counts just those, for example 1 blocking failure must be resolved before this period can close. A failure you can go over doesn't disable the button, because the close dialog is where you give the reason.
A blocking check that doesn't apply to the month shows no chip. It's greyed out with its reason underneath, and it blocks nothing that month. See why some checks say they don't apply.
Ticking an acknowledgement changes nothing about the data. It records that you closed the month knowing the item was outstanding, and the item reads Acknowledged at close on the signed-off checklist. The divergence stays divergent, and entries that hadn't reached your provider still haven't.
Which checks block
Most checks are warnings. These are the ones that can block:
| Check | Blocks | Can be gone over with a reason? |
|---|---|---|
| All entries balanced | Always | No |
| Opening balance applied | On the first month you close only | No |
| Payout-channel order AR cleared | Always | No |
| Marketplace facilitator tax | When Block the close when marketplace facilitator tax doesn't tie out is on | No |
| Ledger generation — individual entries | Always | Yes |
| A/R and A/P match open documents | Always | Yes |
| Inventory debt settled | When Block period close while debt is outstanding is on (the default) | Yes |
| Inventory reconciled to GL | When Inventory and trial-balance breaks block the close is on | Yes |
| Trial balance reconciled to provider | When Inventory and trial-balance breaks block the close is on | Yes |
Where a setting decides, the check is a warning while the setting is off. Two of the settings are in Accounting → Settings → Close: Block the close when marketplace facilitator tax doesn't tie out, under the check tolerances, and Inventory and trial-balance breaks block the close, under Reconciliation policy. Block period close while debt is outstanding is in the inventory debt settings; see inventory debt settings.
Every other check is a warning, including the two in the Sign-off group:
- Provider lock aligned compares each accounting connection's own lock date with your hard close date. It warns when the provider is behind your hard close date, and when it's later.
- Earlier months re-signed warns while an earlier closed month is waiting for a re-sign-off, and names it, for example March 2026 changed after sign-off and needs a re-sign-off. You can close a later month on top of it once you acknowledge it. See which months you can close.
The three review items and any Custom items are ticked by hand. Left unticked, each behaves like a warning: the close dialog lists it as, for example, Review Income Statement — not ticked on the checklist, and asks you to acknowledge it.
If a check can't finish, SKU.io reports it as a failure at that check's own level. A blocking check that couldn't run blocks, and a warning that couldn't run asks for an acknowledgement. A check never passes because it failed to run.
For every check, what it looks at, and what its row says, see the close checks.
Why some failures can't be gone over
The checks you can't go over mean the books are wrong: an entry whose lines disagree with its own totals, starting balances that were never finalized, revenue counted twice through a payout channel, facilitator tax sitting in the wrong account. No permission can sign for wrong books.
The checks you can go over mean the books are provisional or the evidence is incomplete: entries still queued for generation, inventory debt whose cost of sale is still an estimate, a tie-out that doesn't tie yet. That's a judgment call, so it's yours to make and yours to sign.
Ledger generation — individual entries is in the second group for another reason. Its count isn't limited to the month you're closing, so a queue created by unrelated work can hold a month open with nothing you can do about it from inside the close.
What has to be true before a month closes
Two conditions, both enforced.
No blocking check may be failing, unless it's one you can go over and you give a reason. If a blocking failure remains, the close is refused and names it: Blocking checks failing: All entries balanced, Ledger generation — individual entries.
Every warning and every unticked manual item must be acknowledged. The close dialog lists them under Acknowledge each outstanding item to close the period with it unresolved:, with one tick box each. A warning carries an amber icon; a manual item reads — not ticked on the checklist. Miss one, and the confirm button stays disabled, with the tooltip Tick every acknowledgement above to confirm you're going ahead 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: when you confirm the dialog, and again inside the close as it runs, against results evaluated at that moment. The second test is what makes a stale screen harmless. It can also stop a close that looked fine seconds earlier.
Acknowledgements are matched item by item:
- Acknowledging something that has since started passing is harmless. The item is recorded as a pass.
- An item that newly failed after you opened the dialog was never acknowledged, so the close stops. The month goes back to In Review and the job tray names the item. Re-check, look at what changed, and close again.
A close that stops this way changes nothing: no report pack is saved and the month isn't signed off. See fix a failing check.
Going over a blocking check
When a check you can go over is failing, the close dialog shows it in its own amber panel, separate from the acknowledgements.
- With the Accounting → Period Override permission, the panel reads: "This normally blocks the close. You can go over it, but the reason is recorded against June 2026 along with the exposure as it stands." Type the reason in Why is this being closed over?. Until you do, the confirm button's tooltip reads, for example, Give a reason for going over "Inventory debt settled" — it's recorded against this period.
- Without the permission, the panel reads: "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." The confirm button's tooltip reads, for example, "Inventory debt settled" blocks this, and you don't have permission to go over it.
The reason is stored with the month, alongside the exposure as it stood. A full walkthrough, using inventory debt as the example, is in close over outstanding inventory debt.
When your close settings require an independent reviewer, the override moves out of the close dialog and onto the checklist. Someone other than the person closing clicks Record override on the failing row and gives the reason there, and the person closing accepts it by closing. The confirm button's tooltip until then reads, for example, "Inventory debt settled" blocks this until an override is recorded on the checklist. See review and close a month someone else prepared.
A re-sign-off follows the same rules
A month that changed after it was signed off reads Closed – restated and asks for a Re-sign-off. The re-sign-off runs every check again and holds the month to the same rules as a close:
- A blocking failure that can't be gone over refuses the re-sign-off. The panel reads N blocking failures must be resolved before signing off:.
- A blocking failure you can go over asks for a reason in Why is this being signed off over?.
- Every warning and unticked manual item needs acknowledging again, under Acknowledge each outstanding item to sign off with it unresolved:.
Independent review applies to a re-sign-off too. When your settings require an independent reviewer, the people recorded changing the month since its sign-off can't re-sign it themselves. The refusal reads You changed this month after it was signed off, so someone else has to review the change and re-sign it. If you're the only accounting user, you give a reason for signing off without a second reviewer instead. See re-sign-off a restated month.
Moving the hard close date has its own blockers
The checklist decides whether a month can be closed or re-signed. Moving your hard close date forward has separate rules. The months it would cover should be closed, none of them may be waiting for a re-sign-off, and none may have a report that can't be compared with what was signed. A month that closed with a warning acknowledged can still be hard-locked. See move the hard close date.
Why some checks say they don't apply
A greyed-out row means "this doesn't apply to your setup or to this month". It never means "the check couldn't tell". The reason is printed under the title on the row itself, so you can read down the list and see why each one stood aside.
The reasons are all absences: no accounting connection, no Amazon integration, no sales channel that books its revenue through payouts, no inventory accounts earmarked for reconciliation, or an opening balance that doesn't exist or belongs to an earlier month. The close checks quotes what each row says.
Rows that stand aside count as done in the group count and the progress ring, and they never need acknowledging. A check that can't say anything about your month shouldn't stand between you and the close.
Two cases deliberately break the pattern, because there is a question to answer and no evidence either way:
- If you have earmarked inventory accounts but nothing has been compared for the month, Inventory reconciled to GL warns rather than standing aside.
- If you have an accounting connection but no provider trial balance was captured for the month end, Trial balance reconciled to provider fails rather than standing aside. See capture your provider's trial balance.