Inventory management software requirements

The invariants (non-negotiable, testable)

On-hand equals the signed sum of movements — for every product, at every location, at every moment. A system storing editable stock totals fails this requirement by architecture; everything else on this page is commentary.

Every movement names an actor, a timestamp and a reason — the audit trail is not a report but the record itself, and it must survive questions from auditors, insurers and your own staff six months later.

A cancelled reservation returns its stock, atomically — no phantom allocations, no freed quantity visible to one user and not another.

Stock deducts only on invoice approval — a deliberate human step, so intent (orders) and fact (deductions) never blur.

Each of these is testable in minutes of a trial: try to break them. Any vendor whose product cannot demonstrate all four is selling a spreadsheet with ambitions.

The functional must-haves (ranked by impact)

Multi-location quantities — on-hand, allocated and on-order per site, live. Reorder levels and purchase orders from demand — the purchasing signal that replaces memory, with supplier invoice matching and price-variance flags. Order states through fulfilment — received, allocated, picked, packed, invoiced, paid — visible at list level, enforced in one service. Stocktakes — full or cycle counts, variances corrected as movements. Customer self-service — ordering portals with per-customer products and pricing, if the business has trade customers. Batch tracking — if products carry expiry, provenance or recall exposure. Production — recipes, runs and shortage checks, if the business makes things.

Deliberately ranked below these: dashboards (a view of the record — covered here), mobile polish, and forecasting assists. None rescues a record that fails the invariants.

The integration and operational requirements

The accounting handoff — finished invoices pushed with tax codes intact, payment status mirrored back, purchasing reconciled; measured by counting manual steps for one real order. Storefront import — online orders entering the same record, by webhook rather than by re-keying. Access model — multi-user with permissions that reflect who may change what; the second user is where requirements start biting. Data portability — products, movements and reorder levels importable and exportable in open formats; a record you cannot leave is a record you do not own. Total cost over three years — licence plus implementation plus the hours of record-keeping; the cost arithmetic totals it honestly.

We build BSimple, so weigh that: these are the requirements BSimple was built to — movement-based record, multi-location live quantities, portals, batches, production, the accounting handoff to Xero or MYOB (US integrations rolling out), and a trial that is the full product so every line above can be tested on your own data. That is what a requirements list is for: not agreeing with marketing, but outvoting it — and the inventory management guide holds the full pattern.