Amend, re-date, reverse & delete a stock take

A stock take doesn't always end when you finalize it. You'll sometimes need to fix a typo in the notes, move a count to the date it actually happened, undo one you posted by mistake, correct the cost that landed on a found-stock layer, or clear old counts out of the list. What you can do — and how much SKU.io has to unwind behind the scenes — depends entirely on the take's status and whether the stock it created has already been sold, transferred, or built into an assembly.

This guide covers every after-the-fact action: editing, re-dating (and the FIFO replay a re-date can trigger), reversing, compensating, cost-correcting, archiving, and deleting.

Which action do I need?

Pick by intent and by the take's status. The heavier actions are gated by what's downstream.

You want to…	Use	Works on	Reversible?
Fix items or the count date before finalizing	Edit (draft/open)	Draft, Open	Yes — edit again
Fix the notes or move a finalized count's date	Edit (closed)	Closed, non-initial	Yes — re-date again
See the COGS impact of a proposed re-date first	Reallocation preview	Closed, non-initial	Read-only — writes nothing
Undo a finalized count that hasn't been consumed	Reverse	Closed (not Amazon)	Returns to Open or Draft
Undo the effect of a finalized count that has been consumed	Compensating adjustment	Closed, consumed	New child take you finalize
Fix the cost on a finalized count's FIFO layers	Cost correction	Closed	Yes — correct again
Hide a take from the working list	Archive	Any status	Yes — Unarchive
Remove a take permanently	Delete	Any status (unless consumed)	No — permanent

If you haven't finalized the count yet, most changes go through plain Edit — see Count stock and Finalize a stock take. This page focuses on what happens after a take is closed.

Before you begin

• Open the take you want to work with from Inventory → Stock Takes, or from its detail page.
• Every action here needs the Count inventory permission (inventory.count).
• The action buttons live in the top-right of the stock take's detail page. Edit, Delete, and Reverse appear only when they apply to the current status (see the table above). Archive, unarchive, and bulk delete also live on the list's bulk-actions bar.
• Know the model first: how a take moves from draft to closed and creates FIFO layers is explained in How stock takes work, and the layers themselves in FIFO layers & how COGS is realized.

There is no "reserved" state

Committed stock shows as Allocated, never "reserved" — SKU.io has no reserved status. When this page talks about stock being consumed, it means a FIFO layer created by the take has been sold, transferred, or assembled and now has a fulfilled_quantity above zero. See Stock states.

Edit a stock take

What Edit lets you change depends on status.

A draft or open take

While a take is Draft or Open, editing is unrestricted: change the count date, add or remove items, and adjust counted quantities. On an open (initiated) full count these edits re-run the in-progress reconciliation math for you. Use the flows in Create a stock take and Count stock.

A closed, non-initial take

Once a take is Closed, its counts are locked — but you can still fix its notes and move its Count Date.

1. Open the closed take and click Edit.
2. In the Edit Stock Take dialog, change the Notes or the Count Date.
3. Click Save Changes.

Two things you can't do on a closed take, both blocked with a clear message:

Attempt	Result
Delete an item	"Cannot delete items from a closed stock take." (CantDeleteStockTakeItemsForClosedStockTakeException)
Change a counted quantity	"Cannot modify counted quantities for a closed stock take." (ClosedStockTakesCantChangeQuantityException)

To change quantities on a finalized count, reverse it (if nothing's been consumed) or post a compensating adjustment.

An initial count's date is pinned

An initial (opening-balance) count is dated to your inventory start date and can't be re-dated. If you send a new date on an initial count, SKU.io discards it — the date never drifts away from the start date, and no FIFO layers move. You can still edit its notes.

Re-dating replays FIFO consumption and COGS

Moving a closed take's Count Date is more than a label change: the count's date drives its FIFO layer date, its inventory movement dates, and the accounting entry date. When you re-date a closed, non-initial take, SKU.io moves the count's own records to the new date:

• Found-stock (positive) adjustments own a creation FIFO layer. The layer and its originating + movement move to the new date together.
• Removal (negative) adjustments consume layers owned by other documents. Their consumption movements move to the new date so a historical "as of" valuation reflects the removal — but the consumed layers themselves aren't re-picked.

That much is automatic. The bigger decision is whether to replay downstream consumption.

Re-dating a found-stock layer can change its position in the FIFO queue — which changes which layer later sales, transfers, and assemblies drew from, and therefore their COGS. SKU.io doesn't silently rewrite that history. Instead, when you re-date a closed take it shows you a COGS Reallocation Impact preview and lets you choose:

• Move date only — move the layer and movement dates, leave every historical consumption exactly as it was costed.
• Apply — dispatch a background job that replays historical consumption against the re-ordered layers and recomputes COGS on every affected sale, then propagates the corrected numbers to documents and accounting.

The replay runs as a tracked job — after you apply, a "COGS reallocation started — track progress in the job tray" message appears and you follow it in the job progress tray.

Why the two-step is a preview, not a warning

The reallocation preview is a full dry run — it computes the exact reassigned usages and net COGS delta before anything is written. Nothing changes until you click Apply, so you can re-date the label without touching cost history whenever that's all you meant to do.

Preview the FIFO reallocation impact

The preview is the confirm step before you opt into a replay. When you re-date a closed non-initial take and save, the COGS Reallocation Impact dialog runs the dry run and reports:

Field	What it tells you
Reassigned usages	How many historical consumptions would be re-costed against different layers.
Net COGS change	The total dollar swing across all affected sales if you apply.
Per-product rows	Each product's SKU, warehouse, its reassigned-usage count, and its COGS Δ.
FBA excluded	Flags products with Amazon FBA layers — those layers are excluded from reallocation and marked on the row.
Locked-period block	If the re-date would rewrite a locked accounting period, the dialog blocks Apply and lists the reasons (see below).

From here you choose Move date only, Apply (N) — where N is the reassigned-usage count — or Cancel. The preview writes nothing; it only drives your choice. The same read-only impact data is available on its own so tools can check a proposed date before committing to it.

The locked-period guard

If you lock your books up to an accounting lock date (in accounting settings), a re-date can't reach into that closed period. Two guards enforce it, both exempting initial counts:

1. Date guard. A re-date is rejected when the date you're moving to — or the take's current date you're moving from — falls on or before the lock date. You'll see "Cannot move Stock Take #… to <date>: that date is within the locked accounting period (on or before <lock date>)." (StockTakeDateInLockedAccountingPeriodException).
2. Reallocation guard. Even when the layer's own dates sit after the lock date, re-ordering the queue can change which layer a locked-period sale consumed. If a replay you opted into would change COGS on any consumption dated inside the locked period, it's rejected with "Cannot reallocate: this would change COGS in a locked accounting period." (StockTakeReallocationLockedPeriodException), and the preview dialog shows the block instead of an Apply button.

To make the change, either move the lock date, or pick a target date that keeps both the take and its affected consumption outside the locked period.

Re-dates are deadlock-safe

A re-date touches rows that concurrent allocation jobs also lock. If a transient database deadlock hits, SKU.io retries the whole operation up to three times before surfacing an error, so a busy moment doesn't fail your edit.

Reverse a closed take

Reversing undoes a finalized count outright — it removes the stock the take added (or re-adds the stock it removed) and returns the take to an editable state. Use it when a count was wrong and none of the stock it created has been touched yet.

1. Open the closed take and click Reverse.
2. In the Reverse Stock Take dialog, SKU.io analyzes the take and shows Items Adjusted, FIFO Layers, and Value to Reverse.
3. If the take can be reversed, you'll see "This stock take can be reversed. No FIFO layers have been consumed." Confirm the reverse.

What you'll see: the inventory effects are undone and the take returns to Open (a full count) or Draft (an adjustment), with its value change and variance direction cleared. You can then re-count or delete it.

Reversing is blocked in three cases:

Situation	Result
The take isn't closed	"Only closed stock takes can be reversed."
The warehouse is Amazon-managed	"Amazon warehouse stock takes cannot be reversed." — Amazon owns the physical count, so reconcile through the channel feed, not here.
A created FIFO layer has been consumed	"Cannot reverse stock take: some FIFO layers have been consumed." — use a compensating adjustment instead.

You can't reverse a take whose stock has moved on

Once any found-stock layer has been sold, transferred, or assembled, reversing would corrupt that downstream history — so SKU.io refuses. The Reverse Stock Take dialog detects this and switches to the compensating-adjustment flow automatically.

Create a compensating adjustment

When a closed take's FIFO layers are already consumed, you can't reverse it — but you can neutralize its effect with a compensating adjustment: a new adjustment-mode take with the inverse quantities, linked back to the original as its parent.

You reach this from the Reverse Stock Take dialog. When the take can't be reversed, the dialog shows a Compensation Qty column with each item's inverse quantity:

1. Review the proposed compensation quantities.
2. For an item that removes stock, the dialog shows Available, Protected, and Safe to Remove, and flags any item whose removal would collide with protected allocations. Adjust the quantity down to stay within Safe to Remove. Items you set to zero are skipped.
3. Create the compensating adjustment. SKU.io opens the new child take in Draft.
4. Review and finalize the adjustment when ready.

The detail page shows the link both ways: the child take carries a banner reading "This is a compensating adjustment for Stock Take #…", and the original lists its Compensating adjustments.

Creating one is blocked when:

Situation	Result
A compensating adjustment already exists	"A compensating adjustment already exists for this stock take." — one per take.
No item has a variance to reverse	"No items with variances found to compensate."
The take isn't closed	"Compensating adjustments can only be created for closed stock takes."

For how the inverse posting moves stock and cost, see How adjustments move stock & cost.

Correct FIFO layer costs

Cost correction fixes the unit cost that landed on a finalized found-stock count — for example, a count entered at a placeholder cost, or a layer left at zero cost. It works on a closed take, previews the downstream COGS impact, then applies the change and re-costs affected sales.

1. Open the closed take and go to its Items section.
2. Click Edit Unit Costs (shown for a closed, non-Amazon take that has found-stock items).
3. Enter the corrected New Cost for each item you want to fix.
4. Click Submit Cost Changes (N). The Cost Correction wizard opens with a preview.
5. Review the impact — Items Changed, FIFO Layers, Cost Change, and Affected SO Lines, plus per-layer old and new cost and the downstream COGS delta on any consuming sale.
6. Apply the corrections.

What happens on apply: SKU.io updates each FIFO layer's total cost (the average recomputes automatically), records a dated revaluation so the change is auditable, keeps the item's unit cost in sync, adjusts the take's value change, and invalidates COGS on every affected sales order line so it recomputes at the corrected cost.

Cost correction also repairs stale zero-cost layers

An item whose unit cost already matches the value you enter is normally skipped — with one deliberate exception. If the item reads the right cost but its FIFO layer was left at a stale or zero cost (a layer a plain COGS rebuild can't fix, because it would source cost from sibling layers that are themselves zero), cost correction still repairs the layer. That's the case cost correction exists to catch.

To understand when to reach for correction versus a full rebuild, see Correcting COGS: revalue vs rebuild vs recalculate.

Archive and unarchive

Archiving hides a take from the working list without changing any inventory or cost. The list defaults to non-archived takes.

A single take: on the list, use the row's Archive / Unarchive toggle, or click Archive on the take.

In bulk: on Inventory → Stock Takes, select rows, choose a scope — Selected Only or All Filtered — and click Archive (or Unarchive). All Filtered resolves the ids from your current filters, so you can archive an entire filtered set without checking each row.

Archiving twice is harmless

Archiving an already-archived take (or unarchiving one that isn't archived) returns a gentle warning rather than an error, so a bulk action never fails on a row that was already in the target state.

Delete a stock take

Deleting removes a take permanently. For a draft or open take that's just a clean-up. For a closed take, delete first reverses the take's inventory effects — it removes the stock the take added or re-adds the stock it removed — then refreshes the product inventory caches so on-hand and available reflect the change immediately.

A single take:

1. Open the take and click Delete.
2. In the Delete Stock Take dialog — "This will permanently delete this stock take and all its items. This action cannot be undone." — confirm.

In bulk: select takes on the list, pick a scope (Selected Only or All Filtered), and click Delete.

Delete is blocked when stock has been consumed

SKU.io refuses to delete a closed take whose created FIFO layers have already been consumed (any layer with a fulfilled_quantity above zero) — deleting would corrupt that downstream stock and cost history. You'll get a per-item reason like "Stock Take Item: <SKU> has 2 used fifo layer(s) and cannot be deleted." Reverse the take (if nothing's consumed) or post a compensating adjustment instead. The Delete button only appears on a closed take when this pre-check passes.

The list also exposes a deletable pre-check per take, so the bulk toolbar and row menu can hide or disable Delete on a take whose stock has moved on before you ever open the dialog.

Next steps

• Finalize a stock take — reconcile and post a count, and finalize a compensating adjustment.
• How stock takes work — the draft → snapshot → variance → close model behind these actions.
• FIFO layers & how COGS is realized — the layers a re-date re-orders and a cost correction repairs.
• Correcting COGS: revalue vs rebuild vs recalculate — when to cost-correct, revalue, or rebuild.
• View the movement ledger — the audit trail these edits write, and the job tray a reallocation runs in.
• Stock take reference — every status, field, and list column.