Stock you can actually promise, across every warehouse

Almost every stock problem we get called in for describes itself the same way: the number in the system is right, but the number people act on is wrong. There is material in the warehouse, and there is material the warehouse has already promised to somebody. Most systems only store the first one, so the second lives in someone's head, in a message thread, or in a side spreadsheet that has gone stale by Wednesday.

Where the number goes wrong

The trouble is rarely a counting problem. It is that a single word - stock - is being used for at least five different quantities, and the software only stores one of them.

• What is physically on the shelf right now, in that specific warehouse
• What is already committed to confirmed orders or production runs and cannot be sold again
• What is genuinely free to promise to the next customer who calls
• What each of those units actually cost, which is rarely the current purchase price
• Material sitting in your warehouse that belongs to a customer or partner rather than to you

Once those collapse into one on-hand figure, the failure modes follow automatically. Two teams promise the same units. Counts only reconcile at month-end, if then. Margin becomes a monthly estimate rather than a number attached to each order.

How we build it instead

Available and reserved, held separately

Every stock row is keyed on the warehouse, the exact product variant, and the owner of the goods, and it carries two quantities rather than one: available and reserved. Confirming an order does not deduct stock. It moves quantity from available to reserved and writes a reservation row pointing back at the exact order line that caused it.

That back-pointer is the part that matters. "What is this material reserved for?" stops being an investigation and becomes a query. Cancel the order and the reservation releases; dispatch it and the reservation is consumed rather than silently deleted. Reservation events are kept in a separate ledger from real goods movements, so a soft commitment can never distort valuation.

Cost tracked in layers, not averages

The second half of inventory truth is cost. Every inbound movement - a purchase receipt, a production run, opening stock, a customer return - opens a cost layer recording how many units arrived, at what unit cost, and on what date. Every outbound movement records exactly which layers it drew from and how many units it took from each.

• Cost of goods sold is computed from real consumption rows, not a blended average
• Margin can be reported per order, per production run, or per customer, because each one knows the layers it consumed
• Editing or cancelling a document reverses precisely the consumption it created, with no manual correction entries
• Older stock is consumed first by default, so valuation follows the physical reality of the warehouse

A ledger that explains itself

Every movement writes a transaction row: what changed, by how much, at what cost, which document caused it, who did it, and when. Where a row is later corrected - an order edited after invoicing, a production entry cancelled, a vendor bill that revised a receipt cost - the row records why it changed instead of quietly showing a different number.

This is what turns a stock screen into something a finance team will trust. "Why is this number what it is?" becomes answerable from the screen, without tracking down whoever entered it.

Goods you hold but do not own

Job work, consignment, and OEM arrangements all create the same awkward situation: material in your warehouse that is not your asset. Recording it as normal stock overstates the balance sheet. Keeping it in a separate sheet makes it invisible when someone checks availability.

We put ownership on the stock row itself. The warehouse view shows everything physically present, valuation counts only what you own, and when your own material is temporarily used to keep a line running, the system records the borrowing and squares it against the owner's next receipt rather than leaving it to memory.

When this is worth building

Not every business needs this depth. If you hold a few hundred items in one location and sell them roughly as they arrive, a simpler system is the right answer. The signal that you have outgrown it is usually one of three things: your sales team has started checking with production before confirming anything, your month-end stock adjustment has become a routine line item rather than an exception, or you can report revenue accurately but not margin.

Those three symptoms share one root cause, and it is not carelessness. It is a data model that was never asked to hold committed, available, and owned as separate facts. Fixing the model fixes all three at once.