The Inventory Cost That Corrects Itself

The situation

ShipHero does not calculate a weighted average cost. When new stock arrives at a different price, it simply overwrites the cost on every unit already in the warehouse, including the ones bought months ago at a completely different price. That single behavior quietly corrupts margin reporting, inventory valuation, and anything downstream that depends on knowing what stock actually cost. Across 14,000 SKUs, nobody was going to correct that by hand, and there was no built-in setting to turn it off.

What we built

A costing layer that sits between receiving and the books. Every time stock is received, the system blends the price of the new units with the cost of the units already on hand, writes the corrected figure back into ShipHero, and records the whole calculation in a ledger the client can open and read. The warehouse team keeps working exactly as before. The cost number just stops being wrong.

How it works

1. 01Stock is received against a purchase order and ShipHero fires an update. The system checks it is genuinely a receiving event and ignores everything else, so ordinary order edits never touch costing.
2. 02The price actually paid for the incoming units is retrieved, then blended with what is already on hand: (old quantity x old cost + received quantity x new price) divided by the new total quantity.
3. 03The corrected cost is written straight back onto the product in ShipHero, so every report and export downstream picks it up automatically.
4. 04Each receipt is appended to a running ledger holding the cost basis, on-hand quantity, and receiving history for that SKU, giving the client a plain-language audit trail for every figure the system produced.

The challenges we solved

• The incoming notification did not include the price paid, only that a receipt had happened. The system had to go back and fetch the landed price for each event before it could calculate anything.
• The same notification can arrive more than once. Without protection, a duplicate would count the same stock twice and skew the cost. A separate memory of each purchase order line means repeat deliveries resolve to zero newly received units and are safely ignored.
• On a 3PL account, every write has to be scoped to the correct customer account, or a corrected cost lands on the wrong client's books entirely.
• Getting the math wrong at scale is worse than not automating at all. The system was first deployed in a safe mode that logged every calculation without changing anything live, then validated on controlled test SKUs (a $2 receipt and a $4 receipt correctly producing a $3.00 average) before live writes were switched on.

The result

Inventory cost now updates itself the moment stock is received, across a catalog of roughly 14,000 SKUs, with a readable ledger row behind every number. The client stopped choosing between accurate accounting and a warehouse that can actually receive stock.