Why your physical inventory count overstates every product you assemble

The first full physical count I ran on an assembled catalog took two days and produced a variance report I didn't trust. Hundreds of SKUs came back showing a surplus. Not a shortfall — a surplus, on products I knew we'd been selling hard all quarter.

I spent half a day convinced the warehouse had found a hidden pallet somewhere. It hadn't. The count was double-counting, and the cause was baked into the way we make the product.

This is a specific problem for a specific kind of operator. If you sell what you buy, untouched, you can skip this one. If you turn a blank into a finished thing before it ships (printed, engraved, embroidered, bundled into a kit), read on. Your count is almost certainly overstating your components, and counting harder won't fix it.

Where the stock actually lives

Take a blank ceramic mug. You buy it as a component. Say you have 100 of them on the shelf.

An order comes in for a personalized mug. Your system raises a build (Cin7 Core calls it a finished goods assembly) that consumes one blank and produces one finished SKU: the printed mug, ready to ship. Do that 30 times and the system now reads 70 blanks on hand and 30 finished mugs on hand.

The 30 finished mugs haven't shipped yet. They're sitting on a shelf in your building, printed and boxed, waiting for the courier. Physically, you still have 100 mugs' worth of ceramic in the room. Cin7 has split them: 70 counted as blanks, 30 counted as finished goods.

Now send a counter down the aisle. They see mugs. Blanks in one bay, printed ones in another, all of them mugs. If the count sheet says "blank mug" and they tally everything mug-shaped, they write 100. The system says 70. That 30-unit variance isn't real. The 30 units exist, but they've already been counted one shelf over.

The number you should be counting against

The variance is fake because the target is wrong. You're comparing a physical count to the component's bare on-hand figure. On count day the right expected quantity for that component is bigger than its on-hand. You have to add back every unit of it locked inside finished goods that haven't left the building.

Expected component qty = on-hand + child stock exploded back through the bill of materials

For the mug: 70 on hand, plus 30 finished mugs each holding one blank, equals 100 expected. Count 100, match 100, no variance. The ghost disappears the moment you count against the right number.

Now multiply the mistake across a catalog. Every component that feeds a finished good carries this gap, and the gap is as wide as your unshipped finished-goods pile. During a busy stretch (the week before a holiday, a backlog of personalized orders waiting on a print run), that pile is at its biggest. That is also exactly when most people schedule a count. So you get a variance report that's mostly noise, and the noise is the dangerous part. It buries the few variances that are real: the genuine miscounts and shrinkage you called the count to find.

Counting harder makes it worse

The instinct is to tighten the count. Separate the bays. Tell counters to skip anything already printed, and count blanks as blanks.

That swaps one error for another. Now you've undercounted: the 30 blanks living inside finished goods vanish from the component tally, so the component reads 70 when the truth on the floor is 100. You've made the report agree with the system by hiding stock, which defeats the reason you count at all. A count exists to find the gap between the system and reality. You can't find it by teaching the count to look away from reality.

The clean answer is to count what's physically in front of you and compare it to a number that already knows about your builds. That means exploding the bill of materials at count time: take every finished and part-finished unit, break it back down into the components it consumed, and add those components into the expected figure. Do that, and a counter can sweep a whole aisle, blanks and printed units together, and the math still reconciles.

The rest of count day, briefly

The bill-of-materials trap is the one nobody warns you about. A few smaller habits separate a count that takes a morning from one that eats a weekend.

Count blind

The counter should not see the system quantity while they count. The moment they do, a tally that's one unit off quietly becomes a tally that matches, because agreeing with the screen is easier than recounting the bay. Hide the expected number until the count is in.

Count by location, not by SKU

The same component lives in three places. If your count is one line per SKU, the third location never gets entered, and you book a shortfall that's really a routing problem. Record the count per location, then add them up.

Recheck the outliers, and only the outliers

A 2-unit gap on a fast mover is rounding. A 40 percent gap is a question. Flag the counts that cross a threshold (set both a percentage and a minimum unit count, so small SKUs don't flood the queue) and recount those alone. One clean recount clears the flag.

Keep the count out of your other numbers

When you push corrections back into Cin7 Core, those adjustments look identical to waste and shrinkage unless you label them. They're the count catching up to the shelf. Book them as waste and you understate your margin and quietly drag your demand history for months.

What to do before your next count

If you assemble, kit, or personalize, do one thing first: size your unshipped finished-goods pile in component terms. Pull your open finished-goods builds, explode them back to components, and you'll have the size of the gap you've been calling variance every count. For most build-to-order operations it is not small.

Then decide how you'll count against the right number. By hand, that's a spreadsheet that walks every open build, looks up its bill of materials, and adds the components back per location, rebuilt fresh for each count. Workable at a few hundred SKUs. Miserable past that.

This is one of the reasons we built the count workflow in Stocura the way we did. It seeds a worksheet for every active SKU and sets the expected quantity as on-hand plus child stock exploded through the bill of materials. Full coverage, including children that never touch Shopify. You count blind, by location, on a phone if you're walking the floor. Variances over your threshold land in a recheck queue. When the numbers look right, it pushes the corrections to Cin7 Core as a draft stock adjustment you can inspect before you commit, and it tags those corrections so they stay out of your shrinkage and forecast figures.

Either way, the expected number is the thing to get right. If you build your product and count it against bare component stock, you will overstate every component by the size of your unshipped builds, and you'll spend count day chasing surpluses that were never there.