What negative inventory actually means.
Negative on-hand means the system sold more units than it knew you had. Either the sale was real and the receipt was missing, or the receipt was real and a transfer was unbooked, or someone keyed a wrong SKU at POS and depleted the wrong line. In every case, your physical inventory and your book inventory have diverged in a specific direction: the physical has more than the book says, somewhere.
Most ERPs allow negative inventory by default and let you sort it out later. This is the wrong default. Once negative is allowed, COGS gets posted at last-known WAC for units that may not exist, the next receipt blends a phantom history into a new layer, and reconciliation becomes a forensic exercise. Nonari blocks negative inventory by default, with a permission-gated override.
Cause 1: missed receiving.
Goods physically arrived at the branch but the GRN (goods received note) was never posted. The cashier sees the SKU on the shelf, scans it, sells it, and the system goes negative because the receipt never landed. This is the most common cause in busy multi-branch operations where receiving and selling are different people and the receiver got distracted.
Fix: enforce a rule that goods cannot be put on the sales floor until the GRN is posted. Tag receiving area separately from sales floor. The receiving person posts the document, prints the put-away list, and only then does the sales floor see the stock. Nonari supports this with location flags — sales register cannot pull stock from the receiving location, only from the sales floor location.
Cause 2: unposted transfer.
Branch A dispatched 50 units to Branch B. Branch A booked the dispatch, in-transit increased, A on-hand decreased. Branch B received the goods physically but never posted the receipt. Stock is now sitting in in-transit on the books while sitting on Branch B's sales floor in reality. When Branch B sells one, on-hand goes negative.
Fix: receipt-on-truck-arrival policy. Goods arriving from another branch must be received in the system within the same day, ideally within an hour. Enforce with a daily report of in-transit balances older than 24 hours, escalated to branch manager. Most chains never see in-transit older than 48 hours after this policy is introduced.
Cause 3: wrong-sku scan at pos.
Cashier scans a similar-looking item, the system depletes the wrong SKU, on-hand goes negative on a SKU you actually still have. Meanwhile the SKU you really sold is now over-stated. Net inventory value might look fine; per-SKU view is wrong everywhere.
Fix: barcode discipline. Every SKU has a unique barcode. Cashiers cannot manually key a SKU code unless permission-gated. Items without barcodes get bagged and printed with shelf labels containing the barcode. Cycle counts catch the residual errors and the system surfaces them as variance.
Cause 4: returns posted as new sales.
Cashier processes a customer return as a fresh negative-quantity sale rather than as a return document. Some POS systems let you do this; some prevent it. When done as a negative sale, the inventory increases (good) but COGS reverses at current WAC instead of the original sale's WAC, and any sales reports for the period are distorted. Worse, if the return is keyed wrong (positive instead of negative), inventory decreases and goes negative.
Fix: returns are a separate document type, never a negative sale. The return document references the original invoice, reverses inventory at the original sale's WAC, and posts to a Returns account separately from Sales. Nonari requires this — there is no negative-quantity sale path in the POS by design.
Cause 5: bom consumption with insufficient components.
A production run starts but one component is short. Some systems will let you start the run and post negative on the short component, expecting a receipt to land later. If the receipt does not land, you have phantom finished goods costed against missing raw materials.
Fix: production run validates component availability before starting. If short, the run either reduces to producible quantity or refuses to start. Nonari blocks production starts on insufficient components, configurable per BOM.
How to clean up existing negatives.
Run a negative on-hand report across all branches. For each negative SKU, check the last 30 days of transactions: receipts, transfers, sales, returns, adjustments. The error is almost always in the last 30 days. When you find it, post a correcting entry — usually a missed GRN that lands as a backdated receipt, or a missed transfer receipt that lands as the actual receipt. Adjust dates carefully if the period has been closed.
For genuine shrinkage where you cannot identify a missing document: post an Inventory Adjustment with a clear reason code. Debit Inventory Loss, Credit BranchInventory at last known WAC. Document why. Once cleaned, turn on negative-block for that SKU class so it cannot happen again silently.
How nonari prevents negatives in the first place.
Nonari blocks negative inventory at the BranchInventory level by default. A POS sale that would push on-hand below zero is rejected with a clear message: insufficient stock. The cashier can either find the missing receipt, transfer in from another branch, or escalate to a manager with override permission.
Override is logged with reason, manager identity, and timestamp. Reports show overrides per branch per week so you can spot the branches that are using override as a workaround for broken process. The point is not to make selling impossible — it is to surface gaps before they compound into untraceable variance.