Inventory and the close
Three rows in the Sync & reconciliation group of the Close checklist are really the same question asked three ways: is this month's cost of sale final? This page explains what each one is measuring, why two of them let you close anyway, and what you are signing when you do.
The three rows are Inventory debt settled, Inventory reconciled to GL and Cost changes resolved. None of them is about how much stock you have. All three are about whether the money behind that stock has settled.
Inventory debt: stock that shipped with nothing costed behind it
Sometimes goods physically leave before SKU.io has any costed stock to take them from — a sales channel reports an order as fulfilled from units the ledger has not received yet, or someone ships short on purpose because the customer's parcel matters more than the paperwork. SKU.io records the shipment either way and books what it owes as inventory debt.
Because there is no real cost to take, the cost of that sale is posted at an estimate, and the estimate is parked in the Inventory Debt Clearing account. It sits there until a receipt actually arrives and settles the claim, at which point the estimate is replaced by the real cost and the difference posts as a dated variance.
That is the whole reason this row is on the close checklist. A month with outstanding debt is a month whose cost of sale is still provisional — right as far as it goes, but with a correction that will land in some later month, once the receipt turns up. Closing over it signs off a gross margin that is going to move.
The figure the row quotes is money, not units
A failing row reads like this:
Inventory debt settled — Blocking — 3 still owed · 409.75 in clearing
The count is claims; the amount is what is still sitting in clearing — what was posted, less what has already been relieved by settlements. That second number is the one that matters at sign-off, because it is the number that has to agree with the Inventory Debt Clearing line on the Balance Sheet you are about to freeze. Units and estimates drift apart from it as soon as a claim settles in slices, so the row deliberately quotes the money.
Debt never blocks a shipment — it blocks the close instead
This is a design decision worth understanding, because it explains why the pressure lands on you at month end rather than on the warehouse during the month.
The point of inventory debt is that a real customer's goods go out even when the ledger is behind reality. Refusing the shipment is not an option for an order a sales channel has already fulfilled — those goods have left. So the consequence has to surface somewhere else, and the close is the right place: it happens on a schedule, it is owned by finance rather than by the floor, and it is where a provisional number finally costs something.
Which is to say: a debt row failing at month end is not a warehouse mistake that got through. It is the mechanism working as intended, arriving on your desk at the moment it is supposed to.
Which claims count towards this month
Claims are selected by when the debt was incurred — the day the goods went out — and measured against your month's last day in your business timezone, the same boundary every other check uses. Stock that shipped at 11 PM on the final evening of the month is this month's debt, not next month's. See month boundaries and timezones.
Claims incurred after the month end do not count against it, even while they are outstanding. A month can therefore pass this check while your debt report still shows plenty owed.
What clears it, and what only looks like it does
There are two honest ways out, and both of them end with a real receipt. Either the stock the claims are waiting for arrives and settles them, or you count in stock that was on the shelf all along and let that count settle them. In both cases the estimate is replaced by a real cost and the difference posts as a dated variance — which is the whole transaction the row is waiting for.
Nothing else clears it. Acknowledging the row, closing over it, or watching the claim age past thirty days changes what you have signed for, not what is owed. The claims themselves live on the Fulfillment Debt Report, which the row's arrow opens scoped to the month; close over outstanding inventory debt walks that list step by step.
Whether it blocks you is your business's decision, not SKU.io's
Inventory debt settled is the only check whose severity you get to choose, and the choice says how much provisional cost of sale you will let past without a signature. As it ships, the row carries the Blocking chip: the close is refused until the debt settles or somebody holding the override permission closes over it with a recorded reason. Turned the other way, the same row becomes an ordinary warning — it still states the exposure, and you still tick it, but nobody has to say why the month can carry it.
That is the trade the setting is really making. An acknowledgement records that you saw the number; an override records why you accepted it. The setting itself is described once, in close settings and custom checklist items; the override is in close over outstanding inventory debt.
It is also the only blocking check there is any way past. Four checks can block a close, and the other three — All entries balanced, Ledger generation — individual entries and Opening balance applied — refuse it outright, at every permission level, with no override and no acknowledgement. See what stops a close, and what only needs a tick.
Inventory value versus the GL control accounts
Inventory reconciled to GL asks a different question: does SKU.io's own inventory value agree with what your accounting provider's inventory control accounts say it is?
A failing row reads:
Inventory reconciled to GL — 842.10 divergence (limit 1.00)
What is actually compared
You earmark which of your provider's accounts are inventory control accounts, and SKU.io keeps a day-by-day comparison for each of them. At close it takes, for every earmarked account, the most recent reconciliation point dated on or before the month end — not today's position, and not an average — and adds up the gaps.
Two details in that sentence carry weight:
- The gaps are added ignoring their direction. An account overstated by 500 and another understated by 500 total 1,000, not zero. Two errors that happen to point opposite ways are still two errors, and letting them cancel would hand you a clean row over a broken sub-ledger.
- The comparison is dated on or before the month end. A point captured after the month closed does not answer for the month, so the row uses the last one that does.
The limit starts at 1.00, which is a rounding allowance rather than real slack. It is configurable, but not from a settings screen — close settings and custom checklist items says how to have it changed.
No measurement is not the same as agreement
This check refuses to pass on missing evidence, which produces three outcomes that are easy to confuse:
| What is true | What the row does |
|---|---|
| No accounts earmarked at all | Stands aside — No inventory reconciliation accounts earmarked. Nothing has been claimed, so nothing is owed. |
| Accounts earmarked, nothing ever compared | Warns — never compared — no reconciliation points captured |
| Accounts earmarked, some compared and some not | Warns, and the row names them — for example 2 accounts unassessed alongside any divergence |
The middle and bottom rows are the point. Once you have told SKU.io that these accounts hold your inventory, "we never looked" is a finding, not a pass. A single earmarked account with no measurement at month end warns the whole row even when every other account agrees to the cent.
The close will not go and fetch the numbers for you
Reconciliation points are produced by the reconciliation feature, not by the close. Running Re-check re-reads whatever has been captured; it never reaches out to your provider to pull fresh balances. That is deliberate — a close should not silently spend your provider's request budget — but it does mean a stale row stays stale until you refresh it yourself.
Refreshing is a reconciliation job, not a close one, and it lives on the ledger's Reconciliation tab under Inventory, behind Configure & sync. Two sides have to be brought up to date and they do not cost the same: recomputing SKU.io's own inventory value runs in the background and spends nothing, while pulling the provider's GL is the metered step that uses your provider's request budget for the day. That asymmetry is why the close leaves both to you. See fix a failing check for the sequence.
What it means for sign-off
This row is always a warning, never a blocker, and that is the right severity: a divergence between a sub-ledger and a control account is a reconciling item, not a broken book. But acknowledging it puts a number on what you are accepting. If the row says 842.10 divergence (limit 1.00), the Balance Sheet you are freezing carries an inventory figure that your provider disagrees with by roughly that much, and the frozen checklist will say so — the item is stamped Acknowledged at close for good.
Cost changes still awaiting a decision
Cost changes resolved covers the third way a month's cost can be unfinished: a cost that arrived after the stock it applies to, and that nobody has decided what to do with yet.
A freight bill for last month's container, an invoice that corrects what you expected to pay, a purchase price edited after receipt — each of these creates a retroactive cost change, and each can be applied in one of two ways. Restate pushes the new cost back into the periods the stock was received and sold in. Going forward leaves history alone and applies the change from here on.
While a change waits for that decision, the entries for the document that triggered it are held back. So the month is not merely unreconciled — part of its cost has not been written down at all yet, and the decision, once someone makes it, can land on either side of your close.
A failing row reads:
Cost changes resolved — 2 awaiting a decision · 1,240.00 impact
The count is undecided changes; the amount is their total effect on cost.
Matched on when the goods arrived, not when the paperwork did
A change is matched to your month by the original stock dates it affects — the days the goods were received — not by the date of the invoice or the date the entries would carry. That is the only match that answers the question you are asking at close: is the cost of the stock that moved in June still open to change? An invoice dated in September for a June receipt is a June problem, and this row treats it as one.
It warns rather than blocks, on purpose
Closing the month first and applying the change going forward afterward is a perfectly respectable accounting stance — often the right one, once a period has been reported. Blocking the close would take that choice away from you and hand it to whoever happens to be processing invoices. So the row states the exposure and lets you acknowledge it.
What acknowledging means here is specific: you are saying you know a cost is still undecided, and you accept that if it is later resolved as a restatement, it will reach back into a month you have closed. See what closing does to your books for what happens to a closed month when a change does reach back into it.
Only a decision clears it
The row's arrow opens Inventory → Cost Changes scoped to the month, on the Needs review tab, where each change shows what triggered it, what it is worth, and whether it touches a month that is already closed. What the row is waiting for is not work but a judgement: Restate, and the cost goes back into the months the stock was received and sold in; Going forward, and history is left alone. Either answer ends the uncertainty and releases the held entries. No answer leaves the cost unwritten, which is the one state the close cannot report on. See fix a failing check for the steps.
Reading the three together
At sign-off it helps to know which kind of "not final" each row is describing, because they need different judgements:
| Row | What is unfinished | The judgement |
|---|---|---|
| Inventory debt settled | Cost of sale posted at an estimate, correction landing in a later month | How much provisional margin you are willing to sign for |
| Inventory reconciled to GL | Your inventory value and your provider's disagree, or were never compared | Whether the gap is a known reconciling item or an unexplained one |
| Cost changes resolved | Cost not yet written down at all, and the decision could reach back | Whether you would rather decide now or apply it going forward |
None of them means the books are wrong. All three mean the books are provisional, which is exactly the sort of thing a close exists to make somebody sign for. For the line between the two, see what stops a close, and what only needs a tick.