POS and online inventory out of sync: diagnosing the omnichannel stock mismatch nobody notices until a refund

A customer walks into your store on Saturday afternoon and buys the last of a popular item. Ninety seconds later, someone three states away buys the same item online. Your POS knows it's gone. Your website doesn't, not yet, and maybe not for another twenty minutes. Now you have one sweater and two paid orders, and someone is getting a refund email instead of a package.

Why this is a different bug from a normal oversell

Most inventory sync problems that get written about are purely digital: a variant mapping breaks, a webhook drops, two sales channels fight over the same stock count. That's a real issue, and we've covered the mechanics of overselling out-of-stock variants elsewhere.

The brick-and-mortar-plus-online version is quieter and, in some ways, more structural. It isn't a bug in the sense of broken code. It's a lag built into how point-of-sale systems talk to online storefronts. A POS sale has to travel from the register, through the POS software's backend, across an integration or API, into your ecommerce platform, and finally update the number shown on your product page. Every one of those hops takes time, and during that window your online store is quoting stock that no longer exists.

For a pure ecommerce business, inventory is one system of record. For a store with a physical location, inventory has two front doors and one back room, and the door that updates slower is the one that burns you.

How the sync gap actually forms

If you use Shopify POS, in-store sales typically update Shopify's central inventory in near real time, since POS and online share the same inventory ledger on that platform. The gap usually shows up elsewhere: when a third-party POS system (common in WooCommerce and BigCommerce setups) talks to your store through a periodic sync or a webhook that depends on an app being online and responsive. Some integrations poll every few minutes. Others push updates instantly but silently fail if the app's connection drops, your store hits an API rate limit, or a plugin update changes a field mapping.

The practical effect is the same regardless of platform: there's a window, sometimes seconds, sometimes much longer, during which your online stock count is stale. For a slow-moving SKU, nobody notices. For the one sweater left in a popular size, that window is exactly when a customer three states away clicks 'add to cart.'

This is also why the problem tends to hide well. It doesn't produce an error message. Your site isn't down. Checkout works fine. The transaction simply succeeds for an item that no longer exists, and you find out when fulfillment can't find the product on the shelf.

Where to look first: the shapes this problem takes

A few patterns are worth checking specifically, because they point to different root causes.

In-store sales not reflecting online within minutes. If you sell something at the register and the online listing still shows it in stock twenty minutes later, your POS integration is on a polling schedule rather than a push. Shopify's own documentation on POS and inventory notes that sync behavior can vary by app and connection type, so it's worth confirming your specific setup rather than assuming real-time behavior.

Overselling concentrated on a handful of SKUs. If the same few products keep generating 'sorry, that's actually out of stock' refunds, those are almost certainly your lowest-stock, highest-velocity items, the ones where even a short sync delay is long enough for a double sale to occur.

Mismatches that appear right after an app update or POS software update. Integration field mappings and webhook configurations are exactly the kind of thing that silently breaks during an update, since the people pushing the update are rarely testing your specific store setup.

Discrepancies that only show up at specific times of day. If mismatches cluster around your store's busiest in-person hours, that's a volume problem: your sync mechanism can keep up with ordinary traffic but falls behind during a rush, similar to how a storefront can hold up fine until a traffic spike exposes a capacity limit nobody had tested.

A diagnostic routine you can run without a developer

You don't need to audit your integration's source code to find this problem. You need a controlled test and a pattern of observation.

First, run a timed test. Pick a slow-moving SKU with at least two or three units in stock. Sell one at the register and immediately start a stopwatch. Refresh the online product page every thirty seconds and note when the count updates. Do this at a quiet time so you're not fighting real customer activity. This gives you an actual number, your sync lag in minutes, rather than a guess.

Second, pull your refund history and filter for 'unavailable,' 'out of stock,' or 'can't fulfill' as the stated reason. If these cluster on a short list of products, cross-reference those products against your POS sales log for the same window. A pattern of POS sales immediately preceding online oversells on the same SKU is close to a smoking gun.

Third, check your low-stock threshold settings. Many stores set a buffer, for example treating anything under three units as 'low stock' and either reducing visibility or adding a note. If your buffer is set to zero, you have no cushion for the sync gap at all, and the entire burden falls on the integration being fast.

Fourth, treat inventory discrepancy monitoring as an ongoing check, not a one-time audit. A single test tells you your sync lag today, under today's traffic, on today's app versions. It won't tell you if a POS software update next month quietly changes that behavior. This is conceptually the same problem addressed in our broader look at inventory counts that drift across channels, and the fix is the same instinct: check the number your customer sees against the number that's actually true, regularly and automatically, rather than trusting that it stays accurate because it was accurate once.

What to do once you've found the gap

If your timed test shows a lag of more than a minute or two on a system that's supposed to be real-time, that's worth a support ticket with your POS or integration provider. A consistently slow sync on a platform that advertises instant updates usually means a configuration issue, a webhook that's retrying silently, or an app hitting rate limits during busy periods.

If the lag is structural (a polling interval built into the integration), you have two practical levers: shorten the polling interval if your provider allows it, or build in a stock buffer for your fastest-moving, lowest-count items so a short delay doesn't translate into an oversold order. A buffer of even one or two units on your top sellers absorbs most of the risk without meaningfully affecting your sell-through.

Either way, oversells that originate from POS timing look identical to a customer as any other 'we're sorry, this item is unavailable' email. The fix for the customer relationship is the same regardless of cause: a fast, honest refund and, where possible, a substitution offer. Our piece on return and refund workflows covers how to handle that moment well once it's already happened.

This is also the kind of issue that benefits from an outside set of eyes on your storefront. Cassian™ checks stock levels and flags discrepancies as part of its continuous monitoring, alongside order flow, pricing, and uptime, feeding into the overall Cassian Score™ for your store. It won't tell you why your POS integration is slow, but it will tell you when your online stock count and your actual sellable inventory have drifted apart, which is usually the first clue worth having.

The quiet cost of getting this wrong

None of this shows up as a dramatic failure. Your site stays up, checkout works, and the only signal is a slow accumulation of refund emails and a little erosion of trust with customers who ordered something they genuinely couldn't have. That makes it exactly the kind of problem that's easy to deprioritize and expensive to ignore.

A brick-and-mortar-plus-online business carries a structural advantage, local presence, same-day pickup, a real relationship with walk-in customers, but it also carries a structural risk that pure online stores don't: two front doors to the same inventory. Knowing your sync lag, setting a sensible buffer on your riskiest SKUs, and keeping an eye on the gap between what your POS knows and what your website shows is the difference between an occasional apology and a recurring one.