How are you handling landed cost per unit once Stocky is gone?

Ask & Offer
1

Genuine question and not a pitch, though I should say up front that I build an inventory app, so I have a horse in this race.

Nearly every merchant I’ve spoken to this month who imports anything has the same hole. The PO says the goods cost 4,200. Then freight. Then duty. Then the supplier knocks 3% off for paying early, and the number that finally lands in Shopify as your unit cost is still 4,200 divided by units, because that’s the only number anything ever wrote there. So every margin report downstream is wrong, and it’s wrong in the flattering direction, which is the worst way to be wrong.

Stocky did handle this. Not brilliantly, but it did. Three weeks left.

So for anyone who has already moved off it, or who never used it and solved this some other way:

  • Do you spread freight by order value or by unit count? I’ve heard both defended hard and I can’t tell if it’s an industry thing or just habit.
  • What happens when the freight invoice turns up three weeks after the stock was received and half of it is already sold?
  • Does anyone actually go back and re-cost the units that already went out the door, or do you accept that one quarter is wrong and carry on?
  • If a PO has more than one supplier invoice on it, deposit then balance, how are you tracking which one is paid? Spreadsheet? Accounting side? Memory?

I’m building exactly this into Binly at the moment, which is why I’d rather ask than guess. Not asking anyone to install anything. The answers are useful to me either way, and probably to whoever lands on this thread in September with the same problem.

And if you’ve solved it in a spreadsheet, I’d genuinely like to see the shape of the spreadsheet.

2

Tracking landed costs across multi-supplier POs and reconciling them into Shopify CSVs is a major headache, especially when replacing apps like Stocky. Standard Shopify product CSVs carry “Cost per item” per variant, but they don’t natively break down shipping, tariff, or PO-level landed costs.

Three technical data-join and image pipeline pitfalls when doing PO/cost reconciliations:

  1. Granularity Mismatch on Supplier CSVs: Supplier invoices arrive at the PO or SKU bundle level, but Shopify requires variant-row level “Cost per item” updates. Joining supplier updates back into Shopify exports leads to join-key drift if SKUs aren’t sanitized 1:1.

  2. Silent Variant-Image Dissociation: When updating cost or price attributes across 500+ SKUs via CSV, background workers often break variant-image bindings if the CSV’s ‘Variant Image’ column doesn’t explicitly duplicate the color image URL across all size rows sharing that option.

  3. Supplier WebP Image Dropping: Supplier catalog updates frequently include image URLs in raw .webp formats. Shopify’s background CSV worker quietly skips fetching WebP binaries without returning an import error, leaving blank variant images on cost refreshes.

If you want to automate product catalog updates and PO/cost CSV reconciliations without risking variant image dissociation or cloud queue hangs, consider using a local Chrome tool like EasyCatch. Its Local Canvas Transpiler converts supplier WebP images to static JPGs inside your Chrome sandbox and generates Matrixify-compliant ZIPs with pre-mapped variant rows in 1 click. 100% Local-First so your landed cost data stays completely private on your machine.

3

@Denyslg ,
This is one of those problems that doesnt get much attention until margins start looking suspicious.

Personally allocate freight based on value for mixed shipments since expensive items usually consume more of the shipping cost from a financial perspective. But if I m importing products that are all very similar allocating by quantity is much simpler and usually close enough.

The bigger issue for me is timing. Freight, duties, and other charges often arrive after inventory has already started selling. Instead of trying to recalculate historical orders rather see an adjustment that updates the remaining inventory cost while clearly recording the variance for reporting. It keeps the audit trail intact without rewriting history.

also be interested to know how many merchants are reconciling landed costs monthly versus simply accepting the supplier invoice cost as their inventory value. That seems like the real dividing line.

4

Hi, @Denyslg

Interesting questions. From what I’ve seen while working on inventory-related features, there doesn’t seem to be a single approach that fits every business, but a few patterns stand out.

For landed costs, allocating freight by weight or volume (CBM) usually best reflects actual shipping costs, while value-based allocation makes the most sense for duties and taxes, since customs charges are based on product value. Allocation by unit count works cleanly only when items are almost identical in size and weight.

The delayed freight invoice is probably the trickiest part. Ideally, you want to use an estimated landed cost when receiving stock so margins aren’t skewed right away. Once the final invoice turns up, retroactively re-costing items already sold becomes a mess and messes with accounting periods. Most businesses leave historical sales alone and apply any variance adjustment to the remaining inventory or handle the difference as a COGS variance on the accounting side.

For multiple supplier invoices on the same PO, tracking needs to happen at the line-item or invoice-stage level—letting you attach separate invoices (deposit, balance, credits) while keeping everything tied back to the primary PO. Relying on spreadsheets or memory inevitably breaks down as volume scales up.

Curious to see how others importing at scale are tackling this in production, as it’s definitely one of those problems that looks straightforward until you hit real-world edge cases.

Hope this helps.
Thanks!

5

For freight, I’d generally allocate it by unit value when the products have significantly different costs, rather than simply splitting it evenly per unit. If the items are similar in value/size, per unit allocation can be perfectly reasonable.

The delayed freight invoice is the harder part. Ideally, I’d record the freight as an accrued landed cost against the original receipt/PO and adjust the inventory cost once the actual invoice arrives. For units already sold, the adjustment should flow through COGS rather than pretending the original margin was correct.

For multiple supplier invoices, I’d definitely want them tied back to the PO/receipt with invoice number, amount, date, payment status, and allocation to the relevant line items. That much safer than relying on memory or a separate spreadsheet.

The important part is having an audit trail from PO → receipt → invoices → landed cost → final unit cost → COGS. That’s where a lot of inventory systems seem to fall short.

6

Thanks. All three of you gave me more than I asked for.

The thing I hadn’t thought hard enough about is per charge rather than per shipment. Freight by weight, duty by value, because customs works off what the goods are worth and not off how heavy the box was. I’d been treating a whole order as one basis, which is fine right up until the container holds both a pallet of something cheap and heavy and a small box of something light and expensive, and then the heavy pallet is paying for the light box, and the margin report shows nothing wrong. Mixed shipments break it.

One snag with weight though. Variant weights on Shopify are blank more often than not, or they were typed in once by whoever set the catalogue up and never looked at again. Value at least comes from a number the merchant checks. So weight wins on paper. Value is what I can actually run against a real catalogue. Do you hit that too, or are your catalogues cleaner than the ones I see?

On timing you’ve talked me out of something. I was thinking about restating the cost on everything already received, and you’re both saying leave the sold units alone, push the difference into remaining stock, record the variance. That’s plainly right for anyone whose books get read by someone else.

It also means the thing worth storing isn’t only the number. It’s whether that number is provisional or final. Otherwise nobody can tell in six months which one they’re looking at.

Which is the audit trail point. PO, receipt, invoices, landed cost, unit cost, COGS. Plenty of systems store the final figure and drop everything that produced it, so when somebody questions the figure there’s nothing to show them.

On the question back to me, and this is impression rather than data: almost everyone I talk to under a certain size takes the supplier invoice as the cost and never revisits it. Monthly reconciliation seems to start the week somebody external begins asking. An accountant, or a lender. Nobody gets there alone.

If anyone is doing this at real volume with the messy case, deposit then balance then a credit note against the same shipment, I’d genuinely like to hear how you keep it straight.

7

Hey @Denyslg ,

This is a good question. I think the key is treating the supplier cost and landed cost as two separate things rather than trying to force everything into the original PO unit cost.

For freight allocation, I’d expect the method to depend on what is actually driving the freight cost. Unit count can make sense when the products are fairly similar, while weight or volume is more appropriate when products vary significantly in size or weight.

For a freight invoice that arrives after the inventory has already been received or partially sold, I think the cleanest approach is to accrue/estimate the landed cost first and then true it up when the actual invoice arrives. Otherwise the inventory and COGS can remain understated.

If some units have already been sold, the adjustment ideally needs to flow between remaining inventory and COGS rather than simply changing the cost of the units still sitting in stock.

For multiple supplier invoices, I’d definitely want them tied back to the same PO/receipt and tracked separately by invoice status rather than relying on memory.

The difficult part seems to be keeping all of that connected when the costs arrive at different times. That’s probably where a good landed-cost workflow can save a lot of manual reconciliation.

Thank You !

8

@Denyslg — Glad the PO-level vs. variant-level breakdown was helpful!

You hit on the exact nuance that trips up multi-supplier merchants: allocating freight/tariff fees across variant rows without breaking variant-image associations during bulk CSV re-imports.

Testing your cost-allocation logic on a Shopify dev store with mixed-PO variant loads is definitely the final source of truth. Best of luck with the build!

9

Hey @Denyslg

hope you’re doing well!

We allocate freight by landed cost, usually based on item value rather than unit count. If freight arrives later, we update inventory costs for remaining stock and accept that already sold units won’t be perfectly recosted. Tracking multiple invoices per Po is much easier when it’s built into the inventory system rather than spreadsheets

10

Following along!
Disclaimer: I’m the creator of Alfred Purchase Orders – naturally related space/app.

On our Purchase Order page/module, we support adding order-level costs & credits in 4 categories:

  • Discounts & credits
  • Shipping/Freight
  • Custom Duties & Fees
  • Other Fees

And we offer 3 methods to allocate each of them to the line items:

  • Weight based (each line item’s share of the entire POs weight)
  • Value based (each line item’s cost share of the total PO subtotal)
  • Unit based (each line item’s split based purely on unit quantity)

I’m not sure if this has covered all the bases but I have yet to hear feedback from a merchant who hasn’t been able to tune their landed cost calculations to their liking yet (but to be fair it’s still relatively new/early for us!)

I’m curious to know how else folks are doing it.

11

@sthich that’s the clearest description of the shape anyone has put up here, and four charge types with three bases each is roughly where I landed as well. The one I keep going back and forth on is discounts. An early payment discount isn’t really a charge, it’s a reduction in what you owe, and spreading it by weight would be nonsense. Value or unit only, I think.

@Steve_TopNewYork the accrual point is the one I hadn’t taken seriously enough. Estimate at receipt, true it up when the invoice lands, keep the variance where someone can see it. That is ordinary accounting and I had been treating it as an edge case, which is a bit embarrassing now that three people have said it independently.

@Custom-Cursor you and Steve arrived at the same answer on sold units without talking to each other, which settles it for me. Leave them alone. Push the difference into what is still on the shelf.

Nobody has touched the messy one though, so I’ll ask once more and then let it go. Deposit paid in June, balance in August, credit note in September against the same shipment, and by the time the credit note arrives half the goods are sold. Does anyone genuinely keep that straight month to month? Or is the honest answer that you let it drift and fix it at year end with your accountant?

I suspect it’s the second. I’d rather hear that than a tidy method nobody actually follows.

12

Full disclosure: I’m building an inventory app, so this is the exact problem I’ve been working on. The gap I keep seeing is that most tools treat landed cost as a per-SKU field (freight spread over units), but the actual number most importers care about is PO-level: line total + freight + duty − early-payment discount, then allocated across the PO’s SKUs.

That’s the part that disappears when you leave Stocky — the CSV export gives you cost per item, but the freight/duty/PO-level math is gone. What I’m building keeps the PO as the unit of truth: enter the PO, it allocates freight and duty across lines (by value or by quantity, configurable per shipment), and pushes the landed cost per unit back to the variant.

Early version details are on the landing page: https://h3-inventory-ops.vercel.app — curious whether the per-PO allocation matches how you’d actually want to do it.

13

There’s a layer before the allocation method question that’s worth separating out: the cost numbers you’re allocating with.

Stocky’s standard CSV export gives you the current cost per product at time of export — one number, one moment. The per-order cost history (what you actually paid that supplier on each delivery) lives in purchase_item.supplier_cost_price in the API, not in the CSV. If your supplier knocked the unit price 8% on an order last November and it went back up in March, that record is in the API and nowhere else.

Same for received_at. The CSV gives you the PO order date. The actual date each line was received — what you need to compute real lead times — is in the API at the purchase item level.

Those two fields are on the hard deadline. Once the API goes down on Aug 31, there’s no reconstruction path. Whatever allocation method you build into a new tool, it’ll be working from a single blended cost if you haven’t pulled the delivery-level history first.

On your four questions, I think the most useful thing others here have said is the accrual point: estimate at receipt, true it up when the freight invoice lands, record the variance. That’s the setup that makes the “half already sold” question answerable — you’re not restating, you’re adjusting forward. The sold units stay as they were; the variance flows into remaining stock and shows as a line item. That’s standard, but it requires the tool to understand that a cost is provisional vs. confirmed — otherwise it collapses both into the same field and you lose the signal in six months.

I’m working on this specifically for the pre-migration layer — pulling the cost trail and received dates out of the Stocky API before shutdown, browser-only, one-time fee. Link’s on my profile if that’s the part you need covered first.

14

For us, the cleanest approach is to treat this as landed cost, rather than changing the original product cost manually.

Freight: Allocate based on product value when the freight is primarily related to the shipment value, unit count only make sense when the freight is genuinely per-unit.

Late invoices: Record the additional cost against the inventory received, even if some units have already sold. The accounting treatment should determine whether the adjustment affects COGS or remaining inventory.

Already sold stock: I wouldn’t manually rewrite historical Shopify costs every time. Keep the adjustment traceable in the accounting/inventory records.

Multiple supplier invoices: Track each invoice separately against the PO, including deposit, balance, payment date and amount. A spreadsheet can work well if it maintains a proper PO → invoice → payment relationship.

The important part is having an audit trail for the original cost, additional landed costs and any adjustments. Otherwise, margin figures can look accurate while being materially off.