The questions to ask when choosing inventory management software

Costing and valuation questions

The most decisive characteristic of inventory software is how it calculates cost, because gross profit comes out of it. It is nonetheless almost never discussed in a demo.

The first question is what the costing method is and whether it can be changed. The second is whether the moving weighted average is genuinely recalculated on every receipt or only at end of day — the latter makes it impossible to see margin intraday.

The third, and most often skipped, is how landed costs are allocated. A system that cannot allocate freight, customs and insurance into product cost shows gross margin systematically high.

• Which costing methods are supported: moving weighted average, FIFO, standard cost
• Is the average cost updated on every receipt, or at period end
• Is last purchase cost held in a separate field — it is needed for pricing
• Can landed costs (freight, customs, insurance) be allocated into product cost, and on what key
• Can purchase discounts and volume rebates be applied retrospectively to cost
• Do warehouse-to-branch and branch-to-branch transfers carry cost, or are they processed as new receipts

Insist on testing the transfer question live. Systems that treat transfers as goods receipts corrupt the average cost at the receiving branch, and branch-level margin reporting is never correct afterwards.

Data model and grain questions

What a system can do is determined by its data model, not its screens. The model does not change after implementation, which is why the most important questions sit here.

Expiry and lot structure is decisive in a grocery chain. In a system that holds the expiry date as a single field on the product record, different-dated batches of the same product never separate; FEFO issuing, timely markdowns on batches nearing their date and a narrowly scoped recall become impossible.

The second critical subject is grain: at what level does the system store sales. Systems that do not store at receipt line level but keep daily summaries make basket analysis, hourly sales and promotion effect impossible later. A summary can always be produced from detail; detail cannot be produced from a summary.

• Are expiry and lot held batch by batch, and can issues be proposed in FEFO order
• Is sales movement stored at receipt line level, and for how long back
• Can one product carry more than one barcode (the supplier's plus your own)
• Are unit conversions supported: case, each, kilogram
• Can weighed products be read from the scale barcode, and is the unit price of products sold by weight or volume calculated per kilogram or litre
• How many warehouses and branches are supported, and is there a limit

Operational questions

The system runs in the field, not at a desk. Networks are weak in the warehouse, the till is busy in the branch, counting happens at two in the morning. The questions should target those conditions. Who does the installation is an operational question too: when the vendor's own team installs the system and brings each new branch online, the work does not land on your IT team as a project.

The most critical is offline operation. Can the handheld carry on counting when the network drops, or does it stop? If it stops, every count is at risk from every network interruption.

Negative stock behaviour is the second critical subject. Can goods absent from the record be sold; if so, at what cost is the sale written, and is the history corrected when the goods are later received? In systems that do not correct it, the average cost stays permanently broken.

• Do handhelds work offline, and how many records can they hold
• Can cycle counts be planned by ABC class, and can counts opened in several branches at once be followed from head office
• Is negative stock allowed; if so, is the cost corrected afterwards
• Can count variances be coded by cause and posted to separate accounts
• Can shrinkage be entered at the shelf on a handheld, with a mandatory shrinkage reason code
• Can barcode scanning be made mandatory at goods receipt

Migration, integration and the right to exit

The subject that most often delays projects is data migration, and it is usually discussed after the contract is signed. That is the most common source of delay and of extra cost.

The migration scope must be written down: which data, how far back, at what quality. Opening stock, product records, suppliers, ledger accounts and sales history are each handled separately. When sales history is not brought across, the first year has no comparison and forecasting models cannot run.

The right to exit is the subject left to last and the one that generates the most regret. If it is not written into the contract when, in what format and at what cost you can export your data, the decision to change systems is not effectively yours.

1. Put the migration scope in writingWhich data, how far back, in what format. "Your existing data will be transferred" is not a scope.
2. Settle how opening stock will be establishedBy count or from the current system's records. If by count, who does it and when.
3. List the integrationsERP, accounting, e-invoicing, banks, scales, tills and handhelds. For each, is there a ready connector or does it need development, and who builds it; in which direction and how often data will flow with the ERP.
4. Ask about API and data accessCan you reach the data directly to write your own reports? If the only export is from the screen, no analytics layer can be built on top.
5. Get the exit clause into the contractWhen the contract ends, in what format, within what timescale and at what cost is all the data delivered.

"You can always access your data" is not sufficient. In what format — raw tables or PDF reports — and at what cost are separate questions that have to be asked.

Three scenarios to insist on in the demo

A standard demo shows the flow in which the product looks best. The real difference shows up in the scenarios where the system struggles, and it is the buyer's right to ask for them.

Three scenarios surface most of the problems you would otherwise meet later. All three should be run on your own data and your own product structure; a walkthrough on canned demo data proves nothing.

1. Have them build your own product recordHave your most complex product — sold by weight, converted between case, each and kilogram, lot and expiry tracked — set up during the demo. If it cannot be built, or is a struggle, you have your answer.
2. Run the cost chain end to endEnter a purchase invoice, add freight, make a transfer, sell it, take a return. At every step, have the product's cost displayed on screen.
3. Have them produce your own month-end reportHave the most critical report you use today produced in the system and compare the two figures. Any difference should be explained during the demo.

These three scenarios take around two hours, and a vendor refusing to run them is also an answer.