Fix a failing check

The Close checklist is a worklist, not a report. Every failing row names a number, and every number has records behind it. This guide is the loop you run until the month is clean: read the row, follow its arrow to the records it counted, fix them, press Re-check, and close.

Before you begin

• Open Accounting → Close and select the month in the period rail on the left. The month must be past Start close — the header reads In Review, not Open. See close a month.
• You need permission to run close actions (Re-check, Export pack) and, separately, permission to close or reopen a period. Without them the buttons are greyed out and the tooltip says which permission is missing. See permissions in the close.
• Know which failures actually stop you. A Blocking chip is red while its check is failing and grey while it is passing, so a red one refuses the close outright; a row with no chip at all is a warning you can close past once you acknowledge it. See blocking checks and warnings.

Run the fix loop

1. Read the failing row. Its one-line summary says what the number means — 6 outstanding — 2 failed, 4 pending, 2 unbalanced, 842.10 divergence (limit 1.00), 3 still owed · 409.75 in clearing. Hover the title for the check's fuller description.
2. Click the arrow at the right of the row. It opens the surface where those records are fixed, with the check's own filters and date range already applied.
3. Fix the records there. A blocking row is worth finishing before you return; a warning row is a judgement call about whether the month can carry it.
4. Go back to Accounting → Close and click Re-check. This re-runs every automated check against the current state of the books.
5. Confirm the row is now green and the progress ring at the top of the header has moved — for example, from 4/19 complete to 5/19 complete, the total being the seventeen built-in rows plus any custom items your business has added.
6. Repeat until no red Blocking chip remains, then click Close period.

What Re-check does, and what it never does

• It re-runs every automated check, not only the one you fixed. A fix in one place often moves a second row.
• It appends any custom checklist items added in Settings since the close was started, so a late addition still appears on the month. See close settings and custom items.
• It never resets an item you already ticked off by hand, and it never removes an item whose custom definition has since been deleted — what you signed for stays signed for.
• It never ticks an automated check off for you. Automated checks only move when the underlying records move. Trying to tick one is refused with Automated checks cannot be checked off — use Re-check to re-evaluate them.
• The button is only offered on a month that has been started and is In Review. On a month you have not started yet, the request comes back Period 2026-06 has not been started — nothing to refresh. On a Closed month it comes back Period 2026-06 is closed — its checklist is read-only., and on one still mid-close, Period 2026-06 is closing — its checklist is read-only.

tip

SKU.io also refreshes automated results on its own when you open an In Review month whose results have gone stale, so a row you fixed a while ago is often already green when you come back. Re-check is how you force it now.

Jump to exactly the records a check counted

The arrow is not a general link to a page — it carries the check's filters and the month's date range with it, so the number on the row and the length of the list you land on agree. Hover it to see which kind of destination it is: Open the fixing surface for records, Open this report for a figure. Each check's entry under fix each check opens by naming exactly where its own arrow lands.

Four things about these destinations are worth knowing before the count and the list ever disagree:

• Reversed entries, deleted entries and entries rolled into a batch are never counted. That is why the number on the row matches the list it opens: both sides exclude the same records.
• The batches arrow opens overdue and in-settle-window batches together. The row's summary splits them (86 overdue, or 12 overdue · 3 still in settle window), but the split is not something the list can filter on, so you land on both sets. Only the overdue ones make the row fail. See batches and the close.
• Two rows open a report instead of a list. Their number describes a figure — accounts out of balance, unsettled categories — so the arrow takes you to the figure rather than leaving you to find it.
• A row with nothing to open shows no arrow at all. A check marked Not applicable, a custom item you wrote yourself, and Inventory debt settled once nothing is owed all have nowhere to send you. Most other checks keep their arrow even after they pass — following one lands you on the empty list that proves it, which is the point.

note

Ledger generation — individual entries is the one row whose number is not scoped to the month. Generation work is queued against source documents rather than dates, so the check counts everything outstanding across your whole account. Its description says so on the row.

Fix each check

The arrow tells you where to go. This is what to do once you are there, row by row, in checklist order. Each entry names what you land on, what usually put the number there, and the control that clears it. For what a row measures and exactly which filters its arrow carries, see the close checks.

Ledger generation — individual entries

You land on Accounting → Outbox, on the Ledger Outbox list with its Backlog chip already applied — the pending, in-flight and failed rows the number counted. Read two columns: Status and Error.

• Pending and Processing rows are work in flight. Nothing to do but wait and press Re-check — the count drains on its own, usually within minutes.
• Failed rows need you. The Error column names the cause and the Source column names the document behind it. Correct that document, then select the failed rows and click Retry Failed, which re-queues them for another generation pass and skips anything that is not failed. The confirmation warns you of the catch: a row whose underlying cause is still unresolved fails again.

This number is not scoped to the month, so it can carry work from any period. Clear all of it — the close places a lock, and an entry still queued when the lock lands is sealed out of the month. This is another of the three blocking checks with no way past it: while generation work is outstanding, no permission or acknowledgement will let the month close.

Ledger generation — batches

You land on Accounting → Batches, on the unposted batches whose period ended on or before the month end. Open the one you want by its ID.

An overdue batch carries a red Overdue chip; hover it and it says the batch should have closed and posted by a named date, and that its figures are in the books as a re-derivable draft that has not reached your provider. A batch also carrying a Dirty chip has had members change since its summary entry was built.

Click Rebuild on the batch to regenerate that summary entry now, or leave it for the scheduled close to run. Rebuilding a batch whose entry already posted reverses it and posts a replacement rather than rewriting it, so the correction stays visible.

All entries balanced

You land on Accounting → Transactions → All with the Out of Balance filter and the month's dates applied — exactly the entries counted. An entry lands here when its lines no longer agree with its totals, which nearly always means the document behind it moved after the entry was generated.

Select the rows and click Rebuild to regenerate them from their source documents, or use Rebuild in a single row's menu. Unchanged documents are a no-op, and a posted entry is corrected by reversal and replacement.

This is one of the three blocking checks with no way past it — no setting, permission or acknowledgement lets a close through while an entry in the month is out of balance. See what stops a close. If a rebuild leaves the row unbalanced, stop and contact support with the entry's Reference.

Opening balance applied

You land on Accounting → Reconciliation → Starting Balances. This row only applies to the very first month you ever close, and it fails while your starting figures are still a draft — the row reads not applied — still draft.

Review the lines, then click Apply. Save draft keeps it editable and does not satisfy the check; Apply is what it waits for. If Apply is greyed out, hover it — the tooltip names what is still missing. If no starting figures exist at all, use Set up opening balances to enter them, or Fetch from QuickBooks to pull a snapshot as of a date you choose.

It is the third blocking check with no way past it. On that first month, applying the opening balance is the only way through; on every month after it, the row stands aside as Not applicable and blocks nothing.

Amazon settlements mapped

You land on Accounting → Dashboard. When mappings are holding settlements back, the dashboard carries an Amazon settlement mappings card with an Action needed chip and the counts behind the number: Ungrouped mappings, Missing nominal code and Held-back settlements.

Click Fix mappings on that card — it opens the settlement mappings list filtered to the blocked ones. Assign each mapping to a group and give it a nominal code. The held-back settlements post themselves once the gaps are closed, so come back, press Re-check, and watch the row clear.

Entries synced

You land on Accounting → Transactions → All, filtered to the month's entries still on their way to your provider. These are queued, retrying or mid-sync — work in progress rather than a fault, and it usually clears itself.

Press Re-check after a few minutes. To push instead of wait, select the rows and click Sync now. The Sync status — why isn't everything on the provider? panel at the bottom of the Close tab breaks the same entries down by reason with a View link on each: see why entries haven't synced.

This is a warning, so a month can close over it once you acknowledge the row — worth doing when the only thing left is a queue that will drain overnight.

Needs-attention inbox clear

You land on Accounting → Needs Attention, scoped to the month: Ledger entries that failed to sync, hit a conflict, or need review before they reach your accounting provider. Rows are grouped by cause — Conflict, Needs Attention, Failed — each group headed by its count and a Retry all button.

Click Show full error on a group to read the provider's own message. Fix what it names — in SKU.io or in the provider — then Retry selected for the rows you corrected, or Retry all for the group. A retry reports back how many resolved, and resolved rows stay on screen marked Resolved until you clear them.

A conflict means the entry changed on both sides; decide which version is right before retrying, or the retry re-creates the conflict.

Cost changes resolved

You land on Inventory → Cost Changes on the Needs review tab, scoped to the month. A row appears here when a bill or invoice arrived after the stock it affects was already received, so the cost of that stock moved retroactively and nobody has said where the difference belongs.

Each row takes one of two decisions, from its actions menu:

• Apply as restate — record the change on the original receipt dates. The month's figures move. Not offered where it would land in a month you have already locked.
• Apply going forward — record it as a dated catch-up instead, leaving earlier months alone.

See inventory and the close for which one a month-end wants.

Provider documents reconciled

You land on Accounting → Reconciliation → Periods, which sets your monthly ledger totals against the cached mirror of your provider and flags any period where the document count or the amount differs. The table gives SKU Entries, SKU Debit, SKU Credit, Provider Docs, Provider Total and the two gaps, Count Δ and Amount Δ.

Press Refresh first — a stale mirror is the most common reason this row fails when the books are actually fine. If a real gap remains, move to the Documents sub-tab and use Auto-match on the unlinked documents, then look at what is left on each side. How much variance is allowed before the row fails is a tolerance the close carries; for its default and how it is changed, see close settings and custom checklist items.

Inventory reconciled to GL

You land on Accounting → Reconciliation → Inventory, which tracks day by day where your inventory value and the provider's control accounts diverge. Read the tiles first — Accounts diverging, Open divergence, Divergent months and Data as of — then the per-account table, which splits the gap into Opening gap, Divergence, Awaiting sync and Residual gap.

• Anything under Awaiting sync resolves itself when those entries reach the provider. Work Entries synced instead.
• An account that never tied at the outset says so at the top of the page, which offers you two routes: reconcile each account from its row, or Draw a baseline to measure from a clean date instead.
• For the rest, press Refresh from provider to bring the comparison up to date, then click a point on the chart to see exactly what moved that day.

The (limit 1.00) in the row's summary is the tolerance the check compares against — raising it is a decision about the books, not a way to clear the row. For its default and how it is changed, see close settings and custom checklist items.

Inventory debt settled

You land on Inventory → Fulfillment Debt, with Inventory Debt Claims already showing the month's outstanding claims. Debt is stock that shipped before there was any cost behind it, so the month's cost of sale is an estimate until the claim is repaid.

Select the claims and take one of two actions:

• Settle from Stock — repays them from stock that has since arrived, at its real cost, and posts the difference from the estimate as a dated variance.
• Create Catch-Up Stock Take — for debt no receipt will ever repay. It raises a draft adjustment stock take for the outstanding units; finalize that and the claims repay from it.

Of the four checks that can block a close, this is the only one with a sanctioned way through when neither action applies: see close over outstanding inventory debt. It is also the only one whose severity depends on a setting — with the debt setting turned off it warns instead of blocking, and you acknowledge it like any other warning.

Trial balance reconciled to provider

The arrow opens the Trial Balance Reconciliation report rather than a list, because the number describes a figure. The report leads with Accounts Reconciled, Accounts Out Of Balance and Total Abs Variance, then gives a row per account with its Sku Balance, Provider Balance, Variance and whether it is In Tolerance.

Work the largest Variance first. An account is usually out for one of three reasons: entries that have not reached the provider yet (fix Entries synced), something posted directly in the provider that SKU.io never saw, or a genuine difference that needs a correcting entry.

If the row instead stands aside with No provider trial balance captured for this period, there is nothing to compare against yet — run Capture provider balances in the report pack below the checklist. See capture provider balances.

Transaction categories settled with provider

The arrow opens the Sync Category Reconciliation report. Each category gets a row with Entries, Sku Total, Synced Total, Excluded Total, In Flight Total, Needs Attention Total and Settled.

Nothing is fixed on this report — it tells you which other row to work. Find the categories where Settled reads false, then follow the money:

• an amount in In Flight Total is waiting on the provider — work Entries synced;
• an amount in Needs Attention Total is parked for review — work Needs-attention inbox clear;
• an amount in Excluded Total is settled by design and never counts against the row.

Provider lock aligned

You land on Accounting → Dashboard with the Connections dialog open. Each connection shows its Lock date — your provider's own books-closed date, after which it rejects entries dated on or before it. SKU.io reads that date; it does not set it, so this row cannot be fixed from inside SKU.io.

Move the lock date forward in your accounting provider — the connection carries a link out to it, labelled with the provider's name (Manage in QuickBooks) — then come back, press Refresh on the dashboard and Re-check on the close.

Leave this one until last. Locking the provider before your entries have reached it blocks exactly the entries you are still trying to send.

The review items and your own custom items

The three Review rows and anything under Custom are ticked by hand — there is nothing to re-run. A Review row's arrow opens the report it names so you can read it before you sign for it. See close settings and custom items.

When to stop and ask for help

Contact support, naming the month and the row's title, when:

• the same rows fail with the same error after two rounds of correcting and retrying;
• a Rebuild leaves an entry out of balance;
• a row fails with no summary beside it at all (see when a check can't finish);
• the number on a row and the length of the list it opens disagree.

When the month refuses to close

While any blocking check fails, Close period is greyed out. Hover it and the tooltip counts them: 3 blocking failures must be resolved before this period can close. The header carries the same count as a red 3 blocking chip beside the status.

If you reach the Close June 2026 dialog with blocking failures still present, it leads with a red panel:

3 blocking failures must be resolved before closing: • Ledger generation — individual entries (6) • All entries balanced (2) • Inventory debt settled (3)

The confirm button at the bottom of that dialog stays disabled, and hovering it says Resolve the blocking failures first — a period can't close with blocking checks failing.

This is not only a greyed button. SKU.io re-runs the same gate when the close request arrives and refuses it there too, naming each failing check — so there is no way around the button, and nothing to gain from retrying the request.

The fix is the loop above: open each failing row's records, correct them, come back, press Re-check, then Close period. Four checks can block a close, and exactly one of them — Inventory debt settled — has a sanctioned way through: see close over outstanding inventory debt. The other three have none, at any permission level.

Every message that refuses a close

A refusal arrives one of two ways, and the message tells you which.

Refused on the spot. The Close June 2026 dialog stays open, so you can correct the attempt and try again without re-typing anything:

What you see	What it means
Blocking checks failing: …	A blocking check failed on the final re-run — something changed after your last Re-check. Fix it and close again.
These items need acknowledgement before closing: …	An item became outstanding between opening the dialog and submitting it. Close the dialog and reopen it to pick up the current list.
Periods close in order — close 2026-05 first.	An earlier month is still open. Close that one first.
Another period close is already running — wait for it to finish.	Another month is mid-close. Wait for the job tray to finish, then retry.
Period 2026-06 is already closed.	Somebody else closed it while you had the dialog open. Refresh the page.

The same rules guard Start close: it is disabled while an earlier month is open — Close June 2026 first — periods close oldest-first. — and while another close action is in flight. A month that is already closed or currently closing cannot be started again at all.

Refused after you confirmed it. Confirming the dialog does not freeze the checklist: every check runs once more the moment the close actually starts, so a month that passed when you opened the dialog can still be turned away. Two things cause it:

• A blocking failure that appeared in between — an entry posted into the month, a generation row failed, a new debt claim landed.
• A new warning your acknowledgements do not cover. You ticked the items that were outstanding when the dialog opened; a warning that appeared after that has no tick against it, so the close stops rather than closing over something nobody signed for.

What you see: the month goes to Closing… briefly, then returns to In Review. Nothing is closed, no lock is placed, and no report snapshot is taken. The entry in the job tray, named Close Accounting Period: 2026-06, carries the actual cause:

• Close aborted: Blocking checks failing: All entries balanced.
• Close aborted: These items need acknowledgement before closing: Entries synced.
• Close failed: … for anything else that went wrong mid-close.

Read the tray message first — it names what changed. Then press Re-check, look at what moved on the checklist, and close again. A successful run finishes with June 2026 closed — reports snapshotted and the period is locked.

One close at a time, and nothing reopens beside it

Close period is disabled during Closing… and the tooltip says The close job is already running — track it in the job tray. A second attempt is refused with Another period close is already running — wait for it to finish. A reopen is refused for the same reason while a close runs — A period close is running — wait for it to finish before reopening. — so an earlier month cannot be unlocked underneath a close that is already in flight.

When a check can't finish

Occasionally a check cannot complete — the data it reads is in a state it can't evaluate. SKU.io never lets that pass silently and never lets it take the rest of the checklist down with it:

• The check is recorded as failing at its own level. A blocking check that crashes still blocks the close; a warning check that crashes still has to be acknowledged. It is never treated as passing, and never quietly dropped to a softer severity.
• The reason is recorded against the check as Check crashed: followed by the underlying message — but it is not shown on screen. A crashed check looks like a failing row with nothing to say: its title, its red or amber status icon, the Blocking chip if it carries one, and then no summary and no arrow at the end of the row. The exported pack does not carry the reason either — its checklist block lists only the item, its status, whether it was acknowledged, and who completed it.
• Every other row still evaluates. One broken check costs you that check, not the month's checklist.

A row that fails with no explanation at all is the tell. Press Re-check — a transient cause clears on the next run. If the same row keeps failing silently, contact support with the month and the check's title: the underlying message is recorded in SKU.io's own error reporting even though the screen cannot show it to you.

When something fails to load, or an action is refused

The close hub separates the two, and the difference tells you what to do next.

Something failed to load — the month list, the month's detail, one of the reports, or the Sync status breakdown. You get a red panel in place of the content, carrying the reason, with a Retry link beside it. Click Retry: the load is repeated and nothing has changed underneath you.

An action was refused — a start, a Re-check, a check-off, an export, a close, a reopen. The refusal arrives as a notification carrying the message SKU.io sent back, and the screen you were on stays put. Read the message: it names the reason (Periods close in order — close 2026-05 first., Period 2026-06 is closed — its checklist is read-only.) rather than a generic failure, so it usually tells you the next move directly. When a close is refused, the confirmation dialog stays open so you can adjust and try again.

Verify on a closed month follows the load pattern rather than the refused-action one: a failed comparison replaces the results with a red panel carrying the reason and a Retry button on the end of it. Pressing Retry is always safe — Verify only reads and compares, and changes nothing. See verify a closed month.

Next steps

• Close a month
• Close over outstanding inventory debt
• Blocking checks and warnings
• Close checks reference
• See why entries haven't synced
• Review the ledger