Settling stock and the worksheet

Syncing keeps stores in step from now on. It does not fix where they are today. A settle does that: it picks one number per product per location and writes it to every store that disagrees.

You will run one at least twice — once when you first link a group, and again whenever a store’s counts have drifted far enough that you would rather choose the answer than let the hourly check choose it for you.

The three sync runs

The Sync runs tab is where all of this lives. Only the main store can start a run; every store can watch, because a run changes every store’s stock. A partner sees the run cards and a line saying who starts them.

Run	What it does	When to use it
Build index	walks every store’s catalogue and matches products by SKU	after linking a store, and after a big catalogue change
Settle	sets every store to one chosen number per product per location	after linking, and whenever you want to choose the numbers yourself
Hourly check	runs by itself, once an hour, and corrects unexplained differences	automatic. You never start it by hand. It only runs once the group is syncing live

Build the index before you settle — a settle can only act on products it knows are shared.

The three settle modes

Pick one in the Settle to dropdown, then press Settle stock.

The main store’s counts

Every store is set to the main store’s current stock. The simplest option and the right one when the main store is your operational source of truth.
The lowest count in the group

Every store is set to the lowest count across the group, per location. Conservative: it never leaves you promising stock you might not have.

One caveat — if a store cannot be read (its plan lapsed, it uninstalled, Shopify refused), that product is skipped entirely rather than settled from a partial set. “The lowest of the stores we could reach” would not be the lowest.
The uploaded worksheet

You download a spreadsheet, edit the target numbers, and upload it back. Use this when the right answer is neither store’s current figure — after a physical count, or when you know one store’s numbers are stale.

This option stays greyed out until you have uploaded a worksheet that parses cleanly. Uploading a good one selects it for you.

The worksheet, step by step

Run a build index. The worksheet is generated from it, so it has to have run at least once. Until then the Download worksheet button is disabled and says so.
Download the worksheet. Sync runs → Download worksheet. The file is named for the run it belongs to, e.g. multi-store-worksheet-<run id>-2026-08-01.csv.

Open it. The columns:

Column	Meaning
SKU	the main store’s spelling
Location	which slot this row is about
Main available	what the main store holds there right now
Target	the only column you edit
Stores with this SKU	which stores carry it
Local SKUs	any store that spells it differently

There are also three lines at the top starting with #. Leave them alone — they tie the sheet to the run it came from.

Edit the Target column.

Target arrives pre-filled with the main store’s current count, so an untouched sheet settles every store to the main store’s numbers — the same thing “The main store’s counts” would have done. You edit the rows you want to differ.
- a number means “set every store to this at this location”;
- blank means “keep the main store’s value” — a real instruction, not a missing one. Clearing a cell is how you say “leave this one alone”.
One row comes down blank for a different reason: a product the main store holds a negative count of. Negative targets are refused, so that cell is left empty rather than pre-filled with a value its own upload would reject. The real figure is still in Main available beside it.
Upload it. Sync runs → Upload worksheet. Choose The uploaded worksheet in the Settle to dropdown (a clean upload selects it for you), then press Settle stock.
Read the validation report before it runs. The tab reports how many rows it read, lists anything it could not understand, and keeps the settle disabled until the file is clean — rather than running it half-understood. Warnings (such as blank targets) are shown but do not block.

Why the sheet is tied to one run

A worksheet is only meaningful against the run whose products it was built from. Uploading a sheet from another group, another run, or with the header lines stripped is refused before any stock is written. Without that tie you would have to retype the run id, and eventually you would retype it wrong.

If you have edited an old sheet, run a fresh build index and re-download rather than trying to make the old one fit.

Upload messages you might see

Message	Fix
”This worksheet is from run X, but the current worksheet run is Y”	download a fresh one
”This worksheet belongs to a different store group”	you are on the wrong store
”This file carries no run id”	the `#` header lines were removed — download again
”This file has no SKU column header” / “This file has no Target column”	the sheet was rebuilt by hand. Download again and edit only Target
”The worksheet has no rows” / “The file is empty”	nothing to settle
”Row 12: no SKU”	an empty SKU cell
”Row 12: X appears more than once for the same location”	duplicate rows; keep one
”Row 12: ‘4.5’ is not a whole number of units”	targets are whole, non-negative units
”n row(s) have a blank target — those SKUs keep the main store’s current value”	a warning, not an error
”The worksheet is n bytes and the limit is 1000000”	settle in filtered batches instead

What a settle actually writes

Only to stores that disagree with the target. A store already holding the right number is counted, not written.
Only to products that are Matched at that store, with verified ids.
Never to products that are ambiguous, not found, or deleted at that store.
One row on the Corrections table (bottom of the same tab) per store it wrote to, marked Settled, showing the before and after.

Every write is made against the value we just read, so a settle cannot silently overwrite a sale that lands mid-run: if the count moved between reading and writing, it re-reads and tries once more. If it moved again, that product is reported under Stock updates that failed rather than guessed at — re-run the settle.

Watching a run

The Sync runs tab polls every few seconds while a run is live and shows each run’s status, timings and counters. Large catalogues take several passes; that is normal and shown as progress, not as a problem. You can switch to another tab while a run is going — it keeps being watched.

A run that ends “Finished” can still have skipped a store. If one store could not be read, the run finishes for everyone else and reports it under Stores that could not be read — check the counters, not just the status badge.

If a run fails, a banner stays up until the next successful run of the same type. It cannot be dismissed; re-run it instead, which is the point. The banner quotes the run id — have it to hand if you contact support.

If a run gets stuck

Occasionally a run’s worker disappears mid-flight and the run sits there holding the lock, blocking new runs. The main store gets a Force this run to end button on the stuck run’s card, behind a confirmation.

Force-expiring does two things and no more: it releases the lock so you can start a new run, and it records that you did. It does not undo anything the run already wrote — those writes stand, and the next run of the same type re-walks and finishes the job. If the run was in fact still alive, whatever it had left to do is lost. So the sequence is always: force-expire, then re-run. The failure banner clears when the re-run succeeds.