True Landed Cost Per SKU (And Why Most Cannot)

Here is a question that should take 10 seconds to answer: "Is this product making us money?"

For most manufacturers running 200 or more SKUs, the honest answer is "I think so." They know the company is profitable. They can see it in the bank account. But whether the 6-seater dining table is more profitable than the bookshelf? Whether the console table is quietly losing money once you factor in rejection rates and rework? That is a different question. And most operations cannot answer it.

The reason is not laziness. The data exists. It is just scattered across too many places to connect.

What goes into a true landed cost

The landed cost of a SKU is not just material plus labor. It is every cost that touches that product from the moment raw material enters your warehouse to the moment the finished product ships to the buyer.

For a furniture manufacturer with 20+ components per SKU, the full cost stack looks like this:

Wood cost per component. The dining table has 22 components. Each component uses a different wood species at different dimensions. The table top uses 2.5 cubic feet of mango. The four legs use 1.8 cubic feet of sheesham each. The frame uses 1.2 cubic feet of teak. Each species has a different running rate, and that rate changes with every receipt.

Contractor cost per production stage. Machining contractor gets $X per piece. Assembly contractor gets $Y. Sanding, finishing, hardware installation, packing: each stage has its own contractor at its own rate. And those rates sometimes vary by SKU complexity.

Rejection cost. 600 pieces entered sanding. 580 came out. Those 20 pieces represent wood already consumed, machining already paid for, and assembly already completed. That cost does not disappear. It gets absorbed somewhere. Without SKU-level tracking, it gets absorbed invisibly.

Rework cost. 15 pieces failed QC at finishing. They go back to the finishing contractor for rework. Sometimes the rework is free (contractor's fault). Sometimes it is not. Either way, the rework adds time and potentially cost to that SKU.

Overhead allocation. Warehouse storage, equipment depreciation, quality team salaries, logistics for inter-facility movement. These are typically allocated per SKU based on production volume or floor time.

Why most systems cannot do this

The math is straightforward. The data collection is the problem.

In a typical manufacturing operation, wood issuance is logged in the storekeeper's register. Contractor costs are reconciled monthly from handwritten logs. Rejection counts are noted in the QC inspector's notebook. Rework events might not be tracked at all. Overhead is spread across the P&L.

To calculate landed cost per SKU, someone would need to manually pull all of these numbers, match them to specific production runs, and aggregate them per SKU. For 200+ SKUs, that is a full-time job. So nobody does it.

Even in operations running Epicor or Plex, the data often lives in separate modules that do not connect at the SKU level. The procurement module tracks material cost. The production module tracks labor hours. The quality module tracks rejections. But tying them all to one SKU, one production run, one specific job order? That requires custom reports that somebody has to build and maintain.

How event-driven architecture solves this

In SimpleGrid, every action is an event. Every event is tagged with the entities it belongs to.

When the storekeeper issues 2.5 cubic feet of mango wood to the table top component of Job Order JO-1187, that event carries: the wood species, the quantity in cubic feet, the current running rate, the component it was issued to, the SKU it belongs to, and the Job Order it is part of.

When the machining contractor completes 400 table tops and gets paid at $3.20 per piece, that event carries: the contractor, the rate, the quantity, the component, the SKU, the Job Order.

When QC rejects 12 pieces at the finishing stage, that event carries: the rejection count, the stage, the root cause, the SKU, the accumulated cost of those 12 pieces up to that point.

Each event adds to the cost stack. By the time the finished product ships, the system knows exactly what it cost to produce, broken down by:

- Wood cost (per component, per species)

- Contractor cost (per stage)

- Rejection cost (accumulated wasted input cost)

- Rework cost (if applicable)

Compare that to the buyer's price. SKU-level margin. For every product, on every order, in real time.

What this changes

Before: the founder knew the company was profitable. He could see it in the P&L. But he was producing 550 SKUs and had no way to know which ones contributed to that profit and which ones eroded it.

After: for the first time, he could sort his product catalog by margin. The top 50 SKUs by volume were not the top 50 by profitability. Some high-volume SKUs had thin margins because of high rejection rates at specific production stages. Some low-volume SKUs were highly profitable because they used cheaper wood species with simpler component structures.

That is not a dashboard upgrade. That is a different way of running the business.

The practical takeaway

If you cannot answer "what does this SKU actually cost to produce?" within 30 seconds, you are making pricing, production planning, and customer negotiation decisions based on estimates. You might be right most of the time. But the 10% of the time you are wrong, you are losing money without knowing it.

The solution is not better accounting. It is better data capture. When every cost-generating event is tagged with the SKU it belongs to, profitability is not a calculation someone has to build. It is a natural consequence of how the system records work.

SimpleGrid attaches every cost to the SKU it belongs to. Wood, labor, rejection, rework. Real margins. Real decisions.