Choosing a Warehouse Scanning App for Business Central
Not a feature comparison — a set of questions worth asking any vendor, including us, before a scanning app gets anywhere near your inventory ledger. Every one of these is something your own Business Central consultant, or a technically literate colleague, can verify independently, without taking a vendor’s word for it. None of it requires trusting a demo.
Why this list, and why no names
This page deliberately names no competing product. The questions below are useful regardless of who you’re evaluating, and a fair, sourced, fact-checked comparison of a specific named competitor is a different kind of claim than a vendor-neutral checklist is set up to make responsibly. If you want that comparison, ask your consultant to run this exact checklist against whatever you’re actually considering — it travels.
1. Does it post directly to the ledger, or does it stage and sync later?
A tool that writes to its own side table and “syncs” to Business Central on a schedule creates a second dataset that can drift from what the ledger actually recorded — and drift, once it exists, is a reconciliation project waiting to happen, not a hypothetical risk. Ask specifically: at the moment a worker’s screen says a scan succeeded, has that scan already reached Business Central’s own ledger, or is it sitting somewhere else waiting for a batch job to run? The answer changes what “the app is down” actually means for your inventory accuracy.
2. Does it re-verify after posting, or just trust that the call succeeded?
A network call can return success from an app’s own point of view while the underlying post silently failed, partially failed, or landed against the wrong record entirely. The only way to know for certain that a transaction really happened is to read the result back from the ledger itself — a second, independent read — not to trust the HTTP response of the call that requested the post in the first place. Ask what happens, specifically, between “the scan was submitted” and “the app told the operator it worked”: is there a read-back step in between, or is success reported the instant the request returns?
3. Does it handle item tracking through the platform’s own mechanism?
As covered in item tracking in Business Central, explained, a tool can write a lot or serial number somewhere that looks entirely correct on screen and still lose it silently, with no error, if that value isn’t attached the way Business Central’s own posting step actually reads tracking. This is a genuinely easy trap to fall into and a genuinely hard one to notice, because the failure doesn’t surface until a trace or recall comes up empty months later. Ask specifically how a vendor’s tool captures tracking, not just whether it “supports lot and serial tracking” — that phrase is compatible with both the safe mechanism and the silent trap.
4. Does it require a fully directed warehouse, or adapt to what you actually run?
As covered in warehouse topology, explained, Business Central warehousing spans a real ladder of configuration levels, and forcing a simple, un-directed location into a full directed-put-away-and-pick project just to scan a receipt is a real, avoidable cost — in setup time, in item and bin data that has to be defined and kept current, and in staff retraining. Ask whether the app reads your location’s actual current setup and only offers the operations that setup genuinely supports, or whether it silently assumes every customer has already climbed to the top rung.
5. What happens when the signal drops mid-shift?
As covered in why offline barcode scanners lose scans, a dropped connection can either lose a scan outright or double-post it, depending on exactly how the app’s offline design handles the reconnect moment — and a warehouse Wi-Fi dropping mid-shift isn’t a rare edge case, it’s routine. Ask specifically what happens, in mechanism terms — is there a durable on-device queue that survives a crash or restart, and does each queued entry carry something that lets the server recognize a duplicate delivery attempt — rather than accepting “yes, it works offline” as a complete answer. That phrase is compatible with a design that quietly loses or doubles scans under real-world conditions.
6. Does it handle item tracking and FEFO the same way a desk-client user would get it?
If your business ships anything with an expiration date, ask whether a scanned pick actually sources from the earliest-expiring lot the same way a desk-client pick would, at locations where Business Central’s own FEFO enforcement is turned on — see FEFO vs. FIFO, explained. A tool that bypasses this native mechanism, rather than reaching it, can produce a pick that looks correct on the scanner and is wrong against the business’s actual expiration-date policy.
7. What hardware does it actually need?
Can it run on a phone or tablet your team already owns, or does it require dedicated rugged hardware before anyone can scan a single item? This is a real cost difference, not a minor detail — a tool that only works with specific paired scanners adds a hardware procurement project on top of a software rollout, while one that works from an ordinary phone camera can start the same day licensing is assigned.
8. How is licensing structured, and does it actually fit a small team?
Per user, per device, tiered by feature — and was the pricing model built assuming an enterprise headcount, or does it genuinely work for a three- or four-person warehouse crew? Ask about seat minimums specifically; a per-user price that looks reasonable can still be a poor fit if the minimum seat count assumes a much larger floor than you actually run.
9. How long before a worker can scan a real transaction?
Days of mandatory professional-services setup and days of self-service configuration are very different costs to a business, even when the end state looks identical on paper. Ask what has to happen, concretely, between installing the app and a real operator scanning a real receipt — and whether any of those steps require the vendor’s own staff to be involved, or can be done entirely by your own admin.
How to actually run this checklist
The most useful version of this exercise isn’t a written questionnaire a vendor answers by email — it’s watching the mechanism, live. Ask to see a trial environment, pull the network connection mid-scan, and watch what the device does. Ask to see a lot-tracked item picked at a location with FEFO turned on, and check which lot it actually draws from against the item ledger afterward, not against what the screen claims. Ask what a rung-1, un-directed location looks like in the same trial tenant a rung-5 directed one is demoed in, and see whether the app behaves differently on each without anyone reconfiguring it by hand. A vendor whose product genuinely does what this checklist asks for should have no reluctance showing any of that directly, on your own trial data, rather than describing it.
Why this is the right list to bring to any vendor
Every one of these nine questions is independently checkable — by reading a vendor’s own documentation, by asking a specific mechanism-level question in a sales call and listening for whether the answer is concrete or vague, or by having your Business Central consultant inspect the behavior directly in a trial. None of them require taking anyone’s marketing copy at face value, including this one. You can find how WarehouseQ answers each of these questions, in the same order, throughout the user guide.
Key terms
New to the vocabulary? Item tracking lines, FEFO, directed put-away and pick, and offline queue are defined in the glossary.