Inventory reconciliation with cycle counts: keeping the shelf, the storefront, and the books in agreement

Open QuickBooks and Shopify side by side and the inventory counts just… don't match. Orders are syncing fine. Both systems look right on their own. They still disagree. That exact scene gets posted over and over — one seller in r/smallbusiness put it plainly: "Even when orders are syncing correctly, inventory quantities still do not match between Shopify and QuickBooks. It does not seem random." The usual reply is "pick a single source of truth." That's half right — and the missing half is the half that actually costs you money. A source of truth only makes every system agree on one number. It does nothing to make that number match what's on the shelf. Here is how to fix both: the counting that makes the number true, and the sync that makes the systems agree.

You have two problems, not one

The complaint "my inventory doesn't reconcile" is almost always two separate failures stacked on top of each other. The first is system-to-shelf: does the number in your source of truth match the units physically sitting in the warehouse? The second is system-to-system: do Shopify, your ERP, and your 3PL all show the same number? These have different causes and different fixes, and collapsing them is why the problem never fully goes away. Fix the sync and the systems agree — on a number that's still wrong. Fix the shelf in one system and the others keep showing the old figure. You have to do both, in that order: make it true, then make it agree.

Most advice only ever names the second problem. A commenter in r/FulfillmentByAmazon gave the standard answer: "you need a single source of truth for inventory, not three systems arguing about who's right." That's good advice for the agreement problem. But naming one system the winner doesn't make the winner correct — it just means everyone now trusts the same number, right or wrong. The physical shelf is the only real source of truth, and no software knows what's on it until someone counts.

Why the number drifts away from the shelf

Inventory records don't stay right on their own, even in a well-run warehouse. Every system starts from a count and then tracks changes — sales out, receipts in — but a whole category of events changes the shelf without ever touching the record. This isn't rare. In one widely cited study, DeHoratius and Raman examined nearly 370,000 inventory records across 37 stores and found 65% of them inaccurate. The record and the shelf disagree by default; keeping them together is active work, not a resting state.

You can watch it happen in the threads. A seller in r/AmazonSeller noticed "the number of orders I received doesn't match with inventory" — units vanishing between what was sent and what sold — and a replying seller confirmed the same: "Had 4 books go missing in the last day. 6 this week!" That's shrink, and it's only one of the ways the shelf walks away from the record.

A commenter on that QuickBooks-vs-Shopify thread landed on the same list from the software side: the mismatches, they said, aren't just sales failing to sync but "returns/refunds + location transfers + bundles" creating phantom quantities. Same drift, two vantage points. The point is that none of these error out. The record looks clean. It's just no longer true.

The formula for how far the record has drifted is simple, and it's worth internalizing because it's also the definition of shrink. Per Shopify's own guidance, inventory shrinkage equals recorded inventory minus actual inventory. If your system says 100 and the shelf holds 96, you have four units of shrink — and until someone counts, you don't know it exists.

The once-a-year physical count is the wrong tool

The instinct is to fix drift with a full physical count: stop everything, count all of it, reset the numbers. It works, briefly. But a full count means shutting the warehouse (or counting through a weekend), it happens once or twice a year, and by February the number you reset in January is wrong again. Worse, it tells you the total drift without telling you which SKUs drifted or when, so you learn nothing about the cause. It's a reset, not a control.

And the manual version of "just recount it" quietly eats the team. A write-up interviewing 40-plus Shopify warehouse merchants (fair warning — it was pitching a tool) named the top pain not as overselling but as "The Monday morning reconciliation ritual" of manual recounts: "I went into this thinking the biggest inventory problem would be overselling. It's not." Treat that as one person's framing rather than a statistic, but the shape is familiar to anyone who's done it: recounting everything, all the time, by hand, and still not trusting the number.

Cycle counting: count a slice, on a schedule, without stopping

The tool built for this is the cycle count. Instead of counting everything at once, you count a small subset of SKUs on a rotating schedule while the warehouse keeps running — a perpetual auditing procedure that counts a specific subset in a continuous, repeated sequence. Over a quarter you cover everything, but on any given day you're only counting a handful of bins. No shutdown, and because counts happen constantly, drift gets caught in days instead of at year-end. Shopify and NetSuite both document the practice; the mechanics below are the same regardless of which system you run.

The question is which SKUs to count how often. Counting everything equally wastes effort on the slow movers and under-counts the ones that matter. The standard answer is ABC analysis: rank SKUs by annual value (unit cost × units sold) and count the high-value ones most. It's the Pareto pattern applied to inventory — a small share of your SKUs drives most of your value, so they earn the most attention.

How to run a count and post the variance

The procedure below is deliberately mechanical. The whole value of a cycle count is that it's repeatable and boring, so it should read that way.

1. Pull today's count list from the schedule — the SKUs and locations due based on their ABC class.
2. Count blind: give the counter the SKU and bin, not the expected quantity. Seeing the system number first is how a count turns into a confirmation instead of a check.
3. Record the physical quantity per SKU per location, then compare it to the system quantity to get the variance.
4. Apply a variance threshold. Small, in-tolerance differences (often ±1–2 units or a small percentage on high-count SKUs) get posted and moved on; anything past the threshold gets investigated before you adjust.
5. Investigate the exceptions: was it a mis-pick, an unposted transfer, a receiving error, a return to the wrong SKU, or genuine shrink? The cause determines whether a process needs fixing, not just a number.
6. Post the adjustment in your source of truth with a reason code, not a silent overwrite — Shopify, for instance, lets you add a reason to every inventory adjustment so the change is explainable later.
7. Log the accuracy result so you can trend it over time (next section).

Per-count math (one SKU at one location)
----------------------------------------
system_qty    = quantity the record shows        e.g. 100
physical_qty  = quantity actually counted        e.g.  96
variance      = physical_qty - system_qty        =    -4   (4 units of shrink)
abs_var_pct   = |variance| / system_qty * 100    =     4.0%

Inventory Record Accuracy for the count batch
---------------------------------------------
IRA = (# SKUs within tolerance / # SKUs counted) * 100
  e.g. 47 of 50 SKUs matched within tolerance -> 94.0%

Shrinkage (value, over a period)
--------------------------------
shrinkage = recorded_inventory - actual_inventory   (Shopify's definition)

What's a good accuracy number? Most operations target inventory record accuracy of 97 to 98 percent or higher — meaning the large majority of counted SKUs land within tolerance. The exact target matters less than the trend: if your weekly IRA is climbing, your process is working; if it's flat and low, you have a systemic cause (a bad receiving step, an unreliable integration) that counting alone won't fix.

Now reconcile the systems to each other

Once your source of truth matches the shelf, the second reconciliation is the mechanical one you already know how to do: prove the other systems agree, and fix the ones that don't. Match every SKU across systems on a stable primary ID — the SKU or a shared product code, not the display name — and list the differences. In a spreadsheet that's the exact COUNTIF / MATCH set-difference move: SKUs present in one system and missing in the other, and SKUs present in both whose quantities differ.

When the systems disagree even after the shelf is right, the causes are their own short list. Sync timing lag: a commenter noted the "zapier-in-the-middle setup breaks specifically during high volume" because scheduled polling can't keep up when orders come in fast. Logic that isn't mirrored: another put it as "most mismatches I've seen come from inventory logic not being mirrored, not just sync delays" — bundles decremented in one system but not the other, multi-location totals that don't roll up the same way. As one commenter shrugged, "Shopify and QuickBooks were actually never meant to hold hands." They don't have to be friends; they have to agree on a number, and you have to check that they do.

The deeper versions of the cross-system problem have their own guides: overselling when three channels disagree on availability is covered in reconciling inventory across Shopify, Amazon, and your 3PL; orders that never crossed at all (as opposed to quantities that drifted) are the silently dropped records problem; and the storefront-to-ERP field drift specifically is in reconciling Shopify orders against your ERP and where NetSuite's inventory and GL disagree.

Make it a standing routine, not a fire drill

Cycle counting only pays off as a habit. Put the count schedule on the calendar by ABC class, count blind, post with reason codes, and track weekly IRA per class so you can see drift building before it becomes a stockout or an oversell. The reason codes do double duty: they turn every adjustment into an audit trail, which is exactly the kind of evidence covered in what auditors look for in a reconciliation — Shopify keeps a full adjustment history of who changed what and why, and most systems have an equivalent. When two SKUs keep offsetting each other, that's usually a mis-pick or a mislabeled bin, and it's the same detective work as fuzzy matching records: the numbers point you at a cause, not just a correction.

The honest ceiling: a spreadsheet and a disciplined weekly count will hold a small catalog steady for a long time. When you're counting across several locations, reconciling three or more systems every day, or need every adjustment traceable for an audit, the manual version starts to buckle — and that's the point where a dedicated reconciliation layer earns its place. Either way, the discipline is the same: count the shelf, make one system true, then make the rest agree.

← All writing