Case study: keeping inventory balances and stock transactions consistent
Inventory appeared in receipts, sales, transfers, adjustments, returns, and reservations, but a dependable available quantity could not rely on unrelated screens updating separate numbers correctly. Simor Soft designed the workflow around controlled stock movements and traceable balances.
Published August 18, 2026 · In-depth engineering case study
Case study at a glance
Inventory correctness is a concurrency and accounting problem as much as an interface problem. A plausible quantity may miss a transfer leg, include an unposted receipt, duplicate a retry, or ignore a reservation. Corrections must restore truth without erasing the evidence needed to explain it.
The approach defined authoritative transaction types, atomic posting boundaries, idempotent integration behaviour, controlled negative-stock rules, and repeatable reconciliation. Users could trace a balance to its movements and correct exceptions through governed entries rather than hidden edits.
Define inventory quantities precisely
The team separated on-hand, available, reserved, allocated, in-transit, damaged, expected, and financially posted quantities. They answer different questions and cannot share one unexplained field. Definitions included location, item, unit, status, ownership, and effective time.
Each screen and integration stated which quantity it consumed. A sales promise may use available stock, a cycle count concerns physical on-hand, and finance may depend on posted value. This vocabulary prevented a technically correct number from being applied to the wrong decision.
Use movements as durable evidence
Stock changes were controlled transactions carrying item, location, quantity, unit, direction, source document, timestamp, status, and correlation identifiers. Current balance remained efficient to obtain but explainable through movement history. Users did not overwrite the balance to make a screen appear correct.
Relations connected a receipt to its purchase order, a shipment to its sale, and both transfer legs to one event. Reversals and adjustments created new evidence rather than deleting original postings. Investigation and correction could therefore preserve chronology and accountability.
Make dependent posting atomic
Operations that had to succeed together shared one transactional boundary. A transfer could not reduce one location while silently failing to create the destination or in-transit position. A sale-related deduction and its business status could not drift because one update completed and another failed.
Concurrency rules covered users or services acting on the same units at nearly the same time. Availability was validated at the authoritative write boundary, not only when a page loaded. Appropriate conditional updates, locking, or isolation protected correctness ahead of optimistic interface assumptions.
Prevent duplicate processing
Messages and user retries can repeat after a timeout even if the first request succeeded. Each operation carried an idempotency or correlation key. The service recognized an already posted event and returned its existing result instead of changing stock twice.
A safe retry was distinguished from a new transaction. Monitoring recorded rejected duplicates, failed messages, and review items. Recovery described how to resume after interruption without replaying an uncertain batch blindly, making integrations dependable under imperfect network conditions.
Handle reservations and availability
Reservations were separate from permanent physical movements but connected to the authoritative item and location. Creation, expiry, release, and conversion rules were explicit. Available quantity included only active holds and respected locations that could actually fulfill the request.
Tests covered the last units, cancellation during payment or fulfillment, expired holds, partial completion, and multi-location allocation. A reservation could not be treated as casual cache data when overselling or unnecessary denial would result; its lifecycle required transaction discipline.
Control negative stock and corrections
Negative inventory was not governed by one universal rule. Some workflows blocked it; others allowed a controlled exception with role, reason, threshold, and follow-up. The consequence was visible instead of silently distorting replenishment and costing.
Counts and investigations produced adjustment transactions with reason and approval where material. Backdating, closed periods, unit conversion, and lot or serial constraints were checked before posting. Corrections restored state while retaining the original record and accountable decision.
Reconcile modules and interfaces
Reconciliation compared movement totals, calculated balances, location summaries, reservations, and connected document status. Exceptions were classified as timing, missing, duplicate, or invalid transactions. Reports exposed identifiers needed to follow one event across purchasing, warehouse, sales, and finance.
A successful transport response did not prove every line was accepted. Control totals, sequence gaps, retry queues, and unresolved errors provided stronger evidence. Scheduled reconciliation found drift before fulfillment or month-end users encountered it.
Outcome and lasting lesson
The design produced traceable answers to two questions: what quantity is usable now, and which movements created it? It reduced manual balance editing and gave support a structured path for discrepancies. The same evidence supported operational reporting and downstream costing.
Inventory integrity comes from explicit definitions, atomic state changes, durable history, duplicate protection, and reconciliation. A polished stock screen cannot compensate for weak posting semantics. Correct foundations allow interfaces, replenishment, alerts, and analytics to build on a source users can trust.
Exception handling protected the inventory ledger
The team treated retries, cancellation, reversal, partial completion, and dependency failure as ordinary operating conditions. A receipt could not update quantity and then fail before creating its traceable movement. A transfer could not reduce one warehouse twice because a caller retried after losing the response. An adjustment required a reason and authorization rather than an overwrite of the displayed balance.
Every posting used a stable business reference and an atomic boundary for the records that had to agree. Where an external dependency could not join that boundary, the workflow recorded a recoverable state and used idempotent processing, reconciliation, and an owned exception queue.
Reconciliation located the broken boundary
The investigation compared product and location balances with movement totals, source-document quantities, reservations, in-transit stock, production consumption and output, returns, and valuation. Differences were segmented by transaction type, date, integration, and status so the team could find whether the defect came from posting, reversal, retry, migration, or an incomplete workflow.
Repair did not mean editing a balance until totals matched. The correction created durable evidence, preserved the original transaction, and restored agreement across the affected documents and accounting result.
Release tests used competing inventory actions
- Receive the same supplier delivery twice through a repeated request.
- Reserve and ship while another user transfers or adjusts the item.
- Cancel a partial transfer after the source quantity has moved.
- Reverse production consumption and completed output.
- Post a backdated transaction near a closed financial period.
- Interrupt an integration between source acceptance and ERP posting.
Tests verified quantity, availability, status, movement history, source document, valuation, COGS where relevant, permissions, and the final general-ledger relationship. Monitoring retained transaction identity and failure stage without exposing unnecessary business data.
The lasting design rule
Inventory balance is a result that must be reproducible from governed movements and source events. A fast balance field is useful for operation, but it cannot become an unexplained authority. Durable transaction identity, atomic posting, idempotency, controlled reversal, and reconciliation make the result supportable as volume and integrations grow.
Simor Soft applies this experience across receipts, deliveries, transfers, adjustments, production, returns, landed cost, valuation, and profitability. A live technical review can follow one difficult scenario through the database-facing service, permissions, user interface, audit history, and financial result. The lesson is reused as an investigation method, not as an unsupported claim that every inventory discrepancy has the same cause.
Operational monitoring continued after release
The team monitored failed postings, repeated business references, negative-quantity attempts, old in-transit transfers, reservation mismatches, adjustments, backdated activity, and reconciliation differences. Each signal had a threshold, owner, investigation path, and closure evidence. A high adjustment count was not treated automatically as a software defect; the review separated late warehouse activity, training, policy, integration, migration, and posting logic.
Support documentation included transaction states, diagnostic identifiers, safe retry rules, approved reversal paths, and the reports used for reconciliation. This allowed incidents to be contained without bypassing the ledger or making an undocumented database correction.
Why a displayed balance was not sufficient evidence
A balance can appear correct after two offsetting errors, while the underlying history remains unreliable. The case therefore verified movement sequence, source references, unit conversions, locations, status, and accounting relationships rather than accepting the final number alone. This mattered for backdated investigation, inventory valuation, customer fulfilment, and future corrections.
Reports showed both the current quantity and the transactions that produced it. Users could distinguish on-hand, reserved, available, damaged, and in-transit quantities, while support could identify the first inconsistent event instead of adding another adjustment to conceal it.
Migration checks protected the first production balance
Opening quantities were reconciled by product, warehouse, location, status, unit, and value. Open receipts, deliveries, transfers, returns, reservations, and production orders were classified so the same obligation did not appear once in the balance and again as an open transaction. The team tested representative migrated records through their next normal action.
Cutover ownership covered the final physical count, transaction freeze, interface pause, import, reconciliation, approval, and controlled reopening. Differences were resolved before ordinary users began posting, reducing the chance that migration uncertainty would be hidden inside later adjustments.
Units and status changes were reconciled explicitly
The test set included purchasing units that differed from stocking units, partial receipts, damaged quantities, quality holds, and approved returns. Each transition had to preserve the original reference, conversion factor, quantity, value, and responsible user. This prevented a correct total from concealing an incorrect location or unusable stock status.