There is one question that exposes more inventory systems than any feature list: how many different answers can this software give to "how much of this do we have?" In a surprising number, the answer is more than one.
Ask a vendor to show you where the quantity on hand is stored. Then ask whether any other table in the system also holds a stock figure.
This sounds pedantic. It is the single most consequential thing about inventory software. Systems accumulate stock tables the way houses accumulate keys — an original one, then a newer one built for a warehouse module, then a cached balance for reporting speed. Each is written by different code paths. They agree until they do not, and there is no error when they diverge, because from the software's point of view nothing failed. Two screens simply show different numbers and everyone believes whichever one they usually look at.
We can be specific about this because it happened here. Rebota carried two stock ledgers — an older inventory table read by most of the product, and a newer stock_ledger with proper movements — and nothing reconciled them. The populations turned out to be disjoint rather than contradictory, which was luck, and they were consolidated onto one ledger. There is now a command that re-checks it, and it runs as a gate. Ask your vendor whether they have the equivalent; the answer is more revealing than any feature list.
The difference between a stock register and a stock ledger is the difference between a number and a history.
A register stores 240 units. Someone changes it to 190. The 50 are gone and so is any record of why. A ledger stores an issue of 50 against a work order, on a date, at a cost, by a user — and 190 is derived, not stored. When someone asks why stock dropped, a ledger answers; a register can only shrug.
The practical test: ask to see the movement history for one item, and ask whether the current quantity is calculated from it or stored separately. If it is stored separately, ask what happens when the two disagree — and whether anything checks.
Every unit of stock has a cost, and which cost you assign when it leaves changes your reported profit. FIFO assigns the oldest cost; weighted average blends them. Neither is wrong, but they produce different numbers, and your auditor will expect consistency.
The detail that matters for the future: a system should open a valuation layer on every receipt even if you use weighted average. That way the history stays computable and you can change method later. If receipts are only averaged into a single running cost, the layer information is gone forever and switching method means restating from scratch.
Ask: which valuation methods are supported, is the method set per item or globally, and are receipt layers retained regardless of method?
Vendors often present "traceability" as one checkbox. It is two.
Batch or lot tracking answers which production run or purchase lot a quantity came from. It suits materials measured by weight or volume — chemicals, food, cement, pharmaceuticals — and it pairs with expiry dates and FEFO consumption, where the earliest-expiring stock is issued first rather than the earliest-received.
Serial tracking identifies one physical unit. It suits equipment, machinery and anything with a warranty or a recall obligation. The demanding part is genealogy: when serialised units are assembled from batched inputs, can the system trace forward from a raw material lot to every finished unit it entered, and backward from one unit to everything it consumed? That two-directional walk is what a recall actually requires, and it is where most systems stop.
Ask which one your regulator requires before you ask which one the software has.
An unglamorous question that separates serious systems: what happens if the same goods receipt is posted twice — a double click, a retried network request, an integration that fires again?
A weak system creates two receipts and doubles your stock, silently. A serious one requires every movement to carry a key derived from its source document and line, and refuses a movement whose key it has already seen. The stock is right, no error reaches the user, and the second attempt simply returns the first result.
This matters far more once anything is automated. Ask the question in exactly those words and watch whether the answer is specific.
Physical stock and recorded stock diverge. Theft, breakage, unrecorded issues, miscounts. Good software expects this and provides cycle counting — counting a subset of items regularly rather than shutting the warehouse once a year — with the variance posted as an adjustment movement that carries a reason, not as an edit to a number.
The adjustment must be a movement. If a stock correction is an edit rather than a transaction, your ledger has a hole in it exactly where the interesting information was.
One stock ledger, with movements as the source of truth and balances derived from them. FIFO valuation layers with weighted average also available, layers opened on every receipt regardless of method. Batch tracking with expiry and FEFO consumption. Individual serial numbers with genealogy that walks in both directions. Every movement carries an idempotency key, so a repeated post returns the original movement rather than creating a second one. There is a reconciliation command that compares the ledger against its balance cache and fails a gate on any divergence.
What is missing: demand planning and forecasting are not built, so reorder timing is judgement rather than a model. There is no multi-warehouse transfer pricing. And warehouse management covers locations, bins and pick lists but not directed putaway or wave picking, so a high-throughput distribution centre will find it thin.
| Feature | Spreadsheet | Accounting software with stock | Rebota |
|---|---|---|---|
| Current quantity on hand | |||
| Movement history you can replay | Partial | ||
| One stock figure, not several | Trivially | Varies | Reconciled by a gate |
| FIFO valuation layers | Sometimes | ||
| Weighted average | |||
| Batch tracking with expiry and FEFO | Rarely | ||
| Individual serial numbers | Rarely | ||
| Two-directional genealogy | |||
| Duplicate posting refused by key | Varies | ||
| Demand forecasting | Not built | ||
| Directed putaway / wave picking | Not built |
Businesses where stock is a process rather than a register — goods received against orders, issued to jobs or production, counted periodically, and valued for accounts. Particularly those with batch, expiry or serial obligations.
A business holding a handful of SKUs with no traceability requirement. A spreadsheet genuinely holds that, and inventory software would be overhead without benefit.
A high-throughput distribution centre needing directed putaway, wave picking and labour management wants a dedicated WMS. A business whose central problem is forecasting demand wants a planning tool; Rebota shows what you have and what is on order, and does not predict what you will need.
One location, few items, one person issuing stock, no expiry or serial obligation, and no auditor asking how a quantity changed.
The real cost is discipline: stock software is only as accurate as the movements people bother to record. Budget for the process change, not just the licence — a perfect ledger fed by half the issues is worse than a spreadsheet everyone distrusts, because it looks authoritative.
Judge inventory software on whether stock has one answer, whether movements are recorded rather than balances edited, and whether valuation layers survive a change of method. Features are easy to demonstrate; those three are structural and cannot be added later without a migration.
The most useful habit in inventory management is refusing to correct a quantity by editing it. Every difference between recorded and physical stock should be posted as an adjustment movement with a reason code, even when the reason is "we do not know". Over a year those reason codes become the most valuable dataset in the warehouse: they tell you whether you have a theft problem, a recording problem or a counting problem, and no amount of software sophistication substitutes for having asked the question at the time.
