When the Inventory Says Eight and the Drawer Has Three

Needed eight 10µF electrolytic capacitors for a power supply board. Checked the inventory: twelve. Went to the drawer. Counted three times because the result didn't make sense. Three.

Somewhere between twelve and three, nine capacitors moved from "in the inventory" to "somewhere that isn't the capacitor drawer." Some of them I used on projects and didn't subtract. Some might be in the "misc caps" drawer I haven't opened in months. Some probably went into project bags during builds and didn't make it back. One might have rolled behind the bench storage.

None of this is complicated. None of it is unusual. And none of it is the inventory system's fault — the system has the numbers I gave it, and I gave it wrong numbers, gradually, through dozens of small failures to update.

This is inventory drift: the gradual divergence between what your records say you have and what you actually have. It's the most common failure mode in any component tracking system. Left unaddressed, it grows until the system becomes less useful than just checking the drawer — at which point most people abandon the system entirely and go back to the drawer.

The mechanisms

Drift only goes in one direction: it always reduces your recorded stock relative to your actual stock. That's because usage events (which reduce physical stock) are much more frequent than the updates that record them, and because there's no corresponding event that quietly adds stock to your records without your knowing.

Usage without update is the main mechanism. You grab a handful of resistors for a project, use seven, finish the project, don't update. The resistors are gone but the record still shows them.

Partial bag use compounds this. If you have fifty resistors in a bag and log them as "50," and then use twelve without updating, your count is off by twelve. Over five similar projects, it's off by sixty. Now the "50" in the system corresponds to something negative if you checked.

Attrition happens continuously and invisibly: the capacitor that fell on the floor, the component you were holding when the phone rang that ended up "somewhere," the part you tested and found faulty and discarded. All remove physical stock without creating an inventory event.

Lending compounds everything. Already discussed elsewhere but worth noting: if a component leaves your bench without being logged as lent, it's phantom stock — you can't find it but the inventory says you have it.

What makes drift tolerable vs. what makes it break the system

Not all drift is equally damaging. Some you can absorb; some makes the inventory useless.

High-quantity passives with large safety margins: if you have a hundred 1k resistors and you actually have seventy, the inventory is wrong but the error doesn't matter for decisions. You won't order unnecessarily. You won't run out unexpectedly.

Low-quantity, non-substitutable components: if you have two OLED displays recorded and actually have zero, that's a problem. You'll plan a build based on the assumption that you have displays, reach for them, and find nothing. The error crossed from "slightly inaccurate" to "actively misleading at the moment of decision."

The fix isn't perfect bookkeeping forever. It's prioritising accuracy where errors are most costly. High-value, low-quantity components need more careful tracking and more frequent reconciliation. Commodity passives can absorb more drift before it matters.

Practical reconciliation

There are two approaches to fighting drift, and they work best in combination.

Update at use, not at project end. The friction of a post-project update session is high enough that people skip it. The friction of a mid-session note ("used four 100nF caps") is much lower. A small notebook on the bench for mid-session notes, with a quick inventory update at the end of each session, keeps the counts much more current than the project-level update.

Rolling category reconciliation. Once a month or so, reconcile one category — physically count and compare to the records, correct the numbers. Not all at once; that's overwhelming. One category per reconciliation, rotating through. The counts are never perfectly current, but they're never more than a few weeks stale for any category.

The goal isn't a perfect inventory. It's an inventory you can trust for decisions — one where the count might be slightly off, but "the system says I have it" is a reliable enough signal to avoid unnecessary orders and plan builds with confidence.

That standard is achievable with small, consistent habits. The alternative is waiting until the system has drifted so far that you rebuild it from scratch, which is the expensive version of the same work.