An inventory system for a retail chain, scoped to stock truth

Ask three branch managers how many of an item they hold and you will get three numbers, all of them offered with confidence. The head office number will be a fourth. Nobody is lying. They are each counting a slightly different thing at a slightly different moment, and no part of the business has been given the job of reconciling them.

That is the problem worth solving, and it is much narrower than the ERP proposal that usually arrives in response to it. This note scopes what a multi-branch inventory system actually has to do.

Start by identifying items properly

Most chains we see are running on internal item codes that were invented by whoever set up the first branch. Codes drift, branches invent local variants, and two records for one product is the result. Before any software, fix identification.

The standard already exists and it is worth using rather than inventing your own. GS1 defines Application Identifiers, described as prefixes used in barcodes and RFID tags that define the meaning and format of data attributes. The ones that matter for stock are AI 01 for the trade item number, AI 10 for batch or lot, AI 21 for a serial number and AI 17 for expiry.

You do not need all four. A clothing chain needs 01 and possibly 21. A pharmacy or grocer needs 10 and 17 or it cannot handle a recall or rotate stock correctly. Deciding which of those four you carry is the single most consequential decision in the whole build, because it sets what every later question can be answered about.

There is a deadline worth knowing about

If you are choosing scanning hardware this year, one piece of current industry planning should shape the decision. GS1's retail point-of-sale guidance sets out an initiative it calls Ambition 2027, whose stated goal is for retail point-of-sale scanning to be globally capable of reading and processing the item number from both linear and 2D barcodes by the end of 2027.

The practical consequence is specific: the guidance notes this will require software upgrades and may require equipment upgrades where a scanner is not already imager capable. If you are buying laser scanners now because they are cheaper, you are buying something you will replace. During the transition, products are expected to carry both a linear barcode and one of the approved 2D options, so your system should be able to read either and treat them as the same item.

The four events a chain actually needs

Inventory systems get bloated because everyone adds the movement type they personally care about. Almost every chain runs correctly on four events, recorded per branch and never edited after the fact:

Adjustment is the one that gets quietly merged into the others, and it should never be. If a correction can be recorded as a receipt, shrinkage becomes invisible, and shrinkage is usually the reason somebody asked for the system in the first place.

Transfers are where the truth actually breaks

A transfer is the only event with two branches and a gap in the middle, and almost every stock discrepancy we have traced lives in that gap. Stock leaves on Tuesday and is received on Thursday. For two days it exists in neither place, or in both, depending on how the software was written.

• Model a transfer as two rows, dispatch and receipt, not as one instant move.
• Give the in-between state a name and show it on the stock screen, so nobody has to guess.
• Require the receiving branch to confirm quantity, and record the difference rather than overwriting it.
• Treat an unconfirmed transfer older than a set number of days as an exception that a person has to close.

That last rule is what converts a system from a record into a control. Without it, discrepancies accumulate silently until an annual count turns them into an argument nobody can settle.

What to leave out of version one

Forecasting, automatic reordering, supplier portals and demand planning are all reasonable things to want and all wrong to build first. They are calculations on top of stock history, and until the history is trustworthy their output is confident nonsense. Build them in year two, on data you believe.

The same argument applies to integrating your accounting system on day one. Sequencing a build so the expensive parts come last is most of what keeps a project affordable, which we set out in reducing software development cost in the right order. A comparable module by module scoping exercise for a different sector is in a restaurant ordering system for small chains.

Honest limits

A system will not fix counting discipline. If branches count stock when they have a quiet afternoon rather than on a schedule, your data will stay approximate no matter what you install, and the software will simply record the approximation faster. Fix the counting routine first, on paper if necessary, and watch whether it holds for a month.

It is also worth being clear that we build software and therefore have an obvious interest in recommending a build. For a chain under roughly five branches with a single stockroom, an off-the-shelf point-of-sale package with decent stock features is very often the right answer, and the honest test for whether custom work is justified is in signs you need custom software.

Finally, better stock data changes buying decisions, and buying decisions live or die on unit economics rather than on stock counts. KF Agency has a detailed working of that arithmetic for online stores, in Arabic, at how to calculate net profit per order, and it pairs well with a stock system that finally reports honest quantities.