No. Shopify stores one Cost per item on each variant, and a new value overwrites the old one. Buy the same product at $10.00 and later at $12.00 and only the most recent number survives, including for the units you already sold at the older price.
This is one of the most common questions asked by anyone who buys the same thing more than once: multiple locations, seasonal reorders, two suppliers for one product, or a buy-sell-trade store where the cost changes every week.
It is worth understanding why the answer is no, because the reason is not a missing checkbox. It is the shape of the data, and that determines which workarounds can possibly help.
Why Does One Product Have Two Costs?
Because you bought it twice. Nothing about the product changed, but the money you paid did, and there are more ways for that to happen than most catalogues allow for:
- The supplier repriced. Raw materials moved, or your order quantity crossed a break.
- The exchange rate moved. Same invoice in the supplier's currency, different number in yours.
- Freight moved. One container at $5 a unit, the next at $3, for identical goods.
- Duty moved. A tariff change repriced every shipment that landed after it.
- You used a second supplier for the same item, at a different price.
So the same SKU genuinely has several true costs sitting in your warehouse at once. That is not an error to be tidied up. It is the actual state of your inventory, and any number that reduces it to one value is throwing information away.
What Happens When You Update Cost Per Item
Shopify gives each variant one field called Cost per item. It holds a single current number. When the second shipment lands cheaper or dearer and you update it, the previous value is not archived anywhere. There is no version history, no effective date, and no way to ask what the field said in March.
The consequence catches people out, because it works backwards as well as forwards. Every report built on that field, including Shopify's own profit reporting, prices every historical order at whatever the field says today. Update the cost after a price rise and last quarter's margin quietly gets worse, on sales that already shipped at the old cost.
A field is not a ledger
Shopify is not missing a setting here, it is missing a data structure. A field holds one value and overwrites. A ledger holds one row per event and never overwrites. You cannot reach the second by being more disciplined with the first.
What Is a Cost Layer?
A cost layer is one receipt of stock, recorded with the quantity you took in, what each unit cost, the date and the location. Every delivery creates a new layer rather than editing an old one, so nothing is ever overwritten.
When you sell, the layers deplete in a defined order. Under first-in-first-out that is oldest first, so the units you ship today are costed against the delivery that has been sitting longest. Sell 500 units when your oldest layer holds 400 and the sale draws 400 units at the old cost and 100 at the next one, which is the correct answer and one that a single field cannot produce.
This is why it matters for the questions you actually get asked. What did the units I sold in March cost, given they arrived in January? What is my stock on hand worth right now, when half of it landed at $11.40 and half at $12.00? What number goes to cost of goods sold this month? All three need history, and history means rows rather than a value.
Is a Cost Layer the Same as a Batch?
No, and the two get confused constantly because one event usually creates both. A delivery arrives and it is a batch and a cost layer at the same moment. They come apart immediately afterwards.
| Batch or lot | Cost layer | |
|---|---|---|
| What it is | A physical fact | A financial fact |
| Question it answers | Which physical units are these? | What did these units cost? |
| Created by | A production run | A receipt of stock |
| Carries | Production date, serial range, expiry | Quantity, unit cost, date, location |
| Who needs it | Regulators, recalls, traceability | Accountants, valuation, margin |
| Two purchases, one run | Still one batch | Two layers |
Buy the same production run twice, three months apart, at different prices, and you have one batch and two cost layers. Split a single delivery across three locations and the batch is still one batch. Repack or rebadge and the physical identity survives while the cost identity changes.
Which one you need depends on who is asking. A regulator or a customer tracing a defect needs batches. Your accountant, your bank and your own margin report need cost layers. Food, pharmaceuticals and cosmetics need both, and they are two systems rather than one system wearing two hats.
There is one genuine overlap worth knowing. FIFO costing draws stock down in the same oldest-first order that expiry-dated goods physically ship, so the two often agree about which units left. That is a useful coincidence, not the same feature.
Four Workarounds, and Why They Fail
Every store that hits this problem tries at least one of these. Each fixes something real, and each has a cost worth knowing before you commit to it.
A Separate SKU Per Purchase
The most confident wrong answer in the category, and it is offered in good faith because it is technically true: a SKU with one cost is a cost you can trust.
In practice, if you carry 2,000 products and buy each three or four times a year, within twelve months you are carrying 8,000 SKUs. Your barcode stops identifying a product and starts identifying a purchase. Staff pick the wrong one. The storefront lists the same item four times. Your reorder report becomes meaningless, because demand for one product is split across four rows that look like four products.
And the original problem is not solved, only moved. The moment you sell one, you still have to work out which of the four it was. A SKU identifies a thing you sell; cost is a property of when you bought it. Overloading one with the other produces an item master nobody can use.
A Spreadsheet Beside Shopify
This is where almost everyone starts, and the maths in it is usually right. The formulas work. What fails is operational.
A spreadsheet cannot see a sale. Your store sells forty units today and the file has no idea, so the layers only draw down when a human remembers to draw them down. The freight invoice that arrives three weeks after the stock rarely makes it back into anything, because the units it belongs to have already shipped. And the moment two people touch the same file, or the person who built it leaves, the whole thing becomes archaeology.
Just Use Average Cost
Perfectly legitimate, and the default in most retail systems for a reason: average cost never errors. It always returns a number, never asks which delivery a unit came from, and never blocks anything.
The trade-off is that it blends. If your costs are stable and domestic, the blend is close enough to the truth that nobody is misled. If you import, and freight, duty and currency move between shipments, the blend hides exactly the movement you needed to see. It also does not help with the thing that triggered this question, because a rolling average still needs the receipts underneath it, and Shopify does not keep them.
Keep the Field Updated
The most tempting one, because it feels like a discipline problem. It is not. Updating Cost per item correctly, on time, every time, still destroys the previous value and still reprices your history. Doing it more carefully makes the current number better and the historical record no better at all.
| Workaround | What it fixes | What it costs you |
|---|---|---|
| A SKU per purchase | Each SKU has one trustworthy cost | Catalogue bloat, split demand, mispicks, and you still have to know which sold |
| A spreadsheet | Real per-receipt history, at no software cost | It cannot see a sale, so it is only as current as the last person to update it |
| Average cost | One defensible number, always available | Blends away the cost movement that mattered; still needs receipts underneath |
| Updating the field | The current cost is accurate today | Reprices history every time, so old sales silently change margin |
FIFO or Weighted Average?
Both are accepted accounting methods, and this choice comes after you have a ledger rather than before. Neither can be computed from a single field.
| FIFO | Weighted average | |
|---|---|---|
| Cost of a sale | The oldest unbroken receipt still on hand | A rolling average across all stock on hand |
| Best when | Costs move: imports, currency, tariffs, variable freight | Costs are stable and domestic |
| Margin per order | Traceable to a receipt | Indicative |
| Effort | Needs a layer per receipt, drawn down in order | Needs the same receipts, then one calculation |
If you import, FIFO usually earns its keep, because the whole point is that this container did not cost what the last one did. How to track FIFO COGS on Shopify covers the mechanics in more detail.
How to Get Per-Receipt Costs on Shopify
The workable answer is to leave Shopify doing what it does well and keep the cost history somewhere that is built for it. Shopify remains the source of truth for quantity, and a cost ledger sits beside it holding one layer per receipt.
That is the job Landara does. It connects to your store, creates a dated cost layer every time stock is received, and depletes those layers oldest first as orders ship, so every order is costed against what those specific units actually cost. Freight, duty and clearance are landed into the layer before it forms, which is what makes the number worth trusting in the first place: your cost of goods sold is only as good as your cost.
At month end it produces a ready-to-post Dr COGS / Cr Inventory journal for Xero or QuickBooks Online. You decide when it posts; Landara never writes to your ledger on its own.
It does not take inventory management away from Shopify, and it is not lot or expiry tracking. If you need batch traceability for a regulator, that is a different system and you should run both.
Frequently Asked Questions
Can Shopify store more than one cost for the same variant?
No. Shopify stores a single Cost per item value on each variant. It is one current number, and saving a new value overwrites the old one with no history kept. That is a data model decision rather than a missing setting, so no amount of care in the admin will produce a second cost for the same variant.
What happens to my old cost when I update Cost per item?
It is gone, and not only for future sales. Any report built on that field, including Shopify's own profit reporting, prices every historical order at whatever the field says today. Update it after a price rise and last quarter's sales quietly reprice themselves to the new, higher cost.
Is a cost layer the same as a batch or lot number?
No. A batch is a physical fact about which units were manufactured together, and it drives recalls, traceability and expiry. A cost layer is a financial fact about what a particular receipt of stock cost you, and it drives cost of goods sold and inventory valuation. One delivery often creates both at once, but they separate as soon as you buy the same production run twice at different prices.
Does creating a separate SKU for each purchase price work?
It gives every SKU a trustworthy cost, and it breaks almost everything else. Your barcode stops identifying a product and starts identifying a purchase, demand for one product splits across several rows so reorder reports stop meaning anything, staff pick the wrong variant, and the storefront lists the same item several times. It also does not answer the original question, because you still have to know which of them sold.
Do I need FIFO, or is weighted average good enough?
Weighted average is a legitimate accounting method and is enough for many stores with stable domestic costs. FIFO earns its keep when unit costs move: imported goods, currency swings, tariff changes, or freight that varies shipment to shipment. Both need per-receipt records underneath them, which is the part Shopify does not keep, so the choice of method comes after you have a ledger rather than before.
Can I just keep a spreadsheet of costs beside Shopify?
Many stores do, and it is where most start. The limit is not the arithmetic, it is that the spreadsheet cannot see a sale. Your store sells forty units and the file has no idea, so the layers only draw down when someone remembers to update them, and the freight invoice that arrives three weeks after the stock rarely makes it back into anything.
The short version: one product can have many costs, and Shopify can hold one of them. Everything else is a decision about where the other ones live.
One SKU, Every Cost It Actually Had
Connect your store and Landara costs every order against real FIFO layers, with freight and duty landed in, then hands your bookkeeper a ready-to-post journal. Free tier available.
Try Landara Free