---
title: "Mossery says one number and your online store says another"
summary: >
  Most disagreements are not errors: a store only sees stock at the locations
  mapped to it, so retail counters and event stalls are excluded by design. If
  the number really is wrong, the direction decides the fix. A store showing
  too few is repaired on its own overnight. A store showing too many is never
  repaired on its own, and needs a push by hand.
type: troubleshooting
group: sync
step: 7
permission: channels.manage
prerequisites:
  - /help/sync/how-stock-reaches-your-channels
related:
  - /help/sync/product-shows-zero-online
  - /help/sync/fix-a-sync-error
  - /help/store/what-each-location-type-can-do
last_updated: 2026-08-07
---

**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-1-are-you-comparing-the-same-two-numbers)
- [Check 2: which direction is the difference?](#check-2-which-direction-is-the-difference)
- [Check 3: is that store actually being written to?](#check-3-is-that-store-actually-being-written-to)
- [Push the correct number by hand](#push-the-correct-number-by-hand)
- [When every check passes](#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](/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](/integrations/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.

1. Open the product and find its **Sales channels** card.
   [Products](/inventory/products)
2. Find the store that is reading too high.
3. Confirm the store is set to live. In observing mode the button records the
   intention and sends nothing, which looks identical to success.
4. Click **Push now**. It sends the current on-hand figure for the mapped
   location, minus anything already allocated.
5. 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](/help/sync/fix-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 →](/help/sync/product-shows-zero-online)

**Reading and clearing a sync error.** A failed push records which store it failed
against and how many times it has fired.
[Learn more →](/help/sync/fix-a-sync-error)

**What each location type can do.** Warehouses, retail counters, events and
consignees differ in exactly which channels they can supply.
[Learn more →](/help/store/what-each-location-type-can-do)