We operate a physical media retail business with frequent cost variability due to currency fluctuations, import duties, and shipping charge differences. When receiving items against a purchase order, we need the ability to record the actual landed cost per unit at the time of receiving — separate from the product’s current “Cost per item” field.
Currently, Shopify’s native PO/receiving workflow only captures quantities. The variant cost field is a single overwritable value with no per-receipt history, meaning each receive event potentially overwrites accurate historical cost data. This creates real COGS tracking and accounting risks for businesses with dynamic supplier pricing.
Requested: A cost-per-unit field within the receiving workflow that records what was actually paid at time of receipt, without overwriting the standing product cost — similar to functionality that existed in the legacy Stocky app.
This would be invaluable for accurate margin reporting, accounting reconciliation, and reorder decision-making.
I completely agree with this. A single “Cost per item” field isnt enough for businesses where purchase costs change from shipment to shipment.
Being able to record the actual landed cost for each PO receipt without overwriting the default product cost would make COGS reporting, margin analysis, and inventory valuation much more accurate. It would also provide a useful historical record for purchasing decisions and accounting.
The “Cost per item” field in Shopify tracks the current cost of a SKU. Any change made to this field will also affect older date ranges because as it does not retain historical cost data. For now, you’ll need to maintain previous costs externally before making COGS changes.
Ran into this exact gap after Stocky went away. The real issue is that landed cost needs to be a per-receipt record, not a single overwritable field, once duties, freight, and currency shift shipment to shipment, that one “Cost per item” field just can’t hold the truth anymore.
I’ve been building a small tool for exactly this, tracks landed cost per PO receipt (including duty/freight variance) without touching your standing product cost. Still early, but happy to run one of your recent POs through it for free if it’s useful, mostly want to see if it actually solves what you’re describing here. Feel free to DM me if you want to try it.
The native PO gap you’re describing is real, and hopefully Shopify addresses it. One thing worth flagging while that’s being worked on: if you’ve been using Stocky, the exact data you’re asking for — cost per receipt, separate from the overwritten product cost — is already sitting in Stocky’s API right now.
Each purchase_item in the Stocky API carries a supplier_cost_price field: the actual price paid on that specific delivery, at the time it was placed. This is distinct from the product’s current “Cost per item” — which is exactly the snapshot-vs-history distinction you’re drawing. The standard Stocky CSV export doesn’t surface this field at all. It gives you the current cost, not what you paid across different POs over time.
The window to pull this closes August 31 alongside everything else.
I built a Chrome extension (InvoRescue) specifically to extract this layer before the shutdown — pulls the per-delivery cost trail, received_at per line item, and the full PO history from the API. Also walks through capturing vendor notes and par levels since those genuinely can’t be automated (no notes field exists on the Stocky supplier object). One-time purchase, browser-only, no server. Link’s on my profile if useful — happy to answer questions here first about what it does and doesn’t cover.
@bj_1 your description of the problem �� currency fluctuations, import duties, shipping charge differences, needing landed cost at receiving time �� is exactly the gap I am building for. Most tools treat cost as a single field you type once, but the real number only settles after the freight invoice arrives, sometimes weeks later.
What I am working on: per-charge allocation (freight by weight, duty by value, discounts by value), and when a late invoice lands it becomes a new revision with a visible trail �� not a re-entered PO. Plus a report that tells you which units sold before the landed cost was known and by how much those margins were overstated.
Since you are living this problem �� would you be open to a 20-minute workflow review? I am pre-launch and trying to validate the late-invoice case against how people actually handle it. No sales pitch.
This is an accounting-data problem, not just a missing UI field. The standing variant cost and the receipt-level actual cost should remain separate records.
A workable interim model is one immutable row per receipt line: PO number, receipt date, supplier, SKU/variant ID, received quantity, unit purchase cost, allocated duty, allocated freight, currency/FX rate, and calculated landed unit cost. The current product cost can remain untouched. That gives accounting a receipt history and lets margin or inventory valuation use weighted average, FIFO, or a chosen policy later.
I am validating a read-only PO/landed-cost reconciliation report for merchants affected by the Stocky transition. If you can share a synthetic PO export structure (headers only is enough), I can return a free sample report showing the missing fields and reconciliation logic. No store write access or customer data is needed.
@bj_1 what Mingyang_Chen described (immutable row per receipt, standing cost untouched) is pretty much what I built into Reorda, same reason - duty and freight land after the fact, one overwritable field can’t hold that.
each PO line keeps its own cost tied to that PO so nothing gets overwritten on the next receive. separately there’s a running average per variant that blends in freight/discount/handling, so margins reflect what you actually paid over time not just the last invoice. doesn’t touch Shopify’s own “Cost per item” field, tracked internally.
disclosure - built this (Reorda). didn’t post it as a feature suggestion since you wanted this native, but figured worth mentioning since it lines up with what you and Mingyang_Chen described.
One distinction between the approaches above that’s easy to miss: where the final number ends up. A separate receipt ledger is tidy. But Shopify’s profit reports, POS margins and every other app all read one field, the native Cost per item. If your landed number lives somewhere else, your margin reports stay wrong all year.
I build [Binly](Binly ‑ Stocktake & Reorder - Stocky replacement: phone stocktakes, POs & smart reorder | Shopify App Store), so obvious bias, but this was the hill we picked. Freight, duty and discounts get spread across the lines - by value, weight or units, since customs cares what the goods are worth and freight cares what the box weighs - and the landed unit cost is what gets written back into Shopify’s own cost field at receiving. The supplier’s bare price is kept separately for price-change tracking, because blending the two in one field is how you end up comparing last month’s price against last month’s price plus freight.
The genuinely unsolved case is the invoice that shows up three weeks after the goods. Nobody re-costs units that already sold. We true up what’s still on the shelf and log the variance. Honest, but imperfect, and I’d be curious if anyone here has seen a cleaner answer.
partial update - stockyard now shows per-unit landed cost on the PO, live today (header costs spread across lines by value). the write-back into shopifys Cost per item field isnt in yet - thats the piece your thread is really about and its next, since reports only read that one field
There’s a cleaner answer, but it lives one level down from the allocation question. It depends what the cost is attached to.
If cost is one field on the product, then yes. Sold units are gone, you true up the shelf, log the variance, move on. That’s the honest version and you named its flaw yourself.
The distortion is worse than imperfect though. The later the invoice lands, the fewer units are left to absorb it. If the freight bill shows up after 80% of the receipt has sold, the remaining 20% carries five times its share. Margin on everything sold is overstated, margin on everything still on the shelf is understated, and no report surfaces either.
If each receipt is its own dated cost layer instead, the late invoice attaches to the layer the goods actually arrived on. Re-costing sold units stops being a manual restatement at that point. The ledger knows which orders drew from that layer, so the cost trickles down into them and their margins correct themselves. The remainder revalues at the same time, each unit carrying only its own share.
And the boundary that matters isn’t sold versus unsold. It’s the accounting close. Before the lock date, let it flow into the orders that used the goods. After it, one adjustment posted forward in the current period. That’s the line an accountant will hold you to, and it’s a better line than whatever day the stock happened to sell.
This was one of the first things our merchants asked for after Stocky, so we built it properly into Stockroom ‑ Purchase Orders - Purchase orders, inventory management, reporting, COGS + more | Shopify App Store (free, from MyWorks): freight, duty and other charges on a PO allocate across the lines, so each SKU gets a real landed unit cost at receiving - and when a freight invoice arrives late, updating the charge re-books the landed cost on receipts you’ve already taken.
There’s also a landed cost report grouped by supplier, product or PO, and at receive time you choose whether Shopify gets the new average cost or the latest landed cost. Purchase orders and receiving are free and stay free. Happy to answer specifics if helpful!
Your concentration point is the sharpest version of this problem I have seen written down. The later the bill, the fewer units left to carry it.
And no report says so.
Where we landed, having built one of these (Binly, disclosed above): the app keeps per-receipt cost history internally, dated, per delivery, which is your layer ledger in everything but name — but Shopify’s reports still read one field, so that one field needs a policy rather than a pretense. We let the merchant pick. Last landed cost, or a weighted average across what is on hand. Both computed at receiving, while the charges are actually known.
Late invoices are the case we deliberately refuse to automate. A freight bill that arrives after most of the receipt has sold does not silently re-spread. It lands on a review list as “invoice disagrees with what you booked”, and the merchant decides whether to touch the shelf.
Quietly rewriting the remaining units is exactly how you get that five-times distortion. Better to show it than to fake precision.
"Spot on breakdown regarding late invoices and the distortion caused by silently re-spreading costs across already-sold units.
That exact ledger drift and mismatch between per-receipt cost history and native single-field reporting is why we built SyncPulse. We automate multi-location inventory migration, ledger reconciliation, and custom cost tracking without forcing fake precision on merchants.
If you want to completely hand off your post-Stocky audit and reconciliation setup, we are currently onboarding merchants through our $99 Managed Migration & Audit pilot: https://buy.stripe.com/dRm00j2UF9k81LufllgA800
Appreciate you spelling out the landed cost reality so clearly!"
@bj_1 native POs still write a single cost on the product. They do not keep a per-receipt landed cost (freight, duty, FX) separate from Cost per item. That request is real. Spreadsheet or a PO app that stores receipt-level cost is the workaround until Shopify ships it.
If the rest of receiving is also painful (scan, put-away, bins), that is WMS territory. I work on SKUSavvy for the floor side. I would not buy a WMS only to solve landed cost.
The dated cost layer Kalvin_Mizzi describes solves the “when” side, but there’s a second date hiding inside each layer: the duty component.
In 2025–26 the duty rate itself moves by executive order, so two receipts of the same SKU a few months apart can legitimately carry different duty at the same declared value — and a layer that stores only the dollar amount can’t explain why.
Worth adding two small columns to whatever ledger you keep: the HTS code and the tariff-schedule revision the duty was computed under. Cheap to record at receiving, impossible to reconstruct later.
Disclosure: I build a small free open-source tool (tariff-resolver) for exactly that input — screening HTS codes and current Chapter 99 duty layers per SKU from official USITC data, with a watchlist that diffs your codes between schedule revisions.
If anyone wants their catalog checked while waiting on Shopify to ship the native field, DM me a CSV (description, origin, unit value) and I’ll send back HTS candidates + duty components with their compiler notes, free. Screening estimates, not customs advice.
