Inventory Count App: Counting Stock by Camera

The honest headline first: if the item has a barcode, scan the barcode. Nothing in this article beats that, and a guide that pretends otherwise is selling you something.

Decoding a printed pattern is a fundamentally easier problem than recognising printed characters. The widely-quoted industry figures — one error in roughly 300 keystrokes for manual entry against something on the order of one in a million-plus for barcode scanning, both traced back to a US Department of Defense study that is cited far more often than it is linked — are repeated so freely in trade literature that the exact numbers should be treated with suspicion. The direction of the gap is not in doubt. A barcode is a self-checking encoding read by a device built for one job; a photograph of a printed number is a guess about shapes.

There is more in the barcode than most people use, too. A GS1-128 label encodes fields tagged by application identifier: (01) is the GTIN, (10) the batch or lot number, (17) the expiry date as YYMMDD, (21) the serial. If you can see those bracketed numbers printed under the bars, the data you are about to photograph is already sitting in the barcode beside it. The distinction between a pattern you decode and text you recognise is worth being clear about, and scanning a barcode against reading a printed code works through it in a different setting.

So this is about the rest: the stock that has no barcode, the label where the barcode has been scuffed off, the handwritten tally, the asset tag stamped into metal.

The shape of the job changes the tolerance

Three different tasks get called stocktaking, and they do not need the same accuracy.

A full physical count reconciles everything against the system on a single date. It is slow, it is usually annual, and a single wrong quantity distorts a valuation. Cycle counting walks a subset every week, so errors surface repeatedly and get corrected; a mistake here is embarrassing rather than expensive. Goods-in is the one where reading matters most, because a part number entered wrongly at receipt propagates into every subsequent transaction, and nothing downstream will question it.

Match the effort to the task. A cycle count of fast-moving consumables does not warrant photographing every label. A goods-in receipt against a purchase order does.

Where the errors actually enter

Not at the shelf. People are good at counting things they can see. The errors enter at the moment a number moves from one medium to another — off a label onto a clipboard, off a clipboard into a system — and they are transcription errors, not counting errors.

That is the case for photographing the label rather than copying it: the transcription step is where the risk lives, so removing it removes the risk. It is also the case for the oldest control in the trade, the blind recount. One person counts, a second recounts without seeing the first figure, and only the discrepancies get investigated. It costs a second pass and it catches the class of error that no amount of careful reading catches, because a careful reader who is confidently wrong stays confidently wrong on a second look at their own numbers.

What makes a label read badly

What you are photographing	Why it reads badly	What helps
Laminated or shrink-wrapped label	A specular highlight burns the strokes out entirely; there is no data left to recover	Move off-axis, or move the light. A flash aimed straight at gloss makes it worse
Curved surface — drum, can, bottle	Perspective distortion, which engines correct far less well than they correct rotation	Square up to the centre of the text and take one line at a time
Dot-matrix or dot-peen marking	The digits are unconnected dots, so character segmentation splits them apart	More pixels. On peened metal, light it obliquely so the dimples cast shadows
Faded thermal label	Contrast collapses as the coating ages, and there is nothing to sharpen	Diffuse light, no flash. Sometimes the honest answer is to retype it
Kraft card or brown corrugate	Low contrast between ink and substrate, made worse by texture	Get closer rather than brighter
Handwritten tally sheet	Handwriting confusions: 2 for Z, 6 for G, 7 for 1	Read it back against the sheet. This is where a second person earns their keep

Most of these come down to one thing: how many pixels of character height reached the sensor. Why OCR gets numbers wrong covers the threshold in detail, and the short version is that below about ten pixels of character height there is very little chance of an accurate read, and below eight the text is discarded as noise before recognition begins.

Zoom is for aim, not for resolution

This is worth separating because it is regularly confused.

Zooming before the shutter adds real detail: the same digits occupy more of the sensor. Enlarging after capture adds nothing — upscaling invents pixels rather than recovering information, and no sharpening pass restores what was never sampled.

Zoom inside an app is a third thing again, and it is genuinely useful for a different reason. SwipeScan lets you pinch the captured image between 0.5× and 3.0×, which is not about resolution: it is about aiming. The app recognises only the region you paint over with your finger, so on a dense label — part number, lot code, quantity and a supplier reference stacked within a centimetre — zooming in is how you get the stroke onto the lot code and nothing else. That selectivity is the difference from a general reader that hands back the whole label and leaves you to find the field you wanted.

The honest limits

Three of them, and they decide whether a phone fits your process.

No barcode scanning. A text reader reads text. Where a barcode exists, a barcode scanner is the correct tool and it is not close.

No batch mode. Items go through one at a time. For fifty SKUs that is fifty passes, which is fine for goods-in and painful for a full count.

No file export. Output is the clipboard, the system share sheet, and a local history of every recognition kept on the device with a timestamp, newest first. That history is what makes a sequence of items workable — you can walk a shelf and reconcile afterwards rather than switching apps between every item — but if what you need at the end is a CSV, you are assembling it yourself.

Weigh that against the alternative honestly. If you are counting more than a few dozen lines regularly, a dedicated inventory system with a Bluetooth scanner will pay for itself, and a phone camera is a stopgap.

Getting the numbers into a sheet

Whatever reads the label, the figures end up in a spreadsheet, and that is its own hazard. Quantities with thousands separators land as text and stop summing; part numbers with leading zeros lose them; long asset tags run into the fifteen-significant-digit ceiling. Numbers that land in a cell as text covers the checks that catch those before a valuation is built on them.

For the single awkward label — the one the scanner will not take — pulling only the digits out of an image in the browser is quicker than installing anything, and because it restricts recognition to numerals, the unit labels and supplier text around the figure never reach the output. Where the code you need is alphanumeric, a general reader serves better; the digits-only tool is deliberately narrow.

The short version

• Where a barcode exists, scan it. A GS1-128 label already carries the part number, batch and expiry as tagged fields.
• Errors enter at transcription, not at counting. Removing the retyping step removes most of the risk; a blind recount catches the rest.
• Glare, curved surfaces and dot-matrix marking are the three things that ruin a label photograph, and glare is unrecoverable.
• Zoom before the shutter for detail; zoom inside an app to aim a selection. Enlarging afterwards adds nothing.
• A phone has no batch mode and no export. Past a few dozen lines a week, a proper scanner and system is the cheaper answer.