Your online stock says available, your store sold out yesterday: why inventory never matches across systems

The website shows three units available. The shop floor sold the last one yesterday afternoon. The warehouse export from this morning says two. Finance is looking at a fourth number in the accounting system, and nobody in the room can say which one is real. Most teams read this as a data-entry problem and hire another person to keep the numbers clean. Inventory not syncing across systems is rarely a data-entry problem. It happens because every system holds its own copy of the count and none of them was ever named the one that decides. Faster syncing changes how quickly the copies disagree. It does not change that they disagree.

That distinction is the whole article. Once you see stock as a number that several systems each calculate on their own terms, the daily mismatch stops looking like carelessness and starts looking like exactly what the architecture was built to produce. This piece walks through the mechanism end to end, including the places where the usual fixes quietly stop working, so you can tell which of them will actually hold for your setup and which will just reset the clock until the next oversell.

What “not syncing” actually describes

Inventory not syncing across systems means two or more platforms hold different quantities for the same product at the same moment, because each one maintains its own record and updates on its own schedule. The mismatch is not a glitch inside one tool. It is the predictable result of several tools each treating their own copy of the number as correct, with no single record they all defer to.

The word “available” hides most of the trouble. In practice a sellable quantity is almost never a raw physical count. In Shopify, for example, on-hand stock is the physical total, and available is what remains after committed and unavailable units are subtracted. Available is a calculated figure, not a fact you can read off a shelf. Now put four systems side by side. Each one calculates its own version of “available” from its own view of what is committed, reserved, damaged, or in transit. They were never going to land on the same figure, because they are not measuring the same thing. They are each running a slightly different formula on slightly different inputs.

A source of truth is the single system designated to hold the authoritative value for a given piece of data, so that every other system reads from it rather than keeping a rival copy. When people say a business has “no source of truth for stock,” this is what they mean: several systems each believe their own number, and the business has never decided which one wins. Hold onto that definition. Every driver below traces back to it.

Driver one: every system keeps its own version of the count

Start with where the numbers actually live. A growing brand typically runs a storefront, a point-of-sale system, a warehouse or third-party logistics system, and an accounting or ERP platform. Each one records stock because each one needs stock to do its job. The storefront needs it to decide what to sell. The warehouse needs it to pick and pack. Finance needs it to value the asset. None of them was built to ask another system for permission first.

So a single sale touches several records that update independently. A customer buys online. The storefront moves that unit from available to committed and drops the sellable number. The warehouse system will not know until a sync or a scan tells it. The accounting system will not know until an order export runs, often overnight. For a window that can last minutes or hours, three systems hold three defensible numbers, and all three are internally correct. The mismatch is not error. It is latency between records that were designed to be independent.

The mechanism gets sharper across channels. When you sell on the storefront and a marketplace at once, both are drawing down the same physical pool while each keeps its own count. Under normal traffic the gap is small enough to ignore. During a promotion or a launch, orders arrive faster than any sync interval, and both channels keep selling against a number that is already spent. That is the classic oversell, and it is worth being precise about the cause. The channels were not out of contact with each other. They talked on a delay while demand outran the delay.

The intervention point here is not “sync more often.” It is deciding which system is allowed to hold the real number, so the others stop asserting their own. We will get to that. First, two more drivers have to be on the table, because fixing this one alone still leaves you exposed.

Driver two: “in sync” only ever means “agreed at the last sync”

Most integrations move stock on a schedule. A job runs every fifteen minutes, or every hour, or overnight, and copies the latest counts between systems. Between runs, the systems are not synchronised. They are holding whatever they agreed at the last run, while reality has moved on. “In sync” is a snapshot, not a live state, and the length of the gap is the length of your exposure.

The common answer is to shorten the interval or switch to event-driven updates, where a change in one system fires an immediate message to the others. Shopify supports this through webhooks that push an update the moment inventory or an order changes, which is a real improvement over polling on a timer. Moving from batch to event-driven narrows the window where systems disagree, and for many brands it removes the everyday version of the problem. It is the right direction.

It is also where the fix quietly stops being total, so this is the part the shorter guides skip. Event-driven sync still has a window, it is just small. A message can be delayed by an API rate limit, dropped by a timeout, or stuck behind a retry queue during exactly the traffic spike when accuracy matters most. Two systems can both decrement the same unit inside the few seconds before the message lands. The way it breaks also changes shape: with batch sync you expect a lag and plan around it, while with event-driven sync you assume live accuracy and get blindsided when a silent message drop leaves one channel selling stock that is already gone. Faster is better. Faster is not the same as authoritative. A quicker copy is still a copy, and two copies can still both say yes.

Driver three: the count moves in ways the sync never sees

Even a fast, reliable integration only synchronises the events it is watching. Stock moves in several ways that sit outside the clean “sold one, subtract one” path, and each one opens a gap that no sync interval closes because the sync was never told to look there.

Returns are the clearest case. A customer sends an item back. Physically it exists again, but it does not become sellable until someone inspects it, decides it is fit to resell, and puts it back into the right state in the right system. Until then, one system counts it as on hand while another still treats it as gone. The unit is real. The systems disagree about whether it can be sold, and both are arguably right.

Reservations and draft orders create the same split from the other direction. When a staff member holds stock for a customer, or a pre-order app sets units aside, or a draft order is opened, that stock is spoken for without being sold. In Shopify these units move into committed or unavailable states, so the sellable count drops even though nothing has shipped. A system that only watches completed orders never sees the hold, so it keeps offering stock that is already promised.

Then there is location. Once you hold stock in more than one place, “how many do we have” splits into “how many, and where.” An order commits against a specific fulfilment location, not against the company-wide pool, so a unit can be physically present in the building and still not sellable to a given channel because it is allocated somewhere else. Add partial fulfilments, transfers in transit, and stock marked unavailable for damage or quality control, and you have a set of legitimate movements that a naive sync flattens into a single number it cannot keep honest. This is the layer where stock inconsistencies quietly accumulate across channels, and it is the reason a recount fixes today and not tomorrow.

The bottleneck: no system was ever elected the master

Put the three drivers together and the real constraint comes into view. It is not sync speed. It is that several systems each hold an authoritative number and none of them outranks the others. There is no master. When two records disagree, nothing in the architecture decides who is right, so the business decides manually, over and over, usually after a customer has already found the gap.

This is why re-counting stock feels productive and changes nothing. A recount makes every system agree for a moment. Then the next return, the next reservation, the next in-flight order during a sync delay pulls them apart again, because the thing that let them drift is still in place. You corrected the symptom and left the cause untouched. The clock resets. The mismatch was never that the numbers were wrong. It was that the business had no rule for which number wins, so all of them stayed in the running.

Naming the master is an architectural decision, not a tooling purchase, and it is the decision most stacks have never actually made. Buying a sync app without making it does not resolve the conflict. It automates it. You now have a faster mechanism for propagating whichever number happened to update last, which is not the same as propagating the number that is true.

Where intervention actually has leverage

The highest-leverage move is the one the recount and the faster sync both skip: decide which system owns the authoritative stock number, and make every other system read from it instead of keeping a rival copy. That is what “single source of truth” means in practice, and it is a governance decision before it is a technical one.

A few principles make it hold up in a real operation. Assign ownership per data domain, not once for everything: one system owns physical on-hand, one owns what is sellable per channel, and the boundary between them is explicit rather than assumed. Let the owner of a number be the only system allowed to change it, and let the rest subscribe to it. Move updates on events rather than a timer so the read-only copies stay close to live. And accept that a reconciliation process is part of the design, not a sign it failed: a scheduled check that compares systems, flags divergence, and surfaces it before a customer does is how a well-run stack stays honest between events.

This is the work behind the phrase “unified commerce,” and it is worth seeing concretely rather than as a slogan. When Flatline connected North Actionsports’ separate PIM, ERP, and multiple webshops into one coordinated flow, the value was not that data moved faster between the systems. It was that the systems stopped each holding a competing version of the truth and started deferring to a defined order. That is the shift that ends the daily mismatch: not a quicker copy, but a decided one.

The practical first step costs nothing and clarifies everything. Map your current stack and, for each system, write down which stock number it holds and where that number comes from. Most teams discover within an hour that three or four systems all believe they own “available” and none of them was ever told to defer. That map is the real diagnosis. Once you can see which systems are asserting authority they were never granted, the choice of where to elect the master stops being abstract and starts being obvious.

Frequently asked questions

Why does my inventory show available online but sold out in store?

The storefront and the point-of-sale system keep separate counts and update on a delay. When a unit sells in store, the storefront does not know until a sync runs or a scan reports it. In the gap, the website is showing a number that was true at the last sync and is now stale. The cause is that both systems hold their own count with no shared record they both defer to.

Will real-time sync stop overselling completely?

It reduces overselling sharply but does not remove it. Event-driven sync narrows the window where systems disagree to seconds, yet a message can still be delayed by a rate limit, dropped by a timeout, or delayed in a retry queue during a traffic spike. Two systems can decrement the same unit inside that window. Real-time is a faster copy, not a single authoritative record.

What is a single source of truth for inventory?

It is the one system designated to hold the authoritative stock number, so every other system reads from it instead of keeping its own version. It is a governance decision about which record wins when two disagree, not a specific product. Without it, several systems each treat their own count as correct and the business reconciles the conflict by hand.

Does an ERP fix inventory mismatch on its own?

An ERP can serve as the source of truth because it is built to centralise operational data, but it only resolves mismatch if it is implemented as the authority other systems defer to. Dropped into a stack without that decision, an ERP becomes one more system holding its own number. The fix is the governance choice, and the ERP is one place that choice can live.

Why do returns keep causing stock discrepancies?

A returned item physically exists again but is not sellable until it is inspected and put back into the correct state in the correct system. Until that happens, one system counts it and another does not, and both are defensible. Returns move stock outside the ordinary sold-one, subtract-one path, so any sync that only watches completed orders never sees the change.

Key takeaways

• Inventory not syncing across systems is an authority problem, not a speed problem. Several systems each hold their own count and none was named the one that decides.
• “Available” is a calculated number, not a physical fact. Each system computes it from its own view of committed, reserved, and unavailable stock, so they were never going to match on their own.
• Faster and event-driven sync narrow the gap but never close it. A quicker copy is still a copy, and two copies can still both sell the same unit.
• Returns, reservations, multi-location routing, and in-transit stock move inventory in ways a naive sync never watches. This is why a recount fixes today and not tomorrow.
• The leverage is electing a single source of truth per data domain and making every other system read from it. Map which system currently owns each number first. The conflicts usually become obvious the moment you write it down.

Seen this way, the mismatch on your screen is not a sign that someone is careless with the counts. It is a sign that the architecture never decided whose count to believe. That is a solvable problem, and it starts not with a new tool but with a decision your systems have been waiting for someone to make.