Skip to content

How corrections work

Syncing changes as they happen is not enough on its own. Stock also moves in ways we never see — someone edits a number directly in Shopify admin, an app we don’t know about writes to a location, a delivery fails and later turns out to have landed anyway. So once an hour we check, and where we find a difference we cannot account for, we correct it.

The hourly check runs only while the group is syncing live. A group that is still recording only, or that has been paused, is not checked and nothing is corrected.

This page is the one to read before you are surprised by a number changing back.

Corrections come from the main store.

When a partner store’s number disagrees with the main store’s, and our own records do not explain the difference, the partner is set to the main store’s number.

The main store is never corrected by this process. A number you change at the main store propagates outward; a number you change at a partner store is either explained by our records or overwritten.

Once an hour, for each store, we look at what changed since the last check.

First pass — things that changed at the main store. Every matched partner must hold the same number. If it does, we count it and move on. If it does not, we set the partner to the main store’s number and record the correction.

Second pass — things that changed only at a partner store. Here we ask a different question: do our own records account for this? We know what the partner’s number was at the end of the last check, and we know every change we sent it since. If

last known value + everything we sent = what it holds now

then the change is explained and we leave it alone — that is your partner selling normally. If the sum does not close, something moved that we did not cause, and the main store’s number stands.

A product we have never seen at that location gets neither treatment. We write down its current value as a starting point and change nothing. We do not overwrite something we have no history for.

Both passes only ever act on products the shared-SKU index has confirmed as Matched. Anything ambiguous, not found or deleted at a store is counted and skipped, never snapped.

The four verdicts in the Corrections table

Section titled “The four verdicts in the Corrections table”

You will find them in Settings → Multi-store → Sync runs, in the Corrections table at the bottom of the tab — not on a tab of its own. It sits with the runs because what it lists is the outcome of the runs above it.

Every row is one stock level, newest first: Store, SKU, Location, Found → set to, Result, the Run that did it and When. Page through it with Older / Newer.

ResultPlain EnglishDid stock change?
Settledyou ran a settle, and we set this store to the target valueyes
Correctedthis store disagreed with the main store and we could not account for the difference, so we set it to the main store’s numberyes
Explainedthis store’s number changed, and our records fully account for it. Left aloneno
First check — recorded onlyfirst time we have seen this product at this location. We recorded a starting point and changed nothingno

The first check after you link a store imposes the main store’s numbers on every matched product at that store — settled or not. There is no grace period and no “wait until it’s been settled” fence.

That is deliberate: a fence would mean a half-settled group silently running two truths. But it does mean:

If your partner store’s counts are the ones that matter, run a settle right after linking.

See Settling stock. A settle is how you choose which numbers win; the hourly check always chooses the main store.

We deliberately leave things alone in several situations. Each one is visible, not silent:

  • A change of ours is still in flight. If we have sent something to that store and it has not come back yet, we do not correct that product this hour — correcting it would fight with our own delivery. It is checked again next hour.
  • The product is ambiguous — the same SKU is a recipe at both stores, or matches more than one product. We exclude it from both passes entirely, so a partner’s own local recipe never gets snapped.
  • The product is not matched, not found, or deleted at that store. Nothing to compare.
  • We could not read one of the stores. One store failing does not stop the check for the others; that store is simply not checked this hour, and the run reports it.
  • We have no starting point for that product at that location — see “First check — recorded only” above.
  • The window did not fully resolve. If a check left anything unfinished, the next one re-examines the same period rather than moving past it. We would rather check twice than miss once. (There is a limit: the window is never dragged back more than six hours, so one permanently stuck item cannot make every later check slower and slower.)

The second pass does something useful in the other direction. If our ledger says a change failed but the partner’s stock shows it actually landed, the sum closes — and we mark our own record corrected rather than pushing the stock around again. So a delivery that timed out and quietly succeeded stops looking like a failure.

If Shopify moves an order’s fulfilment to a different location after we have already synced it, the totals stay right but the change may sit at the old location’s counterpart. The hourly check heals that. Totals are always correct; a location split can be an hour behind.

“Can I make a partner store win instead?” Not as a standing rule — the main store always wins the hourly check. What you can do is run a settle and choose “lowest wins” or upload a worksheet with the numbers you want. After a settle, the hourly check has nothing to correct because the stores already agree.

“Why did it change back after I fixed it?” Because you fixed it at a partner store. Fix it at the main store, or settle.

“Can I turn the hourly check off?” Not on its own. Pause group (Settings → Multi-store → Group, at the main store) stops everything including the check, and that is the right move if you need it to hold still while you investigate. Resuming does not replay the gap; the next check picks the group up where it is.

“How far back does it look?” At least the last hour, and further if the previous check did not complete cleanly. It never skips a period it did not finish.

Everything above rests on there being a main store. If it uninstalls Assemblified, or is removed, or its Enhanced plan lapses, the whole group is paused and nothing syncs or is corrected anywhere. The Group tab says so: “The main store is no longer available.”