Reference

What a stock control
system has to get right

Almost every merchant who goes looking for stock control software already has stock control software. It is the storefront, or a spreadsheet, or both, and it works until the day a second channel or a second location makes the number ambiguous.

So the useful question is not which product to buy. It is which system is allowed to be right when two of them disagree — because on most sites more than one holds a stock figure, none of them is nominated, and the answer is settled by whoever is asked last.

Every commercial relationship, declared

Shopify. StoreBuilder Ltd is a Shopify Partner and earns referral commission when a merchant moves to or upgrades a Shopify plan through the practice. That is a real financial interest in the platform recommendation, and it is stated here rather than on a page a reader may never reach.

Stok.ly. We hold an affiliate account with Stok.ly, who sell into the category this page describes. We have not delivered an implementation on it, and it is named below as an example of a pattern rather than as a recommendation or a delivered integration. When that changes, the change appears here in this paragraph.

No other stock or inventory vendor pays us anything. Not Linnworks, not Brightpearl, not Veeqo, not Cin7, not Unleashed, not Khaos Control, not any tool named on this page. No referral fee, no commission, no rebate, no affiliate link, no sponsored placement.

Stock is four numbers, and most systems publish one

When a spreadsheet, a storefront and a warehouse all say "stock: 12", they are frequently not answering the same question — and the gap between these four is where every oversell, every stuck order and every argument about whose number is wrong actually lives. A system that cannot separate them cannot be the one that is allowed to be right.

On hand

Physically in the building, countable by a person standing in front of it. The only one of the four that a stock take can verify, and the one most systems are worst at, because it changes without anybody telling the software.

Committed

Promised to an order that has not shipped. It is still on the shelf and it is not yours to sell. Systems that hold no concept of committed stock oversell at exactly the moment it matters, because the shelf and the number agree while the promise is invisible.

Available

On hand minus committed, and the only number a sales channel should ever be shown. Publishing on hand to a storefront is the single most common configuration error we are called into, and it looks completely correct until a busy hour.

Incoming

On a purchase order with a date against it. Without it, replenishment is guesswork and the same line gets ordered twice — once by the person watching the shelf and once by the person watching the report.

Multiply all four by every location and every channel and you have the actual data model. Any product being evaluated should be asked to show all four, per location, in one screen. Several cannot, and it is a faster disqualifier than any feature list. Where any of the stock is consigned there is a fifth dimension — ownership — and it is separate from all four of these, which is precisely the case most systems have no field for.

Stock truth and the order promise are different jobs

Often sold as one product, and that is fine — but they are two questions, and knowing which one you are trying to answer changes what you should be shortlisting. A merchant who buys for the wrong one ends up with a system that is excellent at a problem they did not have.

A stock system owns the truth

What exists, where it is, which of the four states it is in, what it cost and what is on its way. It is the system of record — the one nominated to be right when the others disagree, and the one a stock take is reconciled against.

You need one when more than one place holds stock, or more than one channel sells it, and no single system can currently answer "how many, where" without somebody joining two screens together.

An order system owns the promise

Which unit, from which location, to which customer, in what priority — and the order's state from placed to settled. It consumes stock truth; it does not produce it.

You need one when orders arrive from more than one place, or when a single order can be fulfilled from more than one location and somebody has to decide which. The order-management reference is the other half of this.

The ledger is downstream of both and answers a third question — what the stock was worth at a date that has passed. Why that number legitimately differs from the other two is accounting and stock.

Four questions that shorten the shortlist

Asked in this order, because each one only matters if the previous answer held. None of them appears on a feature comparison, and all four are answerable in a demo if you ask for the screen rather than the brochure.

1 — Which system is nominated to be right?

Not which one is most accurate — which one wins by rule when two disagree. If the answer is "it depends" or "we check both", nothing has been nominated, and buying software will not nominate it for you.
2 — Can it show all four numbers, per location, in one screen?

On hand, committed, available, incoming. Ask to see it on a real multi-location catalogue rather than a demo dataset, and watch whether available is calculated or typed.
3 — What happens when a SKU convention changes?

Barcodes get re-issued, suppliers rename, a range gets restructured. Whether that is one mapping edit or a week of spreadsheet work is the difference between a system you keep and one you replace in three years.
4 — Who owns it on a Tuesday?

Every one of these needs a person who understands the mapping and notices when a feed stops. If nobody in the business will hold that, the honest answer is a simpler system or a supported one, and it is better to decide that before the contract than after.

Linnworks, Brightpearl, Cin7, Unleashed, Veeqo and Stok.ly sit in this category; Khaos Control and NetSuite answer it from inside an ERP. They are named as examples of where a category sits, not as a shortlist — see the disclosure above. How each physically connects to Shopify Plus, and where each connection type breaks, is the systems reference.

When the storefront is already enough

One location, one sales channel, and a catalogue where a person still recognises most of the lines: Shopify's own inventory is a stock control system and it is a competent one. Adding a second system adds a second number to reconcile and solves nothing.

The threshold is not turnover. It is the first moment two places hold the same product, or two channels sell it — because that is when "how many" stops having one answer, and a nomination has to be made whether or not anybody makes it deliberately.

If the symptom rather than the selection is what brought you here — overselling, a second location making things worse, or the WMS-versus-3PL decision — the operations page is the diagnosis.

Stock and fulfilment

What this reference does not yet contain

The per-vendor rows — which of these products genuinely holds committed stock per location, how each behaves when a channel goes down mid-sync, what each costs to run rather than to licence — are not written here.

We have not implemented across that field at this merchant size. The obvious page is a feature grid with ticks, and a reader cannot tell a matrix built from implementations from one assembled out of vendor datasheets. Those rows appear named, dated and attributed as real implementations produce them.

The practical answer in the meantime is the diagnostic: which system is nominated today, whether available is calculated or typed, and how many of the four numbers anything in the business can currently produce.

Book the diagnostic

What a stock control system has to get right