There is a cost per item field on every variant, and it holds one number: the current cost, with no dates attached. The good news first, because it is better than most merchants assume: Shopify captures that cost at the moment of sale, so changing the field today does not silently rewrite what March appeared to earn. What it cannot do is anything else you might want from a cost history. You cannot see what the cost was on a given day, you cannot correct a supplier increase you found out about late so that it applies from when it really started, and a sale that shipped before the field was filled in can never be costed at all.
- Shopify snapshots the cost at the moment of sale, so past reports do not reprice when you edit the field. That part is right.
- There is no dated history to inspect, so you cannot answer what a product cost in March or prove it later.
- A cost discovered late cannot be applied to the sales it affected; the snapshot already took the old value.
- Sales that shipped with the field empty are left out of profit reports rather than costed at zero, so the report covers a subset of your sales.
What the snapshot does and does not buy you
Capturing the cost when the sale happens is the honest design, and it removes the worst failure mode: a merchant updating a cost cannot accidentally rewrite a closed month. A spreadsheet holding one cost per product does exactly that, which is why hand-built margin history is so often quietly wrong.
What the snapshot does not give you is access. The captured values are inside reports rather than in a record you can read, audit or correct, so questions like what this product cost us in March, or why the March margin looks odd, have no answer beyond the report itself. And if the answer is wrong because the field was stale at the time, it stays wrong.
The three failures this actually causes
First, the silent gap. A sale that went out before somebody filled the field in is left out of profit reporting rather than shown at an absurd margin, which is the honest choice and means the margin you are reading covers only the sales that happened to be costed. Nothing on the screen says which share that is.
Second, the missing correction. Discovering in June that a supplier raised prices in March leaves you with three months of sales snapshotted at the old cost and no way to restate them. Third, staleness at the moment of capture: whatever was in the field when the sale happened is what got recorded, so a catalogue nobody maintains records confident, wrong costs forever.
| Period | Actual cost | Field at the time | What was recorded |
|---|---|---|---|
| January to March | €18,50 | €18,50 | €18,50, correct |
| April to June | €19,40 | €18,50, not yet updated | €18,50, too low |
| Discovered in June | updated to €19,40 | April to June stays wrong | |
| July onward | €19,40 | €19,40 | €19,40, correct |
What a dated cost rule adds
Saving a cost with an effective date closes the previous rule the day before and opens a new one, so the history is a readable set of rules rather than a set of invisible snapshots. You can see what a product cost in March, and you can correct it: entering the increase with its real March date reprices those months and leaves everything earlier alone.
It also makes uncosted sales visible rather than absent. A product with no cost is flagged as missing, and the sales it affects stay in the statement with the gap named, instead of quietly dropping out of a margin that then describes a subset nobody measured.
The field is also only half a cost
Even kept perfectly current, a cost per item is usually the supplier's invoice price rather than what the unit cost to own. Freight, duty, currency conversion and the units that arrive damaged add close to a fifth on ordinary import figures, and a landed cost calculator will show the gap on your own numbers in a few minutes.
That is a separate problem and it compounds with the others: a store with stale invoice-price costs is wrong twice, once about how much and once about which sales it covers. The limits of the COGS report cover what that does to product-level reporting specifically.
Why platforms do it this way
It is a reasonable design decision rather than an oversight. A cost per item is there to support a simple gross profit figure, and snapshotting at sale time is the cheapest way to make that figure stable. Carrying an editable dated history means storing rules rather than values, resolving them per order, and recomputing everything downstream when a date changes. That is a cost engine, and a shop platform is not trying to be one.
Which is exactly why the responsibility lands on the merchant. The field is honest about what it is; the trouble starts when a store treats a snapshot it cannot read as though it were a cost history it could audit, and then cannot answer a simple question about last quarter.
Working around it today
- Keep your own dated record of cost changes, because the snapshots are not a record you can read or correct.
- A price list with effective dates is the minimum viable version, one row per cost per start date.
- Never overwrite a cost without noting the date the new one started; that note is your history.
- Compute costs landed rather than at invoice price, so the number you record is the one that matters.
- If you report margins to anybody, say which cost basis they use and how many sales were costed at all.