Shopify says you have 23 units of a bestselling jacket. Your Lightspeed POS at the Madrid store says 17. Neither number is wrong at the moment it was recorded. They are simply not looking at the same clock.
This is the inventory problem behind many multichannel stockouts. A customer places an online order while a store associate is completing a sale. A return is accepted at one location but processed in the central system later. A buyer makes a manual adjustment after counting a shelf. Each system records a valid event, but the events do not always arrive in the same order, at the same time, or with the same understanding of which location owns the stock.
Connecting Shopify to a physical retail operation is not just a matter of copying a number from one system to another. The workflow needs to define which events change available stock, which system is responsible for each decision, and how much delay the business can accept before an item is offered to another customer.
Why Shopify and store systems disagree
Inventory sync usually fails at the boundaries between systems. The most visible problem is event ordering. Suppose a store sale reduces a jacket from 18 units to 17. A few seconds later, an online order reduces the same jacket from 17 to 16. If the online event arrives first, then the store event arrives with an older quantity, one platform can overwrite the newer result with stale information.
Clock skew creates a similar problem. Shopify, a point of sale system, an inventory service, and a warehouse application may all use different server clocks. If a workflow decides which update is newest using timestamps alone, a timestamp that appears later may not represent the latest business event. The issue is not that one clock is inaccurate enough to notice in daily operations. It is that a series of small differences can change the order in which competing updates are applied.
Partial writes are another common failure point. A store sale may be successfully recorded in the POS, while the request that should reduce inventory in the shared stock service times out. The sale exists, but the stock movement does not. The reverse can also happen. Stock is reduced centrally, but the order confirmation fails and a customer service team has to reconstruct what happened.
Manual adjustments are essential in retail, and they are often treated as exceptions when they should be treated as first-class events. A cycle count, damaged item, display unit, supplier correction, or found item can change the available quantity without an order being placed. If an employee edits the quantity directly in Shopify, while a store manager edits it in the POS, the next automated sync may erase one of those decisions.
The practical lesson is that a sync process should move stock movements, not only final stock totals. A final total tells you what a system believes now. A movement tells you why it changed. When an investigation is needed, the difference matters.
Batch sync and real-time sync solve different problems
Batch sync is a scheduled reconciliation. At a set time, often overnight or at the end of the trading day, the integration compares quantities and sends updates between systems. It is easier to operate, easier to inspect, and often adequate for retailers whose stock changes slowly.
A daily batch can be sufficient when most SKUs have low sales velocity, products are not perishable, replenishment is predictable, and the retailer does not run flash sales. It can also work for a business with a single physical location, Shopify, and one POS, especially when staff already perform a manual daily reconciliation. In that environment, the cost of continuous event processing may exceed the value of a shorter stock window.
The limitation is the size of that window. If a product sells three times between scheduled updates, the online channel and store team may both act on a quantity that is already wrong. A batch process can correct the number later, but it cannot prevent an order that was accepted during the gap.
Real-time sync is event-driven. A sale, return, transfer, receipt, or adjustment creates an event, and the relevant inventory locations are updated as that event is processed. This reduces the time during which channels are working with different quantities. It does not mean every screen changes at the exact same millisecond. Networks fail, APIs rate-limit requests, and some platforms process updates asynchronously.
A useful real-time design therefore needs more than a frequent timer. It needs an event queue, retries for temporary failures, a way to identify duplicate events, and a reconciliation process for events that cannot be applied. It also needs location-aware rules. A quantity available in a Madrid shop may not be available for an online order if the retailer does not offer ship-from-store or store fulfillment from that location.
What an agreed stock level means in practice
Retailers often ask for every channel to show the same stock number. That sounds precise, but it is not always the right operational goal. In a distributed system, the more useful goal is an agreed stock level within an acceptable lag window.
Eventual consistency means that systems may briefly disagree while an update is travelling through the workflow, but they converge after the event has been processed. The important questions are how long the disagreement can last, what happens when an update fails, and whether the customer-facing channel is protected during the delay.
For a high-velocity product, an acceptable lag window may be measured in seconds or a few minutes. For a low-velocity product with hundreds of units in stock, a delay of several hours may have no commercial effect. The threshold should be set by sales velocity, margin, replenishment time, and the consequences of accepting an order that cannot be fulfilled.
Agreed stock also requires a shared definition of available. On-hand stock, sellable stock, reserved stock, stock in transit, safety stock, and damaged stock are not interchangeable. A retailer may physically have 23 jackets, but only 18 may be sellable, 3 may be reserved for online orders, and 2 may be held for quality inspection. If Shopify receives the on-hand figure while the POS uses sellable stock, the systems can be synchronized technically and still disagree operationally.
Before choosing an integration schedule, define the stock model. Decide which locations participate, whether reservations reduce availability immediately, how returns become sellable again, and which system records transfers. These decisions prevent the integration from hiding business ambiguity behind a clean-looking number.
A three-location retailer discovers a four-hour gap
Consider a synthetic example. A fashion retailer has three stores, a Shopify storefront, and Lightspeed POS at each location. A limited jacket is promoted in an email campaign. At 10:00, the central inventory view shows 42 sellable units across the business. The online channel is configured to offer 20, while the remaining units are allocated to stores.
The retailer is using a daily batch sync. At 10:15, one store sells four jackets. At 11:05, the online campaign starts producing orders at a much higher rate than expected. By 14:00, the stores have sold another nine units, and Shopify has accepted 19 online orders against its earlier quantity. The next reconciliation identifies the mismatch, but several orders now require substitutions, cancellations, or transfers between locations.
The cause is not a single broken connector. The business chose a four-hour period in which each channel was allowed to make decisions from old information. The promotion changed the risk profile of the SKU, but the sync policy did not change with it.
A better workflow could use event-driven updates for this item, reserve stock as online orders are created, and keep a small safety buffer unavailable for sale. It could also route fulfillment from specific stores only when their stock is current enough to support that promise. The design does not need to make the retailer’s inventory perfect. It needs to make the commercial promise realistic.
How to design the workflow before choosing the connector
Start with the events that change stock. Include sales, cancellations, returns, exchanges, transfers, receipts, damages, cycle counts, and manual corrections. For each event, identify the source system, the affected location, the quantity, and the condition under which the event can be replayed safely.
Next, establish an authority for each decision. Shopify can be the source of online orders, while the POS remains the source of store sales. A central inventory layer can calculate available stock across locations without pretending that either channel owns every quantity. The important point is to avoid two systems independently overwriting the same total.
Then define failure handling. A failed update should be visible to an operations team, not silently discarded. Duplicate notifications should not reduce stock twice. An event that arrives out of order should be held, rejected, or reconciled according to a documented rule. Periodic reconciliation remains necessary even with real-time processing, because real-time reduces lag but does not remove failures.
Finally, measure the workflow using operational indicators. Track the age of unprocessed events, the number of stock mismatches, the time required to resolve them, and the frequency of manual adjustments. These measures show whether the sync is helping store and ecommerce teams make decisions, rather than merely reporting that an API request succeeded.
Stockagile connects with Shopify, WooCommerce, Prestashop, Magento, Lightspeed, and Square. Daily inventory sync is available on the Starter tier. Growth and Scale tiers support real-time sync and access to the REST API. The right setup depends on the retailer’s product velocity, number of locations, fulfillment model, and tolerance for overselling.
Sync complexity grows with SKU count and location count. A single-location retailer using Shopify and one POS may be perfectly well served by manual daily reconciliation. A retailer with several stores, shared online stock, frequent promotions, and transfers between locations needs a more deliberate event-driven workflow. In both cases, the goal is not an impossible promise that every screen will always show the same number. It is a stock process with a known lag window, clear ownership, and a recovery path when systems disagree.
Even with good sync, overselling can still happen during returns processing lag, gift card redemptions, or sales of bundles whose component stock is not updated together. Those cases are boundary conditions, not reasons to abandon synchronization. They are reminders that agreeing on stock levels requires the full retail workflow, not only a connection between two platforms.
