The SKU Collision Problem: Why Your Inventory Spreadsheet Loses Track of Duplicate Items (And How to Fix It)

A SKU collision happens when two different physical items end up sharing the same identifier in your spreadsheet — usually because your numbering system relies on something that repeats, like a brand abbreviation plus a size, or a sequential number you reset each month. The fix is a permanent, non-reused SKU format tied to intake order, not to item attributes, paired with a lookup system that flags duplicates before you list.

Here's how it usually starts. You're at 40 items a month and you build a SKU like NIKE-L-001. Simple, readable, works fine. By month six you've got three Nike large hoodies, two Nike large jackets, and your "001" counter has looped back around because you reset it each January. Now you've got two rows in your spreadsheet both labeled NIKE-L-001 — one sold in March, one is sitting in a bin right now — and you don't know which is which until you physically dig through inventory.

That's not a spreadsheet failure. Spreadsheets do exactly what you tell them. It's a numbering system failure, and it scales badly. At 50 items a month it's an annoyance. At 500, it's the reason your reconciliation takes four hours instead of forty minutes, and the reason you accidentally listed the same physical hoodie on eBay and Poshmark under two different SKUs — creating a real duplicate-listing risk if both sell before you can cancel one.

Why descriptive SKUs collide as you scale

Most resellers start with a descriptive SKU because it's easy to read at a glance: brand, category, size, sequence. The problem is every one of those fields is a repeating value. Brand repeats. Size repeats. Category repeats. The only field doing real uniqueness work is the sequence number — and if that number isn't globally unique and permanent, the whole system breaks.

Common ways sequence numbers stop being unique:

• Resetting the counter every month or year (