Rebuild COGS & the SKU COGS Health dashboard

The SKU COGS Health dashboard is where you audit how consistent each product's cost of goods sold is across its FIFO layers, spot products whose per-unit cost swings widely, and trigger a rebuild — a full re-pricing of every layer from the best-available cost, in date order. This guide covers reading the dashboard, rebuilding one product or a selection, running the all-products rebuild as a tracked background job, and exporting the resulting cost changes.

Rebuild is the heaviest of three cost corrections

SKU.io has three ways to fix costs, from lightest to heaviest: revalue (change one layer's cost by hand), recalculate (re-derive a product's layers in place), and rebuild (re-price every layer chronologically and propagate the change to every place it was consumed). This page is about rebuild. For the difference — and when to reach for each — read Correcting COGS: revalue vs rebuild vs recalculate. To change a single layer's cost instead, see Revalue COGS.

Before you begin

Requirement	Why it's needed
Inventory read/write access (scope.rw:inventory)	Viewing the dashboard, exporting, and every rebuild action are gated on it.
Products with FIFO layers	The dashboard and rebuild only apply to warehouse-tracked products that have received stock. A product with no layers shows nothing to rebuild. See Browse & manage FIFO layers.
An understanding of what rebuild does	Rebuild re-prices layers and rewrites the cost of past consumptions, so it can restate historical COGS. Read FIFO layers & how COGS is realized first if the model is new to you.

Rebuild restates history

Rebuilding re-prices layers and propagates the new cost to every fulfillment, adjustment, or transfer that already consumed them — so figures on past orders and accounting can change. Run it when you've corrected an underlying cost (a wrong receipt cost, a fixed kit component) and want the correction to flow everywhere, not as routine maintenance.

Open the dashboard

Go to Inventory → COGS (route /inventory/cogs). The page is titled SKU COGS Health and opens on a table of every product that has FIFO layers, one row per product.

Read the summary tiles

Four tiles across the top summarize the products currently in view (they respect your filters):

Tile	What it shows
Total SKUs	The number of products with FIFO layers in the current view.
Total Inventory Value	The summed value of all on-hand layers across those products.
Average COGS	The average per-unit cost across the products in view.
Avg Variation	The average Variation % across the products in view — a quick read on how consistent your costs are overall.

Read the table columns

Each row is one product. The columns:

Column	What it holds
SKU	The product's SKU.
Product Name	The product's name.
Default Cost	The product's default unit cost (unit_cost) — the fallback cost on the product record.
Initial COGS	The cost of the product's earliest cost basis — typically its initial stock-take or first receipt.
Min COGS / Max COGS	The lowest and highest per-unit cost among the product's active (non-archived) layers.
Avg COGS	The average per-unit cost across those layers.
Median COGS	The median per-unit cost across those layers.
Variation %	How widely the per-unit cost spreads across the product's active layers, as a percentage. A high value means the same product was costed very differently across receipts. The chip is color-coded: green under 10%, amber from 10% up to 30%, and red at 30% and above.
Qty	Total on-hand quantity across the product's active layers.
Total Value	The summed value of those layers.
Layers	The count of active (non-archived) layers for the product.
Actions	View Details opens the product's COGS detail page (/products/{id}/cogs), where you can browse every layer and its consumptions.

Variation % is a spread indicator, not an error

A red Variation % doesn't mean something is wrong — a product genuinely bought at rising prices will show high variation. Treat it as a prompt to look, not a defect. Use View Details to see which layers drive the spread before deciding whether a correction is warranted.

Filter and search

• Search by SKU or product name using the search box.
• Min Variation % and Max Variation % narrow the list to products whose variation falls in a range — for example, set the minimum to 30 to surface only the products with the widest cost spread.

When no products match, the table shows an empty state reading No SKUs Found. On a phone, the same data renders as a stacked card list rather than a wide table, with the summary tiles above it.

Rebuild COGS for one product or a selection

Rebuild re-prices every layer of a product from its best-available cost in chronological order and propagates the new cost to every consumption of those layers.

Rebuild a selection from the dashboard:

1. On the SKU COGS Health table, select the checkbox on each product you want to rebuild.
2. In the selection actions bar that appears, click Rebuild COGS for Selected.
3. Confirm. SKU.io rebuilds each product and reports how many succeeded and how many failed.

If every product rebuilds cleanly, you get a success message with the count. If any product fails, the response is a failure with a per-product breakdown — the successful ones are still rebuilt, and the failures are listed with their error so you can address them individually.

How a rebuild prices each layer

• Kits rebuild their components first. When you rebuild a kit (bundle) product, SKU.io rebuilds each component product first, then recomputes the kit's unit cost from the fresh component costs.
• Initial-count stock takes are skipped. A layer that came from an initial count stock take is a cost basis, not a derived cost, so rebuild leaves it untouched and prices everything downstream from it. See How stock takes work.

You can also rebuild a single product from its own COGS detail page (View Details → Rebuild COGS), which runs the same operation for that one product.

Rebuild ALL COGS as a tracked background job

Rebuilding every product at once can take a long time, so it runs as a tracked background job with a live progress modal rather than blocking the page.

1. On the SKU COGS Health table, click Rebuild All COGS.
2. In the Rebuild All COGS dialog, read the summary of what rebuilding does, then choose a scope under Rebuild Options:
   • Leave the options unset to rebuild every product.
   • Check Only rebuild products not rebuilt recently and set a Rebuild products last rebuilt before date to skip products already rebuilt after that date — useful for resuming a large run without redoing finished work.
3. Click Start Rebuild.

A COGS Rebuild Progress modal opens and updates in real time as the job runs in batches. It shows:

• Processed / total and a progress bar.
• A running failed count.
• A recently rebuilt list of products as they complete.
• The Job ID, for reference.

The job auto-detects completion once the processed count reaches the total. Any products that failed are collected into a failed products list with their error messages, so a single bad product doesn't hide the rest of the run.

Cancel a run: while it's still processing, click cancel in the progress modal. Cancellation is blocked once the job has already completed, failed, or been cancelled — there's nothing left to stop. If an underlying batch has already finished and been cleaned up, SKU.io skips it silently rather than erroring.

Export the cost changes from a rebuild

After a tracked rebuild, you can export exactly which layers changed cost and by how much.

1. In the COGS Rebuild Progress modal (or when reviewing a completed job), click Export Changes CSV.
2. SKU.io downloads a CSV named fifo_layer_changes_job_<id>_<timestamp>.csv.

The export reads the revaluation rows written during the job window and emits one row per changed layer, with these columns:

Column	What it holds
Changed At	When the layer's cost was rewritten.
SKU / Product Name	The product the layer belongs to.
Warehouse	The warehouse the layer sits in.
FIFO Layer ID	The layer's identifier.
FIFO Layer Date	The layer's date (its position in the FIFO order).
Before Cost / After Cost	The per-unit cost before and after the rebuild.
Cost Difference	After minus before, per unit.
Cost Change %	The percentage change from the old cost.
Original Quantity	The layer's original received quantity.
Link Type	What created the layer (receipt, adjustment, stock take, transfer, and more).
Revaluation ID	The revaluation record behind the change.
Drawer Reference	A link back to the source document, where one exists.
Reason / COGS Source	Why the cost changed and which cost basis it was sourced from.

"No changes found" is normal

If the rebuild didn't actually move any costs — everything was already priced correctly — the export returns a No FIFO layer changes found message (a 404) rather than an empty file. Only rebuilds that restated at least one layer produce a CSV. The export also caps at a high row limit and applies a short start-time cushion so a change posted right as the job began isn't missed.

This CSV is distinct from the COGS report export you get from Revalue COGS — this one is scoped to a single rebuild job's before/after deltas, not the full current cost picture.

When a rebuild is blocked: Orphaned FIFO layers

A rebuild prices each layer from the record that created it — a receipt line, an adjustment, a stock-take item. If that source record was deleted but the layer wasn't, the layer is orphaned: it has no cost basis to rebuild from.

Rather than silently mis-pricing it, SKU.io aborts the whole product's rebuild and raises an Orphaned FIFO Layer detected error carrying a full diagnostics dump — the layer ID, product, warehouse, quantities, costs, dates, and movement count. Because the rebuild runs in a transaction, nothing for that product is changed; the product is reported as a failure (in a selection or the tracked job's failed list) and the rest continue.

If you hit this, note the FIFO Layer ID from the diagnostics and open it in Browse & manage FIFO layers to reconnect or clean up the layer before rebuilding again.

Empty layers are fine to archive

An orphaned layer (a broken link) is different from an empty layer (one that's fully consumed, quantity zero). Empty FIFO layers are a normal end state and can be archived — they don't block a rebuild. See the FIFO layer fields, statuses & enums reference.

Amazon FBA stock on the detail page

The SKU COGS Health headline metrics — Avg COGS, Variation %, Qty, and the rest — cover your warehouse FIFO ledger only. Amazon FBA stock is valued on a separate weighted-average-cost (WAC) ledger and has no warehouse, so it isn't folded into those numbers. On a product's View Details page, any FBA stock appears as a clearly labeled secondary Amazon summary card (units, weighted-average cost, total value, and layer count) so the two ledgers stay readable side by side without distorting the headline. The dashboard export flags each product's valuation method as FIFO or WAC accordingly.

Next steps

• Correcting COGS: revalue vs rebuild vs recalculate — choose the right tool for the fix.
• Revalue COGS — change one layer's cost, or run the COGS report.
• Browse & manage FIFO layers — inspect and repair the layers a rebuild reads.
• FIFO layers & how COGS is realized — the model behind these numbers.
• FIFO layer fields, statuses & enums reference — every layer field and status.