The Shopify inventory audit: four layers that catch what counts can't

For one quarter, a coffee roaster's cycle counts came back clean — every variance within a couple of units. Then a wholesale order blew up the week anyway: two product listings splitting the sales history for the same bean, thirty-odd variants with no cost entered, and a forgotten second location still holding 90 bags nobody could sell. The counts certified quantities. Nothing had checked the data, structure, settings, and habits underneath — which is the job of an inventory audit.

This guide runs the audit as four layers of probe questions you can answer from the Shopify admin and one product CSV export. It tells you what to check, what failure looks like, and where the fix lives — it links out to a deeper guide per finding rather than re-teaching any of them.

What an audit is for

Counts find one class of error: the system number versus the shelf number. An audit finds the four classes counts can't touch:

• Bad data — duplicate listings, blank SKUs, missing costs, half-empty barcode fields.
• Broken structure — variant architecture fighting the catalog, statuses nobody set deliberately, collections that drifted, locations that shouldn't exist.
• Wrong settings — per-variant selling policies and tracking flags doing the opposite of what you assume.
• Undocumented process — adjustments with no reasons, receipts entered days late, reconciliation that happens when someone notices.

A store can pass every count and still lose money to all four. The audit surfaces them in an afternoon instead of through a blown weekend — and it produces a ranked fix list, not a vague feeling that the catalog is haunted.

Run one when a trigger fires — a new sales channel, a staff change, a system or theme migration, a new 3PL — and otherwise on the rhythm below. Triggers matter because each one tends to introduce exactly one new class of mess: a marketplace brings data requirements, a new hire brings permission drift, a migration leaves duplicates behind. Auditing after the trigger is cheaper than auditing after the trigger's mistakes compound.

Layer 1: data hygiene

One product CSV export answers most of this layer. Sort it, filter it, and look for five things:

• Duplicate listings. The same title twice, "Copy of" titles, one product recreated each season. Duplicates split sales history and reorder signals down the middle — finding and merging them is its own procedure.
• SKU consistency. Blank SKUs, exact duplicates, and mixed conventions in one column (ABC-123 next to abc 123). The scheme that prevents this is in the SKU naming guide.
• Cost-field accuracy. Blank or zero cost per item, or costs left from two POs ago. Every margin report built on them is quietly wrong — the COGS guide covers what that field feeds.
• Identifier completeness. Which variants actually scan: barcode fields holding real GTINs, versus SKUs pasted in, versus nothing. Setup and workflow live in the barcode inventory guide.
• Metafield sanity. Inventory-adjacent metafields — bin locations, supplier codes — populated in one consistent format. If you can't filter or report by them, they're decoration; the metafields guide shows the setup that survives growth.

Layer 2: structure

• Variant architecture. Products crowding the variant ceiling (the exact limits have shifted over time — the variant limit guide has current numbers), option values doing double duty ("Bundle" posing as a size), or products that should have been separate entries.
• Product statuses. Drafts holding reserved stock, archived products still sitting in automated collections, active sample products staff keep ordering by accident. Status logic is short — audit it anyway.
• Collections as views. Automated collections whose conditions drifted as titles and tags changed, and whether an operational "needs reorder" view exists at all. Collections organization is the reference for rebuilding them as working views.
• Locations. Locations that are inactive but still holding inventory, or that exist because of a 3PL trial two years ago. Multi-location mechanics and cleanup: the multi-location guide.

Layer 3: settings

• Inventory policies. "Continue selling when out of stock" is a per-variant switch with two failure directions: ON where you can't restock (overselling), OFF on things you wanted backorderable (silently lost sales). Scan it variant by variant — the causes, the cost math, and a prevention checklist are in the overselling guide.
• Tracking flags. Variants with quantity tracking switched off — their stock never moves no matter what sells, and no count will flag them because nothing about them looks wrong. What tracking does and doesn't cover: does Shopify track inventory.
• Staff permissions. Who can edit inventory, receive POs, and export data. In a three-person store this is a five-minute check; at ten people it's load-bearing. The permissions guide lists what to restrict first.

Layer 4: process

The first three layers are snapshots. This one checks the habits that keep them true between snapshots:

• Adjustment trails. Pull the last 90 days of inventory adjustments and count how many carry a real reason versus a bare correction. The log is your audit trail — reading and running it.
• Receiving discipline. Are receipts entered the day goods arrive, counted before shelving? Late receipts manufacture phantom stock that no counting cadence fully repairs. The same-day sequence: the receiving checklist.
• Reconciliation habits. A monthly shelf-versus-system pass on top movers, rather than an annual surprise. The reconciliation method fits on one page.
• Counting cadence. A live, calendared cycle-count schedule — or nothing since last January. Counts and cadence for the weekly rhythm, and the annual deep version pairs with the year-end count.

The findings-to-fixes table

Run the probes, then map what you found. Each row is a symptom you'll actually see, the layer that owns it, and the guide that fixes it:

Mark each probe pass, fix-soon, or broken. An audit that finds twelve failures isn't a project plan — rank by daily pain. A setting that oversells beats a naming inconsistency; a naming inconsistency beats a cosmetic collection reorg.

The audit rhythm

Quarterly, light: layers 1 and 3 from one CSV export and a settings scan — about an hour once you know where to look. A workable sequence for that hour: export the CSV, sort titles for duplicates, scan the SKU and cost columns for blanks, open the inventory settings page and review continue-selling variants, then eyeball the last month of adjustments. Annually, deep: all four layers, timed with your year-end physical count so the data fixes and the fresh baseline land together. The pairing matters — repairing data the same week as the full count means the new baseline starts clean instead of inheriting known defects.

InventoryX sits closest to layer 4: it reads your catalog and inventory data, watches between counts, and flags which SKUs are going dark and what that cost in estimated revenue. It won't merge your duplicates or fix your settings — that's what the table above is for.

Common questions

How often should I audit Shopify inventory? Quarterly for the light version — data hygiene and settings, about an hour from one CSV export — and annually for the deep pass across all four layers, timed with your year-end count. Run an extra audit after any migration, staff change, or new sales channel, since each tends to introduce exactly one new class of mess.

What's the difference between an inventory audit and a count? A count compares system quantity to shelf quantity for a set of SKUs on a given day. An audit checks the four things counts never see: data quality, catalog structure, per-variant settings, and process habits. Counts are themselves a layer-4 habit the audit verifies — the two don't substitute for each other.

What do I need to run this audit? Admin access and one product CSV export cover layers 1 through 3; layer 4 needs your adjustment history and a candid look at how receiving actually happens. The first pass takes an afternoon at a few hundred SKUs; the quarterly light version drops to about an hour once the fixes are in.

Which layer breaks most often? Data hygiene, in stores that grew fast — duplicates from seasonal re-creation and blank cost fields are the usual finds. Settings errors are rarer but sharper: a single continue-selling switch flipped on the wrong variant can oversell within days. Rank what you find by daily pain, not by how many items each layer produced.

Should I fix everything the audit finds? No — triage. Fix settings errors and anything overselling immediately, merge duplicates and fill costs the same week, and schedule structural work like naming schemes and collection logic for a quiet week. A twenty-finding list ranked by pain is a working plan; the same list unranked is a guilt document.

Next step

Export the product CSV today and run the layer-1 probes: sort by title to catch duplicates, then scan the SKU and cost columns for blanks. Put the quarterly hour on the calendar before you close the spreadsheet — the audit only compounds if it repeats, and layer 1 is the one where an hour of fixes buys back the most report accuracy. For the identifier layer specifically — SKU vs UPC vs GTIN vs barcode — the identifier taxonomy is its own guide.