Help · Updated 22 October 2026

Counting stock

A count is blind: the expected quantity stays hidden until the review, and each line you count becomes one movement when you submit. Leave a line empty to skip it — a skipped item keeps its current stock and never becomes zero.

Counting is the job the software has to stay out of. In Mobile Inventory a count is blind by default: while you are counting, the expected quantity is not on the screen. It appears only in the review, beside what you actually counted. That one decision removes the strongest reason a count comes out wrong, which is people agreeing with the number the screen already showed them.

The rest is the working method: start, skip, resume, read the variance, and submit safely.

Before you start

• Count one location at a time. A count belongs to a location. Mixing the stockroom and the shelf in one pass makes every variance harder to explain.
• Count in the unit you sell in. If the item is sold by the bottle, count bottles, not cases. A unit that does not match the item is the most common cause of a variance that looks like theft.
• Start from Count. The count is a draft from the moment you open it, so there is no separate save step to remember.
• Check battery and signal, then forget them. On the phone app, counting works with no signal; changes wait in the outbox.

Run a blind count

1. Open Count and start a count for the location you are standing in.
2. Take the first line and count what is physically there. Type the number. The expected quantity stays hidden, so there is nothing to agree with.
3. Move to the next line. Work in the order that matches the shelf in front of you, not the order of the list, if that is faster. The list is a checklist, not a route.
4. Leave a line empty when you cannot count it. Do not type a guess to clear the row.
5. Open the review when the lines are done, read the variance, and submit.

An empty line is not a zero

This is the rule that protects the ledger. Leaving a line empty means "not counted". It does not mean "none left". The item keeps its current stock, and the review states that plainly before you submit, so an empty row is never quietly turned into a stockout.

If an item really is empty, type 0. That is a counted line, it becomes a movement, and the variance will show the full difference. The distinction between "I counted zero" and "I did not count this" is the difference between a useful ledger and a fictional one.

Close the app and come back

Counting gets interrupted. A customer arrives, the phone rings, the shop opens. Close the app and the draft stays a draft. When you open the count again it resumes at the next uncounted item, so you do not have to remember where you stopped or scroll back through lines you have already done.

Resuming is safe because nothing has been written yet: a draft is not a set of movements, and the ledger changes only at submit.

Read the variance before you submit

The review lists every line with what you counted, what the app expected, and the difference between them. It also names the biggest gap in the item's own unit, which is usually where the mistake is: a case counted as a bottle, a delivery that was never received, a return that went back on the shelf without a movement.

Work down the list and ask one question per line: is this difference real? A large variance is not automatically an error, and a small one is not automatically fine. What matters is that you saw it before it became history.

If stock moved while you were counting

Stock can change during a count. Someone records a sale, receives a delivery, or adjusts a damaged item while your draft is open. When that happens, the review says so. The movement that happened during the count stays in the ledger as its own receipt, so the count does not erase a real event and the two records can be read side by side.

Submit once

Submitting turns each counted line into one movement, recorded with the actor, the device and the time. That is what makes a count auditable later: the number is not just a new value, it is an event with a person and a moment attached.

Retries are handled on the server. If the same count is submitted again, for example after a dropped connection makes the first attempt look like it failed, the server reports the second attempt as a duplicate and writes nothing. You do not have to decide whether the first submit worked; submitting again cannot double the stock.

Scan instead of typing

Scanning during a count fills that line. On a phone, point the camera at the barcode. With a Bluetooth scanner in keyboard-wedge mode, or a USB scanner on the web, scan as you would at a till. This is the fastest way through a shelf of packaged goods, and it removes the typing mistakes that make a variance look mysterious.

A scan only fills a line that exists. An unknown barcode is not silently added to the count; it opens the New item form, which is a decision you should make deliberately rather than in the middle of a count.

Count history

Past counts and their variance are available on the web under Counts. Use it to answer the question that follows every count: was this a one-off mistake, or is the same item drifting every month? A repeated variance on one line is a process problem — a unit, a supplier, a receiving step — not a counting problem.

What it does not do yet

• No multi-counter sheets. You cannot split one count across several people working from separate sheets and merge them.
• No per-line "counted by". The count records who submitted it, not who counted each line.
• No second-person review. There is no approve or reject step by another person. One person runs a count from start to submit.

If two people must count today, one counts and one reads the variance inCounts afterwards — a conversation, not a built-in approval.

Start the 14-day trialAll help articles