On a Monday morning after a busy weekend, you're scanning the weekend orders and finding three that need to be canceled. Products that sold in the store on Saturday before the website knew the stock was gone. Customers placed orders for items that no longer existed. Your customer service team is already drafting apology emails.
This is the kind of problem real-time inventory sync exists to prevent. Whether you're choosing an integration, upgrading one, or auditing what you already have, this post is a practical guide to what real-time actually means for your store, when it matters most, and how to weigh its value against its price.
The two models, briefly
Batch sync runs on a schedule. Typically every 15 minutes, every hour, or longer between cycles, an integration pulls the current inventory state from your POS and pushes it to Shopify. Between cycles, Shopify shows whatever the last cycle reported, even if your stores have sold through half the units since then.
Real-time sync moves changes as they happen. When something changes in your POS — a sale, a return, a stock count — the integration propagates that change to Shopify within seconds. There's no "between cycles" to worry about, and the website's view of inventory closely tracks the actual shelf.
The interesting question isn't which is better in the abstract. It's which one your business actually needs, and how to tell whether what you have is good enough.
What "real-time" actually means for your store
The technical implementation of real-time sync varies between vendors, and most don't publish those details anyway. What matters is the observable behavior — what you can actually test from the merchant side.
Real-time sync that's worth having shows up in three ways:
Speed. When a transaction happens in the store, the inventory change reaches Shopify within seconds, not minutes. The simplest test: sell a unit at the register and refresh the product page on your website. If the available count drops within seconds, you have real-time sync. If you have to wait, or refresh several times, you don't.
Resilience. When something goes wrong — your integration vendor has a brief outage, your network glitches, Shopify rate-limits a request — what happens to the inventory updates during that gap? Healthy real-time sync queues the updates and delivers them when the system recovers. Weaker sync drops them silently, and you discover the gap days later as drift you can't explain.
Bidirectionality. Real-time sync from POS to Shopify is only half the picture. Sync the other way — Shopify to POS — needs to be just as fast, or your in-store inventory ghosts the online sales. The customer who buys online at 10:01 doesn't show up in the POS until the next sync, and your store team can sell that same unit to a walk-in customer at 10:05.
Vendors who can speak clearly to all three behaviors are usually the ones who've made the engineering investment to back the claim. Vendors who wave the questions away typically deserve the skepticism.
Healthy real-time inventory sync is bidirectional, transaction-driven, and fast enough that the gap between any change and its propagation is measured in seconds, not minutes.
The three jobs of inventory sync
Here's where the binary "real-time vs. batch" framing breaks down. Inventory sync isn't one job — it's at least three, and each has a different right answer.
(a) Operations where batch is the natural primitive. Some inventory operations are inherently batch-shaped, and using real-time would be the wrong fit:
- Catalog updates — adding 1,000 new SKUs or updating prices on 5,000 products at once
- Physical cycle count corrections, where you want to apply the entire count atomically rather than piecemeal as each counter scans each shelf
- Accounting and ERP feeds, where the downstream system wants a daily summary batch rather than a constant firehose of per-transaction entries
- Bulk inter-store transfers, generally tracked as single transfer events rather than per-unit real-time updates
These aren't "batch vs. real-time" decisions. Batch is the right shape for the work.
(b) Operations where batch complements real-time. Even with healthy real-time sync, batch operations have a place — as a backstop:
- Nightly reconciliation passes that compare source system to destination and surface any discrepancies. Even transaction-driven sync occasionally drops updates under load; a 3am reconciliation catches them before they cause oversells.
- End-of-day inventory snapshots for reporting and audit trails. Real-time events flowing constantly don't naturally produce a clean point-in-time record.
A mature integration uses real-time and batch reconciliation together. They're solving different problems.
(c) The stock counts customers see at checkout. This is the omnichannel, BOPIS, and overselling-prevention case — the place where "real-time" actually matters and batch is the wrong tool. When customers can buy the same physical unit through any of several channels, the propagation speed of inventory changes is what separates a healthy operation from a steady stream of cancellations. We cover this case in depth in Real-time inventory accuracy: why BOPIS fails without it.
When batch-only is enough
Even for the stock counts customers see online, there are narrow cases where batch alone is genuinely fine. Specifically:
- Single-channel retailers (just Shopify, no in-store, no marketplaces) where there's no race condition to worry about.
- Pure slow-moving inventory — furniture, custom-order, B2B-only operations where the rate of sale is too low for race conditions to occur in any practical sense.
- Very low transaction velocity, typically under 100 orders per day.
- Single-location stores with no online/in-store inventory sharing.
The trap most retailers fall into is the second one. "We're slow-moving, batch is fine" is a defensible argument only if your inventory is uniformly slow-moving across the entire catalog. The moment you carry any mix of velocities — a furniture retailer with fast-moving accessories, a custom-order shop with a ready-to-buy line, a B2B operation with consumer overflow — batch starts overselling on the fast-moving subset even though it's "fine" for the slow ones. Most retailers who think they're slow-moving actually have bimodal velocity, and a sync model that treats the whole catalog as slow-moving will produce oversells on the fast-moving part.
When real-time is required
For most retailers selling multi-channel, real-time inventory sync isn't optional. The cases that demand it:
- BOPIS — where the entire customer experience depends on accurate per-location stock at checkout
- Multi-channel selling where Shopify, Amazon, eBay, in-store, and social commerce all draw from the same physical inventory
- High-velocity inventory like apparel during peak, popular sneaker drops, or any SKU with regular sell-through above a few units per hour
- Flash sales and product drops where the entire inventory ledger can move in minutes
- Multi-location operations where stores share SKUs with the online channel
- Any retailer with mixed-velocity inventory — the moment some SKUs move quickly, the whole catalog needs real-time
If your operation is in any of these categories, batch sync will produce oversells on the inventory customers see online, and no amount of operational tuning will fix it.
The cost of inaccuracy
Most merchants who switch their POS-to-Shopify integration switch to try to control costs. That's reasonable when two integrations offer the same value. The complication is that the cheaper integration usually produces measurably more cancellations than the more capable one — and the cancellation cost rarely shows up in the comparison.
A few costs worth tallying when you're weighing the real value:
- Customer-service time per cancellation. Apology emails, refund processing, sometimes follow-up calls. Even at 10-15 minutes per incident, that adds up across a month.
- Order-management overhead. Identifying which orders to cancel, communicating with customers, sometimes coordinating a substitution from another store.
- Lost lifetime value. Customers who get a cancellation often don't complain — they just quietly stop coming back. Industry data on customer retention suggests this is usually the largest hidden cost, and the hardest one to put a precise number on.
- Brand impact. The occasional negative review, the social media complaint, the friend who hears about the bad experience. Hard to quantify but real.
- Operational stress at peak periods. Black Friday, holiday season, product drops — exactly when the team should be focused on serving customers is when cancellation work tends to pile up.
A worked example: a retailer taking 100 online orders per day with a 1% oversell rate is producing about 30 cancellations per month, plus all the soft costs that go with them. At a conservative $20 per incident in total cost (customer-service time plus a modest LTV impact plus order-management overhead), that's $600 per month in inaccuracy cost. That's a moderately-sized online operation with a modest oversell rate; the number grows quickly with volume. Online overselling specifically is the failure mode — the in-store POS won't let staff ring up an item that isn't there, but the website can sell a unit that has already left the shelf.
The math doesn't always favor the more capable integration. Some retailers genuinely have low enough velocity, simple enough operations, or well-tuned enough manual processes that the cancellation cost stays small. But for most retailers running multi-channel or multi-location, the cost of overselling is the larger number. The integration price is the visible cost; the cancellation cost is the hidden one. The decision is easier when you compare both.
Every app is an integration
There's an argument made in retail technology circles that integrations between systems are the biggest source of accuracy problems. The argument has merit — poorly-built integrations are exactly how the cancellations we've been describing happen.
But here's the practical reality for any Shopify retailer: every app in the Shopify App Store is an integration. Your inventory management system, shipping carrier, accounting system, email marketing, reviews, loyalty program, customer service, marketplaces, ERP, social commerce, fulfillment partners — every one of them connects to Shopify through an integration. The question isn't whether to use integrations; you have to.
The real question is which integrations are well-built. They all sync fine on a slow day. The difference shows up when business is booming — fifty orders in the same minute, two channels racing for the last unit, a connection that drops mid-update. That's when a weak integration quietly loses the change and lets the oversell through, and it's exactly what you can't see while shopping for one. A real-time, queued, bidirectional integration is built for those moments: it syncs the instant stock changes, queues updates so none get lost under load, and runs both directions. That's the difference between an integration that prevents cancellations and one that causes them.
Specifically, the integration handling your inventory is the most consequential one in your stack — because it's the one whose failure produces the cancellation costs we just walked through. Treating it as "just another app" undersells its impact. You should treat it with the same scrutiny you'd give any other critical operational system.
How to evaluate your current sync (or a new one you're considering)
You don't need to understand integration architecture to evaluate sync quality. Five questions, all answerable by either testing or by asking a vendor a direct question:
- How fast does a POS sale show up on Shopify? Real-time integrations should reflect a sale on the website within seconds. Batch integrations typically run every 15 minutes, every hour, or less often — meaning the website can be off for a long time before catching up. Some integrations openly disclose sync windows of "up to 12 hours" or longer in their SLAs. That number is the worst-case oversell window your business is exposed to. If your vendor's docs say something similar, that's batch sync — regardless of how the marketing copy frames it.
- Does it run both directions? When a customer buys online, does your POS reflect the new order immediately, or only after the next batch?
- What happens when updates can't be delivered immediately? If the integration vendor briefly goes down, or your network glitches, are pending updates held until they can be delivered, or are they lost? Held is resilient; lost is fragile.
- Is there a daily check that compares POS and Shopify? Even good real-time sync occasionally misses an update. A scheduled comparison catches anything that slipped through before it becomes the drift you can't explain three weeks later.
- What happens during your highest-volume days? Black Friday, product drops, peak weekends — does the integration hold up under load, or does it fall behind? Ask the vendor for examples; ask current customers if you can.
The answers separate integrations that look fast on paper from integrations that hold up when your business actually depends on them.
How Mortar handles it
For Shopify retailers running Lightspeed Retail (R-Series), Lightspeed Retail (X-Series), or Heartland Retail, Mortar is built for real-time inventory sync as the default behavior:
- Transaction-driven when the POS supports it — every sale, return, stock adjustment, or count flows from Shopify to your POS the moment it's recorded, using whichever real-time mechanism the POS supports best.
- Bidirectional — changes propagate POS → Shopify and Shopify → POS within seconds, so neither channel ghosts the other's transactions.
- Queued delivery — when a change can't propagate immediately (rate limit, downstream outage, network blip), it stays queued until the block clears. Nothing is dropped, and there's no manual recovery to do.
- Scheduled reconciliation alongside the real-time flow, so anything that slips through gets caught on the next pass.
- No store reset required. Your store teams keep working in the POS they already use; Mortar links to your existing products in Shopify and handles the integration layer.
The combined effect: inventory accuracy that holds up under high-volume events (Black Friday, product drops, flash sales) without manual intervention.
See how Mortar handles real-time inventory sync →
Where to go next
- Multi-channel inventory sync: a retailer's guide — the foundational concepts, the channels involved, and what good sync looks like.
- Multi-location inventory management for Shopify retailers — why most multi-location retailers don't need a separate IMS, and what they need instead.
- How to prevent overselling on Shopify — how to protect against oversells from inventory drift.
- Real-time inventory accuracy: why BOPIS fails without it — the BOPIS-specific deep dive.
See how Mortar's real-time sync architecture works →
Add reach without adding overhead. Mortar runs your store and your online store as one operation. Add channels while you keep working in the POS you already use. Sell everywhere your customers are — without the work multiplying. Your store, everywhere. See how Mortar works · Why Mortar