Online orders, in-store stock: why retail and ecommerce keep competing for the same unit

A customer buys the last one at the counter at eleven in the morning. The website keeps offering it until the afternoon, and by lunchtime a second customer has bought the same unit online. The usual verdict is that someone on the floor was slow to update the count. That verdict is comfortable because it points at a person. A retail and ecommerce inventory conflict happens when your online store and your physical store both sell from the same physical stock while each keeps its own count of it. The two channels are not two inventories. They are two claims on one inventory, and when neither defers to the other, the same unit gets promised twice.

Seen that way, the oversell was not a slip. It was available the whole time, waiting for two orders to arrive close enough together to expose it. This piece works through the conflict one layer at a time, starting with the explanation most teams reach for and then going one step past it to the thing that actually made the double sale possible. The retail-specific case is worth isolating, because the online and offline split has its own mechanics that the general cross-system version does not fully cover.

What a retail and ecommerce inventory conflict actually is

A retail and ecommerce inventory conflict is what happens when a single physical stock pool is sold through two channels that each track it separately. One shared shelf, two counts, no rule for which count wins. When both channels believe a unit is theirs to sell, the same item can be committed to an in-store buyer and an online buyer at once, and only fulfilment reveals that one of them cannot be served.

The key word is committed. In most retail systems, selling a unit does not simply subtract it from a physical total. It moves that unit into a committed or reserved state, and the sellable number is what remains after those commitments are taken out. In Shopify, for instance, available stock is on-hand minus what is committed and unavailable. The conflict is not that the shelf is wrong. It is that two channels are each doing this subtraction against their own private view of what has already been claimed, so both can still show a unit as free to sell.

This is why the phrase “double-sold” is slightly misleading. The unit was never sold twice in any physical sense. It was double-promised: two channels each held the right to promise it, and each did. The distinction matters because it points the fix at the right place. You are not chasing a counting error. You are looking at two systems that were each granted the authority to say yes.

The first-order explanation, and where it stops being enough

The first-order explanation is that the count was updated too slowly: a staff member was busy, a sync ran on a delay, a manual adjustment lagged behind the sale. This is usually true, and it explains the timing of any single oversell. What it does not explain is why the oversell was possible in the first place, which is the part that actually determines whether it happens again.

Timing accounts for the specific moment two orders collided. It does not account for the standing condition that let them collide at all. If the only problem were speed, then a faster update would remove the conflict entirely, and yet brands with near-instant sync still oversell during their busiest hours. That gap between the explanation and the outcome is the signal that the first-order story is incomplete. Something structural is sitting underneath the timing, and it stays in place no matter how fast the updates run.

Blaming the delay also quietly sends the fix in the wrong direction. It leads to buying a faster sync, adding a reconciliation shift, or asking the floor team to update more often. Each of those shortens the window in which the conflict can surface. None of them removes the reason the conflict exists. The clock gets faster. The condition underneath it does not move.

The second-order driver: two channels reading two counts of one pool

The real driver sits one level down: the two channels were built to read two separate counts of the same physical pool, and each was allowed to sell against its own count without checking the other. The oversell is not a breakdown of that arrangement. It is the arrangement working exactly as designed, because nothing in it decides whose claim on a unit comes first.

Trace a single unit through it. The shop floor and the website both start believing the unit is sellable. The floor sells it and moves it to committed in the point-of-sale record. In that instant the website’s count is not wrong by its own logic, because the website was never reading the point-of-sale record as authoritative. It was reading its own. Two counts, each internally correct, disagreeing about one physical object. The conflict lives in the space between them, and that space exists because neither count was ever made to defer to the other.

This reframes what “fixing overselling” even means. The problem is not that a number fell behind. It is that two channels hold independent authority over the same stock, so the count can always be current in both places and still let the unit go twice. As long as both channels can say yes on their own, the conflict is structural, and it will keep surfacing whenever demand arrives faster than the channels reconcile. The retail floor and the online store are not competing because someone was careless. They are competing because the architecture gave them equal and separate claims on one shelf.

Why real-time sync narrows the conflict without ending it

Real-time sync makes the conflict rarer without removing it, because it shrinks the window in which two channels disagree but leaves both channels holding their own claim. When an in-store sale fires an immediate update to the website, the gap between the two counts drops from hours to seconds. For everyday trading that is often enough to make the conflict disappear from view. It is a genuine improvement and the right first move.

The reason it is not a full resolution is that the two claims still exist independently. A message can be delayed by a rate limit or a retry during a rush, and in the seconds before it lands, both channels can still sell. Faster propagation moves a copied number between two systems more quickly. It does not make one of them the authority the other obeys. This is the same mechanism that produces mismatch across every disconnected system, examined in depth in the pillar on why inventory never matches across systems. Here the point is narrower and worth holding onto: speed reduces the frequency of the retail-versus-online conflict, but only a decision about whose claim wins reduces its possibility.

The decision underneath it: does in-store stock count as online availability?

The lever most teams never consciously pull is a single decision: whether each store’s physical stock is allowed to count as online availability, and whether a store can fulfil online orders at all. Answer that clearly, per location, and most of the conflict resolves. Leave it unstated, and every store becomes a pool that both channels quietly draw from without agreeing they are doing so.

The decision has real branches, and they are operational rather than technical. A store’s stock can be reserved for walk-in customers only, kept off online availability entirely. It can be made fully sellable online, turning the shop into a fulfilment location for web orders. Or it can contribute partially, with a buffer held back so the floor is never emptied by online demand. Shopify supports this through location-level inventory and fulfilment priority, so an order commits against a specific location rather than a company-wide total. The tooling to make the choice exists. What is usually missing is the choice itself.

This is the same shift that sat underneath OGÉR’s move to a unified setup, where online and offline finally operated from one coordinated structure rather than two channels each guarding a private count. A connected point-of-sale system such as Shopify POS closes the gap between the counter and the website by putting both on the same record, so a sale in one place is visible to the other by default. The tool matters less than the decision it lets you enforce: which channel’s claim on a shared unit comes first, and under what rule.

What ending the conflict actually requires

Ending the conflict requires a decision, not a purchase: name one count that both channels read from, and give one channel’s claim priority when the same unit is in play. Once both channels defer to a single shared record of what is committed and what is available, the same unit can no longer be promised twice, because there is only one place where a promise is recorded.

That decision is the operational implication of everything above. The staff update, the sync speed, and the reconciliation shift all treat the symptom, which is why the conflict returns after each of them. The structural fix is to remove the independence that let two channels both say yes. In practice that means one system holds the sellable count, every channel reads from it before committing a unit, and the rule for what happens when store and web want the same item is written down rather than discovered mid-oversell. The retail floor and the online store stop competing not because they update faster, but because they are finally drawing from one count instead of two.

Frequently asked questions

Why does my online store sell items that are out of stock in the shop?

Because the website and the shop keep separate counts of the same physical stock and update on a delay. When the last unit sells in store, the website does not treat that as authoritative until a sync reports it, so it keeps offering a unit that is already gone. The cause is two channels holding independent counts, not a single slow update.

Is a retail and ecommerce inventory conflict the same as overselling?

Overselling is the visible result. The conflict is the underlying cause. Overselling happens when more units are sold than exist. A retail and ecommerce inventory conflict is the specific reason it happens across channels: two channels each hold their own count of one physical pool and each can commit a unit without checking the other, so the same item gets promised twice.

Does Shopify POS stop online and in-store from selling the same unit?

A connected point-of-sale system like Shopify POS puts in-store and online sales on the same record, so a counter sale is reflected in online availability by default rather than after a delayed sync. That removes the everyday version of the conflict by giving both channels one shared count. Edge cases during heavy traffic still depend on how location availability and reservations are configured.

Should in-store stock be available to sell online?

It depends on a decision you make per location, not a default. Store stock can be reserved for walk-in customers, made fully sellable online so the store fulfils web orders, or shared partially with a buffer held back for the floor. The conflict tends to persist when this is never decided, because both channels then draw from the same store pool without agreeing they are.

Will real-time inventory sync end the conflict between channels?

It reduces the conflict sharply but does not end it. Real-time sync shrinks the window where two channels disagree from hours to seconds, yet both channels still hold their own claim on the stock, and a delayed message during a rush can still let both sell. Ending the conflict requires one shared count that both channels defer to, not only faster updates.

Key takeaways

• A retail and ecommerce inventory conflict is two channels selling from one physical pool while each keeps its own count. The channels are two claims on one inventory, not two inventories.
• The unit is double-promised, not double-sold. Both channels held the right to promise it, so both did. That points the fix at authority, not at a counting error.
• The first-order explanation, a slow update, is real but incomplete. It explains when an oversell happened, not why it was possible. The structural condition survives any increase in speed.
• The second-order driver is that two channels read two separate counts of the same pool with no rule for whose claim wins. The conflict is the design working as built.
• The resolution is a decision, not a tool: one shared count both channels read from, one channel’s claim given priority, and a clear per-location rule on whether store stock counts as online availability.

The mismatch between the counter and the website is not a sign that the floor team is behind on their updates. It is a sign that two channels were each handed the right to sell the same shelf and never told which of them comes first. That is a decision waiting to be made, and once it is, the two channels stop competing for a unit that only one of them could ever have delivered.