How stock takes work
A stock take is how you reconcile what SKU.io thinks is on your shelves with what a physical count actually finds. It's a warehouse-scoped count document that holds one line per product, records what you counted, works out the variance against the system quantity, and — when you finalize it — writes that variance into your FIFO layers, your movement ledger, and your books. Understanding the model is the key to knowing when a count is safe to finalize, what number it will move, and how it lands in accounting.
You manage stock takes under Inventory → Stock Takes. The everyday tasks — building one, counting, finalizing, and amending — each have their own guide; this page explains the machinery underneath them.
This page assumes you know the stock states (on-hand, available, allocated, on-hold, non-sellable) and how FIFO layers realize COGS. Skim those first if a term below is unfamiliar.
What a stock take is
Every stock take carries a warehouse, a mode, a count date, a status, and a set of items (one per product). The mode is chosen when you create the take and decides how each item records its variance.
| Mode | How each item records the change | Variance is |
|---|---|---|
| Full count | You enter the absolute counted quantity you physically found. | counted − adjusted snapshot (see the snapshot model) |
| Adjustment | You enter a signed +/− delta directly (adjustment_qty). | the delta itself — no snapshot is taken |
Use a full count when you are counting real shelves and want SKU.io to work out the difference for you. Use an adjustment when you already know the correction (for example a supplier credit or a known shrinkage) and want to key the +/− directly without snapshotting the whole warehouse. Both modes end up writing the same kinds of FIFO layers and movements — they differ only in how the variance is captured.
The very first count for a warehouse is an initial count — it establishes your opening balance rather than a variance against an existing one. Initial counts are always full-count mode, their snapshot is treated as zero (every counted unit is "found" stock), and their date is pinned server-side to your inventory start date rather than being chosen by hand. An initial count also doesn't sync to your external accounting integration — it's the opening balance, not a period adjustment. See Create a stock take.
The lifecycle
A stock take moves through three statuses — Draft, Open, and Closed — but the path between them depends on the mode. A full count is initiated to capture its snapshot, then finalized; an adjustment has no snapshot to capture, so it goes straight from draft to closed.
- Draft. A new take starts here — fully editable, holding no stock and touching no inventory. You add and remove items freely. See Create a stock take.
- Open (full count only). Initiating the count captures the snapshot for every item and opens the take for counting. You can't initiate an adjustment take — attempting to is rejected, because there is no snapshot to take. See Count stock.
- Closed. Finalizing applies the variance and closes the take. A full count is finalized and reconciled from Open; an adjustment is finalized straight from Draft. This is the step that moves inventory, cost, and accounting. See Finalize a stock take.
Two reversals let you step back:
- Revert to draft pulls an open full count back to draft — it clears the captured snapshot so you can re-scope the take before counting again. No inventory has moved yet, so this is always safe.
- Reverse undoes a closed take's inventory effects: a full count returns to Open, an adjustment returns to Draft. Reversal is refused if any FIFO layer the take created has already been consumed (sold, transferred, or assembled), and Amazon-managed warehouse takes can't be reversed at all. See Amend a stock take.
For the exhaustive list of statuses and their columns, see the stock take reference.
The snapshot model: Two dates, not one
The trickiest part of a full count is that a count takes time — stock can move while you are still walking the aisles. SKU.io separates two distinct moments so a count stays correct even when receipts and sales land mid-count:
| Field | Meaning | What it drives |
|---|---|---|
snapshot_at | The real wall-clock moment the snapshot was captured (set to now when you initiate). | The cutoff for "movements made during the count." |
date_count | The effective / posting date of the count. Defaults to now, but you can back-date it. | The date stamped on the resulting movements, FIFO layers, and accounting journal. |
When you initiate a full count, SKU.io records snapshot_inventory per item — the system on-hand at that instant — and stamps snapshot_at. At finalize, it re-checks the ledger for any movement created after snapshot_at for the same product and warehouse (a receipt, a shipment, a transfer) and nets it in, so the variance it books is:
variance = counted − (snapshot + net movements during the count)
That way, if you counted 100 and a shipment of 5 went out after your snapshot but before you finalized, SKU.io doesn't mistake that legitimate outbound for a counting error.
Because date_count is independent, you can record a count you physically performed last week and have its movements, layers, and journal dated to then — while the during-count math still keys off the real snapshot_at. Re-snapshotting an open take (see Count stock) re-baselines both dates to now, so anything that moved before the re-snapshot is treated as already reflected.
The reconciliation preview you see before finalizing and the finalize itself use the same cutoff — the real snapshot_at moment (falling back to date_count only when no snapshot was captured). So even when you back-date date_count, the preview and the finalized result detect the identical set of during-count movements and show matching variances. The count date only affects the posting date on the resulting movements, layers, and journal — never which mid-count movements get netted in.
Blind counts
A blind count hides the system on-hand from the counter so they record what they physically find, without being anchored to the expected number. While a take is blind, an item's snapshot quantities stay hidden until you enter its counted quantity — the moment qty_counted is set, the snapshot is revealed so you can review the variance.
Turn a blind count on with the Blind count — hide system quantities from the counter checkbox when creating the take. It's only offered for a full count that's not an initial count and isn't scoped from a pre-selected product set — an adjustment take has no snapshot to hide, and an initial count has nothing to compare against. See Create a stock take.
The unit cost basis
Each item carries a unit_cost that fixes its cost basis at snapshot time, so the value a count books doesn't drift as later purchases change your average cost. When SKU.io needs to resolve that cost, it walks a fixed priority chain and stops at the first hit:
- The oldest active FIFO layer's average cost (a layer with quantity still available).
- The newest closed FIFO layer's average cost (if every layer is fully consumed).
- The product's Unit Cost (your configured default).
- Zero, if no cost basis exists anywhere.
For a full count, this cost is computed and persisted per item when the count is initiated. For an adjustment take built in bulk (for example the Create stock take action on the products list), each item is pre-seeded with the product's best-available COGS so the take opens with a cost basis rather than a blank column — the seed is overridable per row, and negative adjustments ignore it entirely (their cost comes from the FIFO layers they consume). When you are choosing a cost by hand, SKU.io surfaces both candidates — Best Available COGS and the product's Unit Cost — so you can pick.
The cost you booked can be corrected on a closed take without reversing it — the cost-correction flow rewrites the affected FIFO layers' cost, adjusts the take's total value change, and invalidates downstream COGS on any sales that consumed those layers. This is distinct from a full revalue or rebuild; see Correcting COGS and Revalue COGS.
What finalizing does
Finalizing is where the count stops being a document and starts moving inventory. For every item with a non-zero variance, SKU.io does one of two things:
Positive variance (you found more than the system had). It creates a new FIFO layer at the item's unit cost and a positive inventory movement of type Stock Take, dated to date_count and stamped with the counted bin (or the warehouse's default location when no valid bin is given). Because that new stock is now on hand, SKU.io releases it to any waiting allocations and backorders. Lot-tracked items land one layer per captured lot, each stamped with its batch and expiry.
Negative variance (you found less). It consumes existing FIFO layers — by automatic FEFO/FIFO, or by the exact layers you named in a lot allocation — writing negative movements against them. The realized cost of what was consumed flows into the take's value change.
Across the whole take, SKU.io accumulates the signed cost delta into value_change and records a variance_direction of positive, negative, or mixed. Large full counts (over 100 items) run through a bulk path for speed, but the effect on your stock and cost is identical.
A count that writes on-hand down is checked against open allocated reservations first: if the counted reduction would leave a sales order or transfer holding stock that no longer exists, SKU.io either blocks the finalize (naming the conflicting documents) or, in downgrade mode, quietly demotes the affected reservations back to planned. Ship, cancel, or backorder the conflicting documents first. This is the same truth model as the over-allocation health check — see Allocations and backorders.
Every movement a take writes is a first-class ledger entry you can trace later. See The movement ledger, Browse FIFO layers, and — for how a stock take compares to a direct adjustment — How adjustments move stock and cost.
Accounting
Closing a stock take posts a Stock Take accounting transaction, dated with date_count as its transaction date and referencing the warehouse. Each item with a non-zero variance contributes a balanced debit/credit pair:
| Variance | Debit | Credit |
|---|---|---|
| Positive (stock found) | Inventory | COGS |
| Negative (stock lost) | COGS | Inventory |
The inventory and COGS nominal codes are resolved from the warehouse and the product, and the amount is the realized cost per unit of the variance. An initial count posts its opening-balance transaction but doesn't sync it to your external accounting integration.
You can't re-date a stock take onto or before your accounting lock date — the guard blocks both the date you are moving to and the date you are moving from, so a take already sitting in a locked period can't be dragged around either. Separately, a re-date whose FIFO reallocation would change COGS on a consumption inside a locked period is refused even when the layer's own dates are clear of the lock. Initial counts are exempt. See Amend a stock take.
For how these entries fit the wider ledger, see How order financials flow to accounting.
Adjacency: FBA inbounds that inject their own stock
Stock takes aren't only a manual tool — other flows use a covering take to inject stock they need. When you process a legacy Amazon FBA inbound whose source warehouse is short of the units it's sending, SKU.io creates a covering adjustment stock take to top up exactly the per-product shortfall, then feeds those units into the inbound's warehouse transfer.
This covering take is deliberately different in one way: it injects the FIFO stock without releasing it to backorders. The whole operation holds a lock on the source pool from inject through to transfer, so the topped-up units flow into the transfer's own reservation instead of being claimed by a pending sales-order backorder. The take is idempotent — reprocessing the same inbound reuses the existing covering take rather than injecting twice.
The inbound above is processed through its transfer automatically. You can't manually receive a channel-managed (Amazon FBA / AWD / WFS) transfer — SKU.io rejects the attempt with a clear message, because the channel owns that receipt. See Receive a transfer.
Next steps
- Build one: Create a stock take
- Count and initiate: Count stock
- Apply the variance: Finalize a stock take
- Re-date, reverse, or delete: Amend a stock take
- Look up every status and field: Stock take reference
- Understand the cost side: FIFO layers and how COGS is realized · Correcting COGS