Landed Cost per SKU When Freight Changes Every Shipment

It was the last few minutes of a call in September 2025. Her colleague had someone arriving at 2:30, she had to reach FedEx before the last pickup, and I asked if she had any other questions. She said hers wasn’t going to get answered right away. Then she asked it anyway: “I bought this [item] for $15 and paid 5 in freight and tariff. But I also bought the same [item] the next week and only paid 3.” She runs operations at an importer with goods coming by air and by ocean, on tariff rates that kept moving, and she wanted to follow the true cost of that item until the day it sold.

That is two real costs, $20 and $18, for one SKU on one shelf. Landed cost belongs to the receipt, not to the SKU, and most of what goes wrong with it comes from keeping it in a place that only has room for one number.

I answered a different question. I told her our landed cost worked but wasn’t ideal, because freight went on the purchase order under the same supplier as the goods, so it reached QuickBooks under the wrong vendor, and I’d been changing the vendor in QuickBooks by hand. We’d started fixing that a few days earlier. All of it was true, and none of it had anything to do with her $20 and her $18.

So she came at it from the other side. If she received two products on one shipment, that was “two different products, two different weights, two different values.” I said, “Based on value.” She told me they had a spreadsheet that took the total weight of the shipment and divided it by each product’s weight. “It’s not perfect, but it’s all we have for now.” I said I thought the default was by cost, that I’d have to verify whether weight was even an option, and that I didn’t know “how important the proration method is.”

It is about the most important setting there is, and she was the one who knew it. Carriers bill on weight or on cube, so if you split that bill by value, the small expensive product pays the freight of the big cheap one beside it, and you end up reading the margin on both wrong for as long as they sell. Her spreadsheet had the right method in it. SKU.io now has an Allocate by choice on the bill, by cost, weight, volume or quantity, and you can set it per kind of charge, so one broker invoice can split its freight by volume and its duty by each line’s estimated duty. Weight and volume only work if the products have them on file.

Her real question took longer. The item has both costs, one per receipt. Each receipt becomes its own layer of stock at what it landed for, a sale takes the oldest layer first, and so the order that ships a $20 unit carries $20 and the next one, further down the shelf, carries $18. Shopify can’t hold that. Cost per item is one field, and it gets read at the time of sale. If you turn on Cost Sync we push the average into it, so with both layers on hand Shopify shows something between $18 and $20, while the profit on each order inside SKU.io uses the layer.

By March 2026 she was moving over and we were on opening stock, and she asked it again in a smaller form: “Yeah, but what if we have different landed costs?” For the past, there’s no answer worth paying for. I told them to give us a blended average, because quantity times average cost has to match the books on the day you start, and nothing before that day was ever kept per receipt.

Then in May she brought me one I handled badly. A vendor was paying the shipping and was going to bill them for it later. She had the goods in the building, no landed cost, and wouldn’t have one for another week or two, and she wanted some way to be reminded “instead of putting like a sticky note.” I said that was probably a job for a task manager, like Asana. She said she had her own Claude reminder for it and had just been wondering. I moved us on to vendor deposits.

That was the wrong answer, because what she had wasn’t a to-do problem. For those two weeks anything she sold left at a cost that was too low, and a reminder wouldn’t have changed that. You can add a bill to a received purchase order whenever it turns up, and SKU.io revalues the layers and trues up the units that already shipped, and I’ve written about when that restating should stop, but it doesn’t help anyone looking at margin in the meantime. What does help shipped in October. You can book an estimate at receipt, so it sits in the layer and in an accrued landed cost account, and the real bill clears it and only the difference moves. An estimate with no bill after 90 days raises a warning on the month-end close. If no bill is ever coming, you click No more landed cost expected, or it releases itself 120 days after the last receipt. Older accounts have to turn this on, and it only knows about receipts you gave it an estimate for. Give it nothing and you’re back to the sticky note.

In July she mentioned that she’d added a SKU to a purchase order after the landed cost was allocated, and the cost didn’t reach it. I told her I thought we’d fixed that. “Yeah, yeah, yeah, yeah. But the idea is the same. Like if you do something afterward, it doesn’t know to rejigger it around.” We had just watched the same thing happen on a different screen. The bill comes after the receipt, the sale comes before the bill, the SKU comes after the allocation. That sentence of hers is a better description of this problem than anything I said on four calls.

If you add a line after a bill is allocated, look at that line’s landed cost before you trust it.

If you buy a few times a year, one row per receipt in a spreadsheet will do, and you don’t need us. If the same SKU comes by air and by ocean, book a demo and bring two bills for it.