What is an inventory accuracy system, and how is it different from the stock figure in my ERP?

It is the combination of process, counting method and software that keeps recorded quantity equal to physical quantity. The ERP holds the book figure; an accuracy system covers cycle counting, variance tolerances, audit trails and reconciliation. Accuracy is measured as record accuracy rate — the share of SKUs whose counted quantity matches the system within tolerance.

How do we know stock accuracy has become a real problem worth fixing?

When stockouts and oversells appear on items the system says are in stock, or write-offs keep recurring. A common trigger is inventory record accuracy sitting below roughly 95% on fast-moving SKUs. Pull a variance report from recent cycle counts; if the same SKUs fail repeatedly, the process, not the counter, is at fault.

What do we need before starting a stock accuracy project — hardware, data, anything else?

Clean SKU and unit-of-measure data first: duplicate SKUs and mismatched UoM conversions cause most false variances. Then barcode labels on bins and items, a scanning device or phone app, and a count frequency defined per ABC class. Back up the item master before bulk edits, and run the first count as a read-only exercise.

How does cycle counting work, and why not just do one full physical count a year?

Cycle counting counts a subset of SKUs on a rolling schedule — typically A items weekly or monthly, C items quarterly — so errors surface while the cause is still traceable. A single annual count finds the variance but not its origin, and usually needs operations frozen. ABC ranking by value and movement sets the frequency.

How do you reconcile counts without stopping the warehouse?

Count inside a freeze window per bin or location rather than across the whole site. Record receipts and picks that happen during the count against a timestamp cutoff, and post adjustments only through an approved variance workflow. Offline-capable apps queue scans locally and sync, so poor connectivity does not halt counting. Sync conflicts need a defined rule and an exception queue.

What usually makes the counted stock drift away from the system?

Unrecorded receipts and returns, unit-of-measure errors, backdated or late-posted transactions, kit or bundle components not exploding correctly, and duplicate SKUs created when the same product is entered twice. Theft and damage are real but usually smaller than process error. Compare transaction timestamps against count timestamps to isolate posting lag.

How do we verify an accuracy fix actually worked?

Re-count the same SKUs after the change and compare variance. Track inventory record accuracy over time and the adjustment value per period — both should trend down. Sample-check a known bin independently of whoever counted it. If variance moves to a different SKU group, the root cause shifted rather than disappeared; investigate before declaring success.

Who should be able to change a stock figure, and what should be logged?

Restrict adjustment rights by role, require a reason code, and separate counting from approving. Every adjustment should write an immutable audit record: user, timestamp, SKU, location, old and new quantity, reason. Without that separation, staff can mask shrinkage. Review the adjustment log monthly — unusual concentration by user or SKU is the signal.

Should we build this ourselves, or use an existing inventory or ERP module?

If you run WooCommerce, Shopify or an ERP, extend it with a scanning app and a counting workflow before building a separate system — two sources of truth is the failure you are trying to fix. Build custom when counting rules, multi-location logic or integrations genuinely do not fit. Our team can scope that at /contact.

What drives the ongoing cost and effort of an accuracy system?

Counting labour scales with SKU count and frequency, so ABC classification keeps it proportionate. Other drivers are hardware per location, scanner or app licensing per user, integration work when a sales channel or ERP changes, and the time spent investigating variances. Cloud costs depend on transaction volume and how long you retain audit history; check current vendor pricing.

Inventory Accuracy System: Make Stock Counts Match

Stock counts that match what is on the shelf

An inventory accuracy system keeps the number in your software equal to the stock on the shelf. It records every movement at the moment it happens, then reconciles the gaps on a fixed schedule. Reaching the high nineties comes from three things: scanning where stock moves, cycle counts instead of one annual stocktake, and a written variance process.

Key Takeaways

Counts drift because the system only knows what someone remembered to tell it. Fix the capture points first, then the counting routine, then the reporting. The order matters — better dashboards on top of bad data just make the wrong number arrive faster.

Accuracy is a process problem before it is a software problem. No system repairs an uncounted delivery.
Scan at the point of movement: goods-in, pick, sale, return, write-off. Every manual keying step is a leak.
Cycle counts beat annual counts. Count a small slice of SKUs weekly by ABC class instead of shutting the shop once a year.
Hide the expected quantity from the person counting. Blind counts remove guessing and the arguments that follow.
Give every variance a reason code, or you will recount the same SKU forever.
Keep an append-only movement ledger. On-hand stock is a sum of movements, never an editable field.

The four stages every trusted stock number passes through: capture the count, compare it to the ledger, explain the variance, then post and recheck.

What does an inventory accuracy system actually do?

An inventory accuracy system records stock movements as events and derives the on-hand quantity from them for each location. It covers receiving, put-away, transfers, sales, returns and write-offs, then compares that derived number against counted reality on a schedule you choose.

The word derives is doing the work there. Most broken setups store one balance per SKU and let a dozen screens edit it — a till, a spreadsheet, an admin page, a marketplace sync. Nobody can say which edit was wrong. A movement ledger gives you a history you can read backwards.

Why does stock drift away from what's on the shelf?

Stock drifts because movements happen in the physical world before they reach the software, and some never reach it at all. A delivery signed for at four in the afternoon and entered the next morning leaves a gap that never closes by itself.

The leak points are predictable:

Goods received against a paper note, keyed in hours later, or not at all.
Damages, samples and staff purchases removed without an adjustment.
Returns restocked to the wrong SKU because the label was unreadable.
Counter and online store decrementing separate stock files.
Transfers between locations that only one side records.

None of those are database problems. They are capture problems, which is why buying software first rarely moves the number.

When do you actually need one — and when is a spreadsheet fine?

You need a system once more than one person moves stock, or once the same SKU sells through two channels. A single-location shop with one counter can run on a spreadsheet for years, until a second till or an online store appears.

Three practical triggers: you are overselling online, staff keep a private tally because they do not trust the system, or month-end stock value takes more than a day to work out. Below that line, a tidy spreadsheet and a weekly walk-through of your top twenty SKUs is genuinely enough — and cheaper to operate.

How does the system work under the hood?

The database stores movements, not balances. Each row carries a SKU, a location, a quantity, a reason code, a timestamp and the user or device that created it. On-hand stock becomes a query, and a scheduled job compares it against the last counted snapshot.

A minimal version looks like this:

SELECT sku, location_id, SUM(quantity) AS on_hand
FROM stock_movements
WHERE posted_at <= now()
GROUP BY sku, location_id;

Two details keep it honest. Movements are append-only, so a correction is a new row with a reason code rather than an edit to history. And the count itself is a movement, so there is one timeline for everything that ever changed the number.

How do you set one up, step by step?

Start with the items, not the software. A clean item master with one record per physical SKU, a barcode on every shelf location, and a settled unit of measure has to exist before any counting tool can be trusted.

Clean the item master. One record per sellable SKU, no duplicates, correct unit of measure, a barcode that scans first time. Slow, and not optional.
Map your locations. Aisle, rack and bin codes, a printed label per bin, and one designated spot for stock that has arrived but not been put away.
Choose capture devices. A rugged Android scanner or a phone app for receiving, picking and counting. Test one device in your own aisles before buying twenty. The Android developer documentation covers the scanning APIs if you are building rather than buying.
Freeze and count everything once. Stop sales and receiving, count blind, post the result as your opening balance. Do it on a quiet day.
Switch on the ledger. Every receipt, pick, transfer, sale and return writes a row. Remove direct edits to the balance field.
Wire the channels together. Till, online store and any marketplace must decrement the same ledger. Our notes on inventory integration for an online store cover where that sync usually breaks.
Schedule cycle counts. Split SKUs into A, B and C classes, then count A weekly, B monthly, C quarterly. Ten minutes a day beats a weekend shutdown.
Publish a variance report. Weekly, by location and reason code, to whoever owns the stock. A report nobody reads is a hobby, not a control.

Which configuration actually changes accuracy?

Three settings move your accuracy more than anything else: whether the expected quantity is hidden during a count, whether the till is blocked from selling negative stock, and how returns and damages get posted. Get those wrong and no amount of reporting will save the count.

Then the quieter ones. Set a tolerance, a variance small enough to accept without investigation, so nobody chases a one-unit difference on a low-value SKU. Decide how weighed goods are stored, because decimal and rounding rules create more phantom variance than theft does. And keep daily snapshots in one timezone, or a report run at 9am will disagree with one run at 6pm.

How do you verify the counts are right?

Verify with a blind recount by a second person, never with the system's own figure. Track two numbers weekly: unit accuracy, the counted units that match expected divided by total counted, and line accuracy, the share of SKUs with zero variance.

Watch the trend, not a single result. A dip in A-class line accuracy after a new hire joins the receiving desk tells you exactly where to look. Our frequently asked questions cover the shorter version of what clients ask us about this.

How each counting routine maps to the stock it suits — cycle counts for fast movers, full counts for the annual baseline, blind counts to remove bias, a live ledger to stop the drift at the source.

Why do counts drift again after a good count?

Accuracy decays from the first uncounted movement after the count. Receiving keyed in from a paper note, a damaged unit binned without a write-off, a refund processed at the till without restocking — each one reintroduces exactly the gap the count just closed.

When a SKU goes wrong, debug in this order:

Pull the last thirty movements for that SKU and read them in time order. Most gaps are visible in the first ten lines.
Look for double-posted receipts — the same delivery entered by two people.
Check whether the channel sync job failed silently. A queue that stopped draining looks identical to theft.
Check the negative-stock flag. If the till sold stock it did not have, the error surfaces somewhere else.
Only then suspect physical loss, and compare CCTV times against movement timestamps.

Why accuracy decays between counts: each unreconciled movement compounds, and the annual stocktake only measures the damage after it is done.

What does it cost to run, in money and attention?

Costs come from three places: devices and software licences, the staff hours spent counting instead of selling, and the engineering time to wire the ledger into your till, online store and accounting. Hardware is usually the smallest of the three.

Inventory tools are commonly licensed per user or per device each month, and the figure depends on whether you need batch tracking, multi-location transfers or purchasing built in. Confirm current numbers on the vendor's own calculator before you commit. The recurring cost that surprises people is attention: a cycle-count routine needs a named owner, and without one it stops within two months.

What should you watch on the security side?

Stock systems hold two sensitive things: prices and the ability to write off inventory. Anyone who can post an adjustment can move value out of the business, so adjustment rights belong to a small group, and every adjustment needs a reason code and an audit trail.

The quieter risks are shared logins on a shop-floor scanner, offline queues holding unsent counts on a device that walks out of the building, and backups nobody has ever restored. Test a restore once — it is the only way to know your ledger survives a dead disk.

Which mistakes do teams make most often?

The most common mistakes are buying the software before cleaning the item master, letting staff see the expected quantity while counting, and treating the annual stocktake as the accuracy plan. Each one produces the same result: a system nobody trusts by month three.

Counting everything at once, once a year, and calling that accuracy.
Keeping a parallel spreadsheet "just in case" — it always wins, and it is always wrong.
Letting anyone post an adjustment without a reason code.
Skipping the opening count, then wondering why every number is off.
Rolling out to every location on day one instead of one counter first.

What does this look like in a real shop?

Picture a Kathmandu electronics retailer: one shop, a WooCommerce store, about four thousand SKUs, and stock shared between the counter and online orders. Before any real process, the same few SKUs were oversold online every week, and counter staff had quietly stopped trusting the stock figure.

The fix was not dramatic. They cleaned the item master over three weekends, labelled every bin, put one scanner on the counter, blocked negative stock at the till, and counted the top two hundred SKUs every Monday morning. Online oversells stopped within a month. The bigger change was cultural — the weekly variance list gave the team something to fix instead of someone to blame.

Should you build, extend, or buy?

Extend what you already run if your accounting or e-commerce platform already holds the item master. Buy a dedicated inventory or ERP module when you have multiple locations, batch or serial tracking, or manufacturing. Build custom only when your stock workflow is genuinely part of the product.

If you are weighing those routes, our comparison of custom software against off-the-shelf works through the same trade-offs for a business application. Whichever you pick, the integration work is where the effort goes — a custom web application that talks to your existing till and store is often the smaller job than replacing both.

Option	Fits when	Main cost driver	Who operates it
Extend the platform you already run	One or two locations, stock already lives in the e-commerce or accounting system	Integration work and add-on licences	Your existing admin staff
Buy an ERP or warehouse module	Multiple sites, batch or serial numbers, purchasing and accounts in one place	Per-user licences and implementation time	A trained key user, plus vendor support
Build custom	The workflow is genuinely unusual, or stock handling is part of what you sell	Engineering time and long-term ownership	Your team, or whoever you hire next
Stay on spreadsheets	One counter, one person, one channel, no growth planned	Staff hours and repeated errors	Whoever owns the file

In short: accuracy comes from capture, counting and consequence — scanning where stock moves, counting small slices often, and acting on every variance with a reason code. Software makes that routine possible; it does not make it happen.

People also search for

These are the questions readers send us after a count has gone wrong: how to replace a legacy stock file, how to run an old and new system side by side, and how to get staff to actually use the new process.

If your stock figures and your shelves keep telling different stories, our team can help you clean the item master, wire one movement ledger into your till and online store, and set a counting routine your staff will actually keep. Start by telling us what your counts look like today, and look at the internal systems we have delivered for businesses running the same problem.

Frequently asked questions

It is the combination of process, counting method and software that keeps recorded quantity equal to physical quantity. The ERP holds the book figure; an accuracy system covers cycle counting, variance tolerances, audit trails and reconciliation. Accuracy is measured as record accuracy rate — the share of SKUs whose counted quantity matches the system within tolerance.
When stockouts and oversells appear on items the system says are in stock, or write-offs keep recurring. A common trigger is inventory record accuracy sitting below roughly 95% on fast-moving SKUs. Pull a variance report from recent cycle counts; if the same SKUs fail repeatedly, the process, not the counter, is at fault.
Clean SKU and unit-of-measure data first: duplicate SKUs and mismatched UoM conversions cause most false variances. Then barcode labels on bins and items, a scanning device or phone app, and a count frequency defined per ABC class. Back up the item master before bulk edits, and run the first count as a read-only exercise.
Cycle counting counts a subset of SKUs on a rolling schedule — typically A items weekly or monthly, C items quarterly — so errors surface while the cause is still traceable. A single annual count finds the variance but not its origin, and usually needs operations frozen. ABC ranking by value and movement sets the frequency.
Count inside a freeze window per bin or location rather than across the whole site. Record receipts and picks that happen during the count against a timestamp cutoff, and post adjustments only through an approved variance workflow. Offline-capable apps queue scans locally and sync, so poor connectivity does not halt counting. Sync conflicts need a defined rule and an exception queue.
Unrecorded receipts and returns, unit-of-measure errors, backdated or late-posted transactions, kit or bundle components not exploding correctly, and duplicate SKUs created when the same product is entered twice. Theft and damage are real but usually smaller than process error. Compare transaction timestamps against count timestamps to isolate posting lag.
Re-count the same SKUs after the change and compare variance. Track inventory record accuracy over time and the adjustment value per period — both should trend down. Sample-check a known bin independently of whoever counted it. If variance moves to a different SKU group, the root cause shifted rather than disappeared; investigate before declaring success.
Restrict adjustment rights by role, require a reason code, and separate counting from approving. Every adjustment should write an immutable audit record: user, timestamp, SKU, location, old and new quantity, reason. Without that separation, staff can mask shrinkage. Review the adjustment log monthly — unusual concentration by user or SKU is the signal.
If you run WooCommerce, Shopify or an ERP, extend it with a scanning app and a counting workflow before building a separate system — two sources of truth is the failure you are trying to fix. Build custom when counting rules, multi-location logic or integrations genuinely do not fit. Our team can scope that at /contact.
Counting labour scales with SKU count and frequency, so ABC classification keeps it proportionate. Other drivers are hardware per location, scanner or app licensing per user, integration work when a sales channel or ERP changes, and the time spent investigating variances. Cloud costs depend on transaction volume and how long you retain audit history; check current vendor pricing.