An inventory tracking app stores events, not a number.
The number on screen in any inventory tracking app is a conclusion. What makes it trustworthy is whether the app kept the movements that produced it, so when the shelf disagrees you can find the receipt nobody entered rather than argue about theft. That is the same discipline that runs through other internal business apps.
This page is about the parts that decide whether counts match: counting method, the unit of measure trap that quietly breaks totals, and what a phone camera can and cannot do on a stockroom shelf.
See the mistake that breaks most totalsThe short version
Count little and often, and never mix cases with singles.
Cycle counting beats an annual stocktake for one reason: it finds the broken process while anyone can still remember what happened. An annual count tells you the size of a problem long after the cause has gone.
And most wrong totals are not theft. They are a case received as one unit and sold as twelve, with nothing in between converting one to the other.
The unit of measure trap
A supplier delivers a case of twelve. Receiving scans the case and adds one. The counter sells singles and removes one at a time. After a week the system says you have minus four of something you can see on the shelf. Nobody did anything wrong; the app simply had one field where it needed two.
This is not a local quirk. GS1, which administers the barcode numbering used across retail, defines trade items as products or services that are priced, ordered or invoiced at any point in the supply chain, and a case and a single are different trade items with different identifiers. If your app treats them as one thing, it is disagreeing with the numbering system printed on the box.
The fix is to store a base unit and a conversion, and to record every movement in the unit it actually happened in. It costs one extra field and it removes the single most common cause of counts that cannot be explained.
What each counting method actually finds
| Method | What it finds | Disruption | Fixes the cause |
|---|---|---|---|
| Annual stocktake | The total, once a year | Closes the operation for a day | No |
| Cycle counting | A few lines every day | Minutes per day | Yes |
| Count on receipt only | Supplier shortages | None | No |
| Perpetual with movement records | The movement that was missed | None, if entry is quick | Yes |
Try it
How far out is the count?
Put in what the shelf said and what the system said. The gap matters less than the pattern of gaps over time.
96% accuracy, -4 units
Drifting. This is the range where a missed movement is more likely than theft.
What a phone can realistically scan
A phone camera reads ordinary retail barcodes well in decent light, which covers most shop and small warehouse counting. It slows down on damaged labels, very small codes, frozen or shrink-wrapped goods, and on the specific job of counting several hundred items quickly, which is where a dedicated scanner still wins on ergonomics rather than on accuracy. Deeper detail on that trade-off sits in the barcode scanning for inventory page, and the consumer version of the same problem shows up in a home inventory app.
Whatever you scan with, keep fast manual entry next to it. Counts that cannot be finished get abandoned, and an abandoned count is worse than no count because it leaves the record half updated. If you want the mechanics of camera access, using the camera to scan codes covers it.
Where the count stops being an operational number
At some point in the year the stock figure leaves the shelf and enters the accounts. That is the moment the tolerance changes: a count that was good enough to reorder from is now part of how profit is calculated, and the rules are no longer yours to set.
United States tax regulations require that an inventory conform as nearly as may be to the best accounting practice in the trade or business, and that it clearly reflect income. The regulation is also explicit that consistency matters more than the particular method: greater weight is given to being consistent from year to year than to any single basis of valuation. For an app, that translates into something concrete. Whatever rule you use to value stock, the app has to apply it the same way every period, and has to be able to show what the figure was on a given date.
The practical consequence is that you cannot only store the current quantity. You need the movements that produced it, with dates, because a year-end figure that cannot be reconstructed is a figure an accountant has to take on trust. Storing events rather than totals costs almost nothing while you are building and is close to impossible to add afterwards.
Locations that are not shelves
Most inventory systems assume stock sits in a place with an address. Real operations hold stock in vans, in a customer's building waiting to be installed, at a subcontractor, and in the gap between despatch and delivery. Every one of those is stock you own and cannot see, and every one of them is where counts go wrong.
Modelling a location as a type rather than a shelf solves most of it. A van is a location that moves. A job site is a location that closes when the work is signed off. Consignment stock is a location you own the contents of but not the building. Once locations can be anything, a count is a count wherever it happens, and the awkward cases stop needing a spreadsheet of their own.
In transit is the one people leave until last, and it is the one that causes the arguments. Stock that has left one location and not arrived at another has to be somewhere, or your total drops for two days every time you move a pallet. Give it a location and the total stays honest.
Building one around your own stock
Packaged inventory systems assume a shape: you own what you hold, a location is a shelf, and a product is one thing with one unit. Plenty of real operations break at least one of those. Consignment stock, vans as locations, lot numbers that matter for recall, or a product sold in three different units are all common and all awkward to bolt on afterwards.
Newly is an AI app builder: you describe the app, including how your stock actually behaves, and it builds and ships a real mobile app you own. Plans start at $25 a month, there is no free plan, and iOS builds ship through App Store Connect. It is not an inventory product and does not compete feature for feature with one. It is what you use when the inventory product cannot hold your model.
Questions people ask about inventory apps
An inventory tracking app records what stock you hold, where it is, and every movement in and out. The useful ones do not just store a number; they store the events that produced it, so when the count on the shelf disagrees with the number on screen you can see which movement was missed.
Describe the stock you actually hold
Units, locations, and the awkward case that no system supports. Build the app around that instead of around a template.
Start building