Shopify keeps one cost per item per variant and records it with each sale, so editing the field never reprices past orders. It keeps no dated history, though: you cannot look up a past cost, apply a late increase to the sales it affected, or cost a sale that shipped without one. Historical COGS needs costs stored with dates.
Historical COGS means knowing what each product cost on any past day, so every sale is priced at the cost that was true when it happened. Shopify gets half of that right: it records the cost per item with each sale, so editing the field today does not rewrite what March appeared to earn. What it does not keep is the history itself. You cannot look up what a product cost on a given day, you cannot apply a supplier increase you found out about late to the sales it affected, and a sale that shipped before the field was filled can never be costed at all. This guide covers what the field does, what it cannot do, what each gap costs you, how profit apps handle it, and how to keep a cost history that holds.
In short
- Shopify snapshots the cost per item with each sale, so past reports do not reprice when you edit the field. That part is right.
- There is no dated history to inspect, so nobody can answer what a product cost in March, or prove it later.
- A cost discovered late cannot reach the sales it affected, and sales made without a cost stay out of profit reports for good.
- Historical COGS needs costs kept as dated rules: a new cost starts on its own date, the old one ends the day before, and a correction can be dated back.
What Shopify's cost per item field records
Every variant has one Cost per item field, set on the product page under pricing. It is optional, it holds one number, and it carries no dates. When a sale happens, Shopify records the cost that was in the field at that moment, and its profit reports are built from those recorded costs.
Profit is reported only for variants that had cost recorded at the time they were sold. Shopify Help Center, Profit reports, checked 1 Oct 2026
That design is the honest one, and better than the spreadsheet most merchants start with, where editing one cell silently reprices every order in the file, last quarter's included. A closed month in Shopify keeps the costs it was sold with. The trouble is everything a cost history is for beyond that.
What the field cannot do
It cannot show you the history it captured. The recorded costs live inside the reports rather than in a record you can open, so a question like what this product cost us in March, or why March's margin looks odd, has no answer beyond the report itself.
It cannot take a correction. Discovering in June that a supplier raised prices in March leaves three months of sales snapshotted at the old cost, and nothing in the admin restates them. The report shows those months' margins too high for as long as anyone reads it, and staleness at the moment of capture works the same way: whatever was in the field when the sale happened is what got recorded, so a catalogue nobody maintains records confident, wrong costs forever.
And it cannot cost what it never saw. 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 it means the margin you read covers only the sales that happened to carry a cost. Nothing on the screen says which share that is, and filling the field later does not bring those sales back.
| 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 |
Why historical COGS matters beyond one report
Three everyday decisions depend on knowing what goods cost on a past day. Returns, first: a unit sold in March and returned in June should be credited at March's cost, or a price change between the two invents a gain or a loss that nobody made, which is the rule set out in which cost a refund credits back. Pricing, second: a margin history that cannot be restated after a late invoice tells you a product was healthier than it was, in exactly the months you would use to decide whether its price needs to rise.
And the year end. An accountant valuing stock and a merchant reading margins have to agree on what the goods cost and when, which is impossible if one side works from invoices with dates and the other from a single number that was overwritten twice since. A dated cost history is what lets both look at the same March.
How profit apps handle cost history
Apps that track profit on Shopify answer this differently, and the answers move. On 16 Apr 2026, TrueProfit's help centre published a notice about the upgrade of its COGS page, and its historical COGS feature, which let a merchant set different product costs for different date ranges, did not survive it.
In the new COGS experience, Historical COGS is no longer available. TrueProfit help centre, COGS page upgrade and migration notice, 16 Apr 2026, checked 1 Oct 2026
Its changelog since then adds a recalculation that applies a cost to past orders for the products and date ranges a merchant picks, first on 26 May 2026 and in its current form on 24 Aug 2026; both pages were read on 1 Oct 2026. The difference worth holding on to is between recalculating and remembering. A recalculation overwrites past orders with a cost you choose today, which fixes a known mistake but keeps no record of what the cost was before. A dated cost history keeps every value with the day it started, so the past can be read, audited and corrected without losing what was there.
If cost history matters to how you run the store, ask any tool which of the two it does, and read its changelog as well as its feature list. The wider comparison of Shopify profit tracking apps sets out the rest of what separates them, with every price dated.
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. Every cost type in nouz works this way: product costs, shipping rate cards, pick and pack, packaging, payment fee rules and fixed costs.
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.
On the day a store connects, nouz starts every variant that has a Shopify cost per item with one rule at that cost, running from the store's first order, because a starting value is better than a gap. If you know what a product cost before, you add the older costs with their own dates; once a variant has a cost in nouz, a later sync never changes it, so your history is never overwritten by the field it was built to replace.
Backdating stays possible and stays deliberate. A correction dated to March reprices March onward and nothing before it, which is the only intended way a closed day changes, and how to do it without surprising anybody is set out in backdating a cost safely.
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.
Keeping a cost history yourself
- 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.
A correction, made on 1 Oct 2026: two earlier posts on this site, does Shopify show profit and where profit is in the Shopify admin, said that editing the cost per item field reprices sales already made. It does not, as this guide explains, because Shopify records the cost with each sale. Both posts now say so, each with its own correction note, and this is one of the corrections the methodology page lists.