How to build a barcode scanning app for inventory,
one movement at a time.
A good barcode scanning app for inventory starts with how stock actually moves, not a scanner bolted onto a spreadsheet. It needs a scan that identifies the right item, a cycle-count schedule that doesn't require shutting the warehouse down, and a record of every movement precise enough to trust. This page covers what cycle counting actually means versus a full physical inventory, how GTIN, UPC, and QR codes differ for scanning, what a stock movement record needs to hold, and where this fits inside the wider category of internal business apps that ops and warehouse teams run their day on.
The short version
Two ways to count, five fields to log.
Cycle counting and a full physical inventory are not competing methods, most operations run both. The scanning app's job is to make the ongoing one painless and make every movement it logs trustworthy enough to stand in for the annual one.
Ongoing
Cycle counting
A rotating subset of locations, counted while the warehouse keeps running.
1–2x a year
Full physical inventory
Everything counted at once, usually with normal work paused.
5 fields
A trustworthy movement record
What, when, where, why, and how, per GS1's EPCIS standard.
Counting methods
Cycle counting vs. a full physical inventory.
A lot of inventory app marketing treats these as the same activity at different sizes. They're not, they solve different problems, and a scanning app should support both.
What cycle counting actually is
The Association for Supply Chain Management (ASCM, the body behind the APICS credentials) describes a cycle-count schedule as counting a subset of locations every day rather than shutting the building for a full physical inventory, usually driven by ABC analysis, the practice of counting high-value or fast-moving items more often than slow ones. Nothing stops, a warehouse worker counts a handful of bins between other tasks, and the schedule cycles through the full item list over weeks or months.
When you still need a full physical count
ASCM's own framework for inventory control splits systems into periodic and perpetual inventory: periodic counts physical inventory at a recurring interval, often monthly, quarterly, or annually, while perpetual inventory tracks stock continuously in near-real time as transactions happen. Cycle counting is what perpetual tracking is checked against; a full physical count is still the periodic backstop most accounting and audit processes expect at least once a year, even in an operation that cycle counts constantly.
| Cycle counting | Full physical inventory | |
|---|---|---|
| Disruption to normal operations | Warehouse keeps running while it happens | Usually means pausing normal work |
| Frequency | Ongoing, on a rotating schedule | Typically once or twice a year |
| Coverage in one pass | A subset of locations or SKUs | Everything, all at once |
| What decides who gets counted | Often ABC analysis, counting high-value or fast-moving items more often | Nothing to decide, every item is in scope |
| What it's good for | Catching and fixing record errors continuously | A single accurate snapshot for accounting or audit |
Sources: ASCM on cycle counting and ABC analysis and ASCM on periodic vs. perpetual inventory.
Barcode basics
GTIN, UPC, and a barcode aren't three different things.
A mobile app for barcode scanning only needs to know two things about a code: what it can hold, and how reliably a phone camera can read it. Per GS1, a GTIN (Global Trade Item Number) is the underlying product identifier, and a barcode is just the visual, scannable representation of that number. UPC (GTIN-12) is a 12-digit format mostly used in North America; EAN (GTIN-13) is a 13-digit format used mainly in Europe and the rest of the world. They're not competing standards, UPC and EAN are regional formats of the same GTIN system.
12–13 digits
UPC-A / EAN-13
Numeric only, the format retail products already carry.
A–Z, 0–9
Code 128
Letters and numbers, for SKUs with no GS1 barcode.
2D
GS1 QR code
Holds a link or batch data, not just a number.
| Barcode type | What it encodes | Best for | Scanning in practice |
|---|---|---|---|
| UPC-A / EAN-13 | Numeric only, 12 or 13 digits | Retail products that already carry a GS1 barcode | Reads fast with almost any camera or laser scanner |
| Code 128 | Letters and numbers, variable length | Internal SKUs, lot numbers, or bin labels with no GS1 barcode | Needs a clear, reasonably well-lit line of sight |
| GS1 QR code (2D) | Letters, numbers, and links, variable length | Attaching more than a number, a batch, an expiry date, a web page | Tolerates odd angles and partial damage better than 1D codes |
Source: GS1 on barcode and GTIN types. Most warehouses end up mixing them: GS1 barcodes on anything that arrived from a retail supply chain, and an internal code 128 or QR label printed in-house for bins, lots, or SKUs that never had a GS1 barcode to begin with. If your endgame is a spreadsheet rather than a full app, the narrower build is covered in our scan barcode to excel app guide. Wiring the scan itself, camera permissions, decode speed, and what happens when the camera can't get a clean read, is its own topic; see camera-based scanning in mobile apps for how that actually gets built. This page stops at the product and inventory logic around the scan, not the scan itself.
Which barcode fits your items?
Select what's true for your inventory and see which format comes out ahead.
Select whatever applies to see a recommendation, or use the table above on its own.
The record
What a stock movement record needs to hold.
A scan that only updates a total is a shortcut that costs you later. GS1's EPCIS standard, built specifically for tracking movement and chain of custody, frames every event around five dimensions: what, when, where, why, and how. A stock movement record modeled the same way holds up when someone asks why a count is off.
| Field | Why it matters | Example |
|---|---|---|
| What | Which SKU or batch moved, not just that something changed | The item's barcode/GTIN, or a lot number for a batch |
| When | A timestamp orders events and should be captured automatically, not typed | The device clock at the moment of the scan |
| Where | The location stock moved to or from, so a count means more than a global total | Bin, shelf, warehouse, or site tied to the scan |
| Why | The business reason for the movement, so the number is explainable later | A reason code: receiving, picking, cycle-count adjustment, return |
| How | How the event was captured, since a scan and a manual entry carry different confidence | Barcode scan, RFID read, or manual count |
Does your current system capture all five?
Check off what your spreadsheet or app already logs on every movement.
The missing fields are usually the first thing to fix, they're what turns "the count is off" into something you can actually explain.
Try it
How many counts a day does that schedule need?
Split your item list into three tiers by how often you want to count them, the classic ABC pattern is high-value or fast-moving items counted often and slow movers counted rarely, then see roughly how many scans a day that schedule adds up to. Adjust the numbers to match your own warehouse.
Tier A (high-value or fast-moving)
240 SKUsTier B (medium priority)
360 SKUsTier C (everything left over)
600 SKUs · 50%Counts per year
19,200
Item-counts across all three tiers, combined
Average per workday
76.8
Assuming roughly 250 working days a year
The options
Paper, a scanner app, or an inventory management app for small business.
Most small operations start on a spreadsheet, add a free barcode-lookup app once typing SKUs by hand gets slow, and only consider a custom app once the workflow, cycle counts, movement history, multiple locations, stops fitting inside a generic scanner. The same build logic shows up in adjacent categories too, a heavy equipment inspection app doesn't track SKU counts, but the underlying idea, a scan tied to one specific record instead of a blank form, is identical.
| Paper / spreadsheet | Free scanner app | Inventory software | Custom-built appBest fit | |
|---|---|---|---|---|
| Works with no signal, in a basement or a metal warehouse | Yes | Depends on the app | Depends on the vendor | Yes |
| Ties a scan to your own item fields, not a generic template | Yes | No | Limited to their schema | Yes |
| Logs a full movement record: what, when, where, why, how | No | Rarely | Yes | Yes |
| Cycle-count scheduling by your own ABC tiers | No | No | Usually | Yes |
| No per-seat fee as your team grows | Yes | No | No | Yes |
| Matches a workflow that doesn't fit a category template | Yes | No | No | Yes |
In practice
Building your own, four steps.
The counting method and the record fields above are the substance. This is the shape a scanning app puts around them, from a blank item list to a schedule that runs on its own.
01
Start from your item list, not a template
Describe the fields your inventory actually needs, SKU, size, location, reorder point, instead of adapting someone else's schema to fit.
02
Add the scan
A barcode scan should look up an existing item or offer to create one, and it should work whether the code is a retail UPC or an internal Code 128 label you printed yourself.
03
Log the movement, not just the new total
Every scan writes a record: what, when, where, why, and how, so a quantity change six months from now is still explainable.
04
Set a cycle-count schedule
Group items into tiers and rotate through them on a schedule that doesn't require shutting anything down, then run a full physical count as a periodic backstop.
Why teams build their own
When a generic scanner stops fitting.
Newly is not inventory management software and isn't trying to compete feature-for-feature with dedicated warehouse systems. It is an AI app builder: you describe the inventory app you need, in plain English, and it builds a real native iOS and Android app around it, with a database for your item list, locations, and every scan logged as a movement record. Teams reach for it once their fields, their cycle-count tiers, or their barcode mix, GS1 codes on some items and internal Code 128 labels on others, stop fitting inside someone else's template.
Newly starts at $25 a month, and that includes building the app itself, the backend that stores every item and every movement, and publishing it to the App Store and Google Play.
FAQ
Barcode scanning apps for inventory, answered.
A barcode scanning app for inventory is a mobile app that uses a phone's camera (or a paired scanner) to read a product's barcode, look up or create a record for that SKU, and log a quantity change, a cycle count, or a movement between locations. The scan is the input; the part that actually makes it an inventory app is the record behind it, a database that tracks on-hand quantity, location, and the history of what moved, when, and why.
Build the scanning app that fits your inventory.
Describe the items you stock and how you already count them. Newly builds the app, the database behind it, and gets it ready for the App Store and Google Play.