Why is our application's stock always wrong?

Because the application stores a quantity and lets it be edited: by an employee, by a bug, by a synchronisation that runs twice. An edited quantity no longer carries the trace of what produced it. The construction that settles this is an append-only movement ledger whose quantity is the sum; a variance becomes an adjustment with a reason, and the figure becomes explainable again.

What is the difference between on hand and available?

On hand is what is in the warehouse; available is what you can still sell or promise, that is on hand minus current reservations and, depending on the case, units in transit. A B2B portal order reserves without a single case moving; the shop must sell on available, and stock-out alerts are computed on available.

How do you avoid selling the last item twice?

By having the database hold the rule, not the screen: available is reserved then decremented under a lock inside a transaction, and the database refuses a negative quantity. The second sale is refused at validation, instead of being recorded and cancelled at delivery. The screen may show a stock a few seconds stale; the database may not.

How do you manage stock across several warehouses?

A transfer is two movements, an out scanned at departure and an in scanned on arrival, with an “in transit” state between them so that the goods are somewhere. The variance between out and in is an adjustment with a reason, attached to the transfer and the driver. A sales rep's van or a delivery vehicle is a location like any other.

What if the warehouse has no network?

The scanner or the phone writes the movement locally, with a unique identifier created on the device, and sends it when the network returns. The server ignores an identifier it has already received, so a replayed receipt does not count twice. It is the same mechanics as any offline application, described in our dedicated guide.

Do we still need a yearly stocktake?

Cycle counting replaces it in practice: class-A references counted every week, B every month, C every quarter, without seeing the system figure, every variance with a reason. The month's accuracy, the share of counted lines that were right, measures continuously whether the stock is reliable; a full count remains possible when an obligation or an auditor asks for it.

How long does it take to make stock right?

Six weeks in the typical calendar: one to write the rules and the product record, one for the ledger and the take-over of stock as an opening movement, one for capture and offline, one for reservations and transfers, one for cycle counting, one for alerts and the first review. The duration depends on the number of locations and the state of the existing product record.

The application's stock never matches the real stock: what gets built in Algeria in 2027 to make it right, movement ledger, reservations, cycle counting, several warehouses, offline

Short answer. Stock is not a figure, it is a sum: a table of movements you append to and never erase from, receipt, sale, reservation, transfer, adjustment, return, each with its signed quantity, its source document, its author and its device. The displayed quantity is computed from this ledger and checked against it every night. Available, what you can still sell or promise, is on hand minus reservations, and a reservation expires if it is not paid. A transfer between two warehouses is two movements with an in-transit state between them. A movement entered offline carries an identifier created on the device, and the server ignores what it has already received. The last case is not sold twice because the database refuses it, not the screen. And cycle counting counts a little every week, without seeing the system figure, to produce the only measure that matters: the month's accuracy. Six weeks, the first without code.

This guide is for the manager of a wholesaler or a chain of shops who no longer trusts their stock, the founder settled in France who reads a figure from afar and cannot go and count, and the person for whom the yearly stocktake closure feels like a punishment. It does not repeat how an application works without network, described in the offline guide, nor how an old stock file is taken over, described in the data take-over guide; it describes what gets built so that the application's figure stays the shelf's, and it extends our software engineering page.

One product, one day: stock is a column of movements

The question we are asked is always the same: “why is the application's stock wrong?”. The answer is almost always the same too: because the application stores a quantity, and a stored quantity gets edited, by an employee, by a bug, by a synchronisation that runs twice. Once edited, it no longer carries the trace of what produced it, and nobody can say whether it or the shelf is right. The figure follows one product for one day in one warehouse.

Figure 1 · One day of one product in one warehouse. Stock is not a field you update: it is the sum of a column of movements, each with its source, its author and its device. Available, what you can still sell or promise, is on hand minus reservations; it drops at 9:12 when the B2B portal reserves, without a single case moving, and rises at 16:00 when an unpaid reservation expires. The 14:02 adjustment is a movement like the others, with a mandatory reason. The data is a constructed example.

Six movements, six documents, three people, two devices. The morning receipt comes from a receiving note scanned on the warehouse scanner; the 9:12 reservation comes from a B2B portal order, and it lowers available without a single case moving, because those 12 units are promised; the counter sale comes from a till receipt; the 11:20 transfer takes out 24 units that are no longer here and not yet there; the 14:02 adjustment comes from a count, with a mandatory reason, and it is a movement like the others; at 16:00, a 48-hour-old reservation that was never paid expires by itself, and available goes back up.

The end-of-day figure, 66 on hand, 12 reserved, 54 available, is written nowhere: it is the sum of the column. If someone doubts, you reread the column. If the column and the shelf diverge, you count and add an adjustment with a reason, and the variance becomes information: which person, which product, which reason, how often. That is the difference between stock taken on trust and stock that can be explained, and it is what managers who read their stock from France, according to the remote management guide, ask for first.

«Stock is never “edited”: a movement is added, and the quantity is the sum. A figure you can type is a figure you cannot explain.»

Accurate stock, in five layers

The ledger is the layer that matters, but it is not enough: you need capture that produces movements without network, fast read quantities, rules the database enforces, and a measure.

Figure 2 · The accented layer is what makes stock explainable: you never “correct” the quantity, you add an adjustment movement with a reason. The quantities of the third layer are a read view; if they diverge from the ledger, the view is recomputed, never the ledger retouched.

Capture. The barcode scanner or the phone camera at receiving, at the till, at transfer and at counting; every gesture produces a dated, signed movement with a unique identifier created on the device. That identifier is what lets the movement be written without network and replayed later without duplicate, following the mechanics described in the offline guide. Movement ledger. An append-only table: type, signed quantity, product, lot, location, source document, author. The stock of every product at any instant is a sum over this table.

Computed quantities. On hand, reserved, in transit and available per product and per location, kept up to date at every movement so that reading is instant, and recomputed every night from the ledger; if the two diverge, the view is corrected, never the ledger. Rules. A reservation expires without payment; a transfer is two movements with an in-transit state; an adjustment requires a reason and a right, following the roles and audit log guide; and two simultaneous sales of the last case do not both go through, because the decrement happens under a lock in the database, which refuses a negative quantity. Measurement. Cycle counting by class, variances with a reason, monthly accuracy per warehouse, and stock-out alerts computed on available, not on on hand, because a product with 20 units on hand and 20 reserved is out of stock.

A transfer between two warehouses, in six steps

As soon as a company has two warehouses, or a warehouse and shops, the transfer becomes the first source of wrong stock, because it is almost always entered once: on the way out, and the destination's stock is wrong until someone remembers to enter it; or on arrival, and total stock is wrong for the whole journey.

Figure 3 · The transfer is the first source of wrong stock in a company with several warehouses, because it is almost always entered once, on the way out or on the way in. The accented step is the one applications skip: between departure and arrival, the goods are nowhere, and a state is needed to say so. The fifth step turns the missing case into an explained movement, not a diverging figure.

Prepare the list of products, quantities and lots under a transfer number. Scan out case by case, which writes a dated, signed out movement. Mark in transit: the goods are neither in warehouse A nor in B, and the application says so; this is the step applications skip. Scan in case by case on arrival, which writes an in movement into B. Record the variance: out 24, in 23, the variance is an adjustment movement with a reason, lost on the way, counting error at departure, case delivered to the wrong shop, and it is attached to the transfer and the driver. Close: the number becomes final.

The same pattern serves stock travelling in a sales rep's van, following the field pre-sales guide, and stock that changes temperature on the way, following the cold chain guide: a “vehicle” location is a warehouse like any other, and what enters and leaves it is a movement.

Cycle counting: count a little every week

The yearly stocktake closes the company for a day or two, mobilises everyone, produces a figure that is right that evening and wrong from the following week. Cycle counting does the opposite: count a little every week, the products that matter most first, and measure continuously whether the stock is reliable.

Figure 4 · Cycle counting replaces the yearly closure: class-A references, those carrying most of the value, are counted every week, B every month, C every quarter. You count without seeing the system figure, every variance gets a reason and becomes an adjustment movement, and the month’s accuracy, the share of counted lines that were right, is tracked against a written objective. The 20/80 split is a rule of practice, not a law; the quantities are a constructed example.

References are classed by annual value: class A, often a small share of references carrying most of the value, is counted every week; B every month; C every quarter, one aisle at a time. The 20/80 split is a rule of practice from inventory management references, not a law; every company adjusts its thresholds. Three rules make the count hold: you count without seeing the system figure, otherwise you copy it; every variance gets a reason, breakage, receipt mis-entered, sale not recorded, theft, and becomes a signed adjustment movement; and the month's accuracy, the share of counted lines that were right, is tracked against a written objective, per warehouse and per person.

That accuracy is what says whether the stock is reliable, and it is what appears on the manager's dashboard, following the real-time dashboard guide; recurring variance reasons say where to act: a receipt mis-entered three times in a month is a scanner or training problem, a recurring unrecorded sale on the same product is a till problem. The quantities in the figure are a constructed example.

«You count without seeing the system figure, every variance gets a reason, and the month's accuracy is the only measure that says whether the stock is reliable.»

Six reasons for wrong stock, and what the application does

The six reasons we meet in almost every application we take over, and the construction that settles them.

Figure 5 · The first two rows are settled by the ledger and the database; the next two by expiry and state rules; the last two by the device identifier and the product record. None is settled by a more attentive employee.

The first two rows are settled by the ledger and the database: a quantity that cannot be edited, and a lock that refuses the second sale of the last case instead of writing negative stock. The next two are settled by expiry and state rules: a reservation that releases itself, and a transfer with an in-transit state. The last two are settled by the device identifier, which prevents double counting of a replayed receipt, and by the product record, which attaches all barcodes to a single reference with units and factors. The barcode itself says nothing about stock: a GS1 prefix 613 identifies a company registered with GS1 Algeria, not the product's origin, and the case and the unit carry different codes; the product record is what links them. None of the six rows is settled by a more attentive employee.

Seen elsewhere: inventory management references, and what carries over

Two ideas from inventory management references carry over as they are. The first is the append-only ledger: systems that keep accurate stock at scale never write a quantity, they write transactions and compute the quantity; it is the same idea as an accounting general ledger, and it is what databases do best. The second is cycle counting by classes, which replaces the yearly closure with continuous counting and measures record accuracy; common objectives sit above 95 % of lines right, and each company writes its own.

What those references do not say: your movement types, your units and factors, who may adjust, and how long a reservation lives before it expires. The project's first week answers that, and the manager signs.

The rules of stock that stays right

Six rules, written in the first week. The quantity is never editable: a movement is added. Every movement has a source, an author, a device and an identifier created on the device. Available is on hand minus reservations, and alerts are computed on available. A reservation expires at a written hour. A transfer is two movements with an in-transit state, and the variance on arrival is a movement with a reason. The month's accuracy is measured per warehouse and per person, and reviewed every month.

And one rule of method: existing stock enters the new application as an opening movement per product and per location, dated and signed, after a count, never as a figure copied from the old software; the take-over is described in the old-software migration guide.

Six companies, and the movement that was missing

Six situations composed from projects we meet; the names are generic and the figures are examples.

A food wholesaler in Sétif, one warehouse and three shops. Total stock was wrong every week by the amount of transfers in progress. The construction: two-step transfer, visible in-transit state, arrival variance attached to the driver. In the third month, recurring variances on the same route pointed to a loading problem, not theft.
A clothing chain in Algiers, online shop and four stores. The last item of a size sold online and in store at the same hour. The construction: available reserved at order, decremented under lock at validation, reservation expired after 48 hours without payment. Cancellations for “item unavailable” stopped.
A pharmacy with three branches. Lots and expiry dates kept in Excel, the application's stock ignored. The construction: movements per lot, class-A cycle count every week, expiry alerts computed on the ledger; the case is described in the three-branch pharmacy guide.
A drinks distributor in Oran, twelve trucks. Truck stock did not exist; variances were discovered at month end. The construction: every truck is a location, loading and unloading are scanned movements, the evening variance is an adjustment attached to the driver.
A founder in Lyon, cosmetics shop in Algiers. They read a stock they could not check. The construction: ledger readable from afar, month's accuracy on the dashboard, count photos attached to adjustments.
A hardware store in Constantine, the same product under three codes. Case, unit and old internal code, three wrong stock lines. The construction: product record with units and factors, all codes attached, stock read in units, labels reprinted following the label printing guide.

The 2027 calendar

Six weeks for a company that already has a till or an ordering portal; the first week passes without code.

Figure 6 · Six weeks, and the first without code: you write the movement types, the units and the rights, because a ledger built with the wrong types migrates badly. The second week is accented because the existing stock enters it as an opening movement, not as a typed figure; from that week on, no quantity is editable any more.

Week 1, rules and product record: movement types, units and factors, attached barcodes, locations, who may adjust, A/B/C classes and accuracy objective, signed by the manager. Week 2, ledger and quantities: append-only movement table, computed quantities per location, nightly recompute, and existing stock taken over as an opening movement after a count; from that week on, no quantity is editable. Week 3, capture and offline: receipt, sale and return by scanner or camera, device identifiers, offline queue replayed without duplicates.

Week 4, reservations and transfers: reservation with expiry, lock on the last case, two-step transfer. Week 5, cycle counting: count sheets by class, blind entry, variances with reason, monthly accuracy per warehouse. Week 6, alerts and review: stock-outs computed on available, recurring variances by product and by person, first monthly review. Every week ends with a demo, following the delivery without breakage guide.

What makes accurate stock fail

Five causes, seen in applications we take over. An editable quantity, “for urgent cases”: after a month every case is urgent, and the ledger is useless. Available confused with on hand: the shop sells what is already promised to the B2B portal, and the customer learns at delivery that there is none left. A transfer entered once: total stock is wrong for every journey. Synchronisation without identifiers: every network recovery doubles a receipt. A yearly stocktake alone: the figure is right one evening a year.

And one cause of method: taking over the old software's stock without counting it. The copied figure is wrong from day one, and the first month's accuracy says so; better to count once, class A first, and enter correct opening movements.

Frequently asked questions

The questions managers and founders ask when they describe wrong stock to us.

Why is our application's stock always wrong?: Because the application stores a quantity and lets it be edited: by an employee, by a bug, by a synchronisation that runs twice. An edited quantity no longer carries the trace of what produced it. The construction that settles this is an append-only movement ledger whose quantity is the sum; a variance becomes an adjustment with a reason, and the figure becomes explainable again.
What is the difference between on hand and available?: On hand is what is in the warehouse; available is what you can still sell or promise, that is on hand minus current reservations and, depending on the case, units in transit. A B2B portal order reserves without a single case moving; the shop must sell on available, and stock-out alerts are computed on available.
How do you avoid selling the last item twice?: By having the database hold the rule, not the screen: available is reserved then decremented under a lock inside a transaction, and the database refuses a negative quantity. The second sale is refused at validation, instead of being recorded and cancelled at delivery. The screen may show a stock a few seconds stale; the database may not.
How do you manage stock across several warehouses?: A transfer is two movements, an out scanned at departure and an in scanned on arrival, with an “in transit” state between them so that the goods are somewhere. The variance between out and in is an adjustment with a reason, attached to the transfer and the driver. A sales rep's van or a delivery vehicle is a location like any other.
What if the warehouse has no network?: The scanner or the phone writes the movement locally, with a unique identifier created on the device, and sends it when the network returns. The server ignores an identifier it has already received, so a replayed receipt does not count twice. It is the same mechanics as any offline application, described in our dedicated guide.
Do we still need a yearly stocktake?: Cycle counting replaces it in practice: class-A references counted every week, B every month, C every quarter, without seeing the system figure, every variance with a reason. The month's accuracy, the share of counted lines that were right, measures continuously whether the stock is reliable; a full count remains possible when an obligation or an auditor asks for it.
How long does it take to make stock right?: Six weeks in the typical calendar: one to write the rules and the product record, one for the ledger and the take-over of stock as an opening movement, one for capture and offline, one for reservations and transfers, one for cycle counting, one for alerts and the first review. The duration depends on the number of locations and the state of the existing product record.