Your store does not hold a copy of your inventory. It holds one number, for one place, that this app last sent it.
That is why the two can differ, and why "different" is not the same as "wrong". A store is often showing exactly what it was designed to show. When it genuinely is wrong, which way it is wrong decides everything: one direction heals itself overnight, the other never does.
- Check 1: are you comparing the same two numbers?
- Check 2: which direction is the difference?
- Check 3: is that store actually being written to?
- Push the correct number by hand
- When every check passes
Work through them in that order. Most reported disagreements stop at check 1.
Check 1: are you comparing the same two numbers?
The total you see in this app is the whole business. The number on a store is one location on one store.
Every location is mapped, one by one, to the stores it fulfils for. There is no guessing: if a location has no mapping row for a store, that store has no target to write to and the stock there stays invisible to it. Warehouses are normally mapped to your online stores. Retail counters and event stalls normally are not, because their units are sold across a counter, not shipped.
So a product can hold real stock that a given store can never see, and nothing is broken.
Three more differences are expected rather than faulty:
- Built products advertise more than they hold. A kit publishes what is already assembled plus what its components could build at that same location. A store reading 40 against a built stock of 12 is the intended behaviour.
- Made-to-order products keep selling at zero. A product set to be made on demand is allowed to sell below zero on the store, so it can show as available while the app reads 0.
- Allocations are already deducted. The figure pushed out is what is on hand minus what open orders have claimed, so it sits below the shelf count.
If the difference survives all of that, it is real. Go to check 2.
Check 2: which direction is the difference?
This is the part people get wrong, so it is worth stating plainly.
A reconciliation runs every night. It reads the live quantity back from each store, compares it against this app for every mapped product and location, and records every difference it finds. It then corrects in one direction only.
| What the store shows | What the nightly run does | What you must do |
|---|---|---|
| Fewer than the app (undercount) | Records the difference and pushes the correct, higher number back | Nothing — check again tomorrow |
| More than the app (overcount) | Records the difference and stops there | Push the correct number by hand |
The asymmetry is deliberate. Pushing a number up only ever un-hides stock you really have, so it is safe to automate. Pushing a number down is not: orders are being placed and fulfilled while the run is working, and an automatic down-correction would overwrite a deduction that a real order had just made. Stock coming down is the job of fulfilment, which happens live.
Two more things about that nightly run are worth knowing:
- It only writes to stores that are switched to live. A store still in observation mode is compared and reported, never written to.
- It is capped per run. A large backlog is corrected over several consecutive nights rather than in one burst, because a flood of writes to a store is its own kind of outage. A difference that is still there tomorrow is not necessarily stuck.
Open Reconciliation to see the most recent run, how many items it checked, how many differed, and the per-item list. Reconciliation
Check 3: is that store actually being written to?
A store can be connected, mapped, and correct in every respect, and still be receiving nothing.
Each store connection has one of three modes:
| Mode | What happens on a stock change |
|---|---|
| Live | The new number is sent to the store |
| Observing | The app records the number it would have sent, and sends nothing |
| Paused | Nothing happens at all |
Observing mode is how a store is validated before it is trusted, and it is the single most common reason a correct number never appears on a storefront. Inside an observing store, individual products can be added to a trial list so that those few do push while everything else stays quiet — so "that product updates but this one doesn't" on the same store is a real and expected state.
Check the mode on the channel before assuming anything is broken. Sales channels
Push the correct number by hand
An overcount will sit there forever until someone sends the right number. Do this once you have confirmed the app's figure is the correct one.
- Open the product and find its Sales channels card. Products
- Find the store that is reading too high.
- Confirm the store is set to live. In observing mode the button records the intention and sends nothing, which looks identical to success.
- Click Push now. It sends the current on-hand figure for the mapped location, minus anything already allocated.
- Reload the storefront listing and confirm.
If the push reports an error rather than a quantity, it has written a row you can read and act on. See fixing a sync error.
When every check passes
If the mapping is right, the direction is an overcount, the store is live, and a manual push still does not move the number, the fault is no longer in the sync layer.
Two places to look next. First, compare the app's figure against a physical count at that one location. If the shelf and the app disagree, this is a stock accuracy problem and the fix is a stock count, not a push. Second, check whether the store itself is being written to by something else — a second system pushing to the same store will keep overwriting whatever you send, and no amount of pushing from here will win.
If neither applies, note the product code, the store name, the number each side is showing, and the time you checked, and pass all four to whoever administers your sales channels. Those four facts are what makes a report actionable.
Explore
A product shows 0 online but you still have stock. The extreme undercount has its own three checks — a missing link, an unmapped location, or a queued update. Learn more →
Reading and clearing a sync error. A failed push records which store it failed against and how many times it has fired. Learn more →
What each location type can do. Warehouses, retail counters, events and consignees differ in exactly which channels they can supply. Learn more →