Help · Updated 22 October 2026

Offline mode and syncing

Scanning, counting and recording movements all work with no signal, including a sale with its price and note. The home screen shows how many changes are waiting to sync; when the connection returns they are sent once, and each carries its own id so a retry cannot duplicate a movement. Transfers, invites and billing need a connection.

A stockroom is often the worst place in the building for signal: thick walls, a basement, a cold room with a metal door. Offline mode exists for that room, not as a bonus feature. The rule is simple — recording stock does not wait for a connection, and the shop tells you honestly what has not been sent yet.

What works with no signal

• Scanning. A known barcode opens that item; an unknown barcode opens the New item form with the code filled in.
• Counting. A blind count runs to the end offline. Leave a line empty to skip it, close the app mid-count, and the draft resumes at the next uncounted item.
• Recording movements. Receiving a delivery, a sale, waste, a correction and a return are all recorded locally with their actor, device and time, and wait in the outbox.
• A sale with detail. A sale typed offline keeps its price and its note, and replays once when the connection returns.

Everything you record offline is written as the same kind of movement it would have been online. Offline is not a second, weaker ledger that gets merged later; it is the same movement, waiting.

The waiting-to-sync badge

The home screen shows a count in plain words: N waiting to sync. That number is your only reliable answer to "did that save?" — not a green tick you think you saw, and not the speed of the screen.

• It goes up by one for each change you record while offline.
• It goes down as changes are accepted by the server.
• It is per shop. If your account belongs to more than one shop, changes waiting in one shop are not counted in the other.

A badge that sits at zero means everything you recorded has reached the server. A badge that is not moving while you have signal is the one case worth investigating — see below.

What happens when the connection returns

Queued changes are sent once. Each one carries its own id, generated on the device, and the server refuses a second copy of an id it has already seen. That is what makes a retry safe: a dropped connection during sending, a phone that sleeps, a flaky signal that reconnects four times — none of them can turn one received delivery into two.

The same idea protects a count. A count submitted twice — a retry after a dropped connection, or an impatient second tap — is reported by the server as a duplicate and writes nothing the second time. You may see the duplicate message; it is not an error in your count, it is the server telling you the first submission already landed.

If stock changed while you were counting, the review says so and keeps that receipt in the ledger. Counting offline does not make the shop forget what happened online in the meantime.

What needs a connection

Transfers need a connection because they are one paired movement across two locations: the server has to check that the source location actually holds the quantity before it moves it, and that check cannot be made on a phone that is out of contact. A transfer that refused to move more than the source holds is the feature working, not failing.

When something is rejected permanently

Some changes cannot succeed no matter how many times they are retried: a permission error, for example, when a staff member's device tries to change a price. Those are surfaced, not silently dropped. The app tells you which change was refused and why, and the change does not sit in the queue pretending it will work later.

Treat a permanent rejection as information about the shop, not about the network. Fixing the cause — asking a manager to make the change, or correcting the item — is the only thing that makes it go away. Re-entering the same change repeatedly just produces more refusals.

If the queue looks stuck

Before you touch any data, do these in order. They are cheap and they resolve most cases.

1. Open the app and leave it open for a minute on a known-good connection. Sending happens in the background and a phone that is asleep keeps the queue waiting.
2. Check the badge again. If it moved, the queue is working; let it finish.
3. Read what the app says about the waiting changes. A permanent rejection is named there and will never clear on its own.
4. If a change is genuinely refused, do not enter it a second time to force it through. Entering it again is a second movement, and the ledger will record both.
5. Do not uninstall the app or clear its data while changes are waiting. They have not reached the server yet, and the queue lives with the app.
6. Do not change the item — its quantity, its price, its location — to "help" a stuck change. If the change later lands, you will have two edits to explain instead of one.

The safe move when you are stuck is to write down what you did and when: the item, the quantity, the time and the device. That record lets support find the movement in the ledger whether the queued change arrives or not. Email[email protected] with it rather than re-entering the work a third time.

What it does not do yet

• No conflict resolution screen. If two people change the same item while one is offline, the movements both land and the ledger shows both; the app does not ask you to pick a winner.
• No background sync guarantee. The queue sends when the app runs with a connection; it is not a system service that wakes itself.
• No offline transfers, and no offline invites or plan changes.
• No per-device queue view. You see the count of waiting changes, not a list you can edit or delete before they send.
• No offline sign-in on a device that has never signed in.

Start the 14-day trialAll help articles