Why stock on hand and stock available to sell can differ
A product can have physical stock in a warehouse while Magento refuses to sell it. The reverse can also occur: a storefront appears to offer stock that operations cannot fulfil. These situations need a traceable explanation, not an arbitrary quantity adjustment. Start with one SKU, the affected website and the exact purchase quantity that produces the problem.
Midoriweb separates physical inventory, the quantity available for the sales channel and the customer-facing stock message. Each can be influenced by different rules and update paths. A warehouse receipt, an open order, a cancellation and a shipment are different events. Treating every number labelled “stock” as interchangeable makes reconciliation unreliable and can hide the event that caused the discrepancy.
If the problem begins in an external stock feed, the inventory synchronisation guide is the next step. This article focuses on interpreting stock availability within Magento’s inventory model before changing records.
Establish the exact sales channel and product
Record the SKU, product type, website, selected variant and quantity requested. With configurable products, the child variant matters. A parent product can be visible while one size or colour cannot be purchased. Compare the same child SKU in the operational records and the storefront rather than mixing parent-level presentation with variant-level inventory.
Check whether the website is connected to the intended stock and whether the relevant sources are enabled and assigned as expected. A quantity in the wrong source or sales-channel context may not support the purchase being tested. Also review minimum quantity, backorder and stock-status settings applicable to that product.
Do not change several settings together simply to make Add to Cart work. Record the expected business rule first. A successful purchase created by enabling backorders may conceal a stock-mapping defect rather than resolve it.
Understand reservations through the order lifecycle
Adobe’s source selection and reservations documentation explains how reservations participate in salable quantity. The important operational distinction is that accepting an order and physically deducting stock are not necessarily the same moment. Open commitments need to be considered alongside warehouse quantities.
For an affected SKU, follow recent order events rather than looking only at the current total. Establish which orders were placed, shipped, cancelled or otherwise progressed. Compare those transitions with the expected inventory behaviour for the installed version and any custom integrations.
A suspicious reservation balance is evidence to investigate. It is not permission to delete reservation rows. Manual changes can break the relationship between open customer commitments and stock availability, especially when shipments or cancellations are still being processed elsewhere.
Trace one mismatch from its last known correct state
Choose a manageable example with a clear history. Record the last point at which the warehouse and storefront agreed, then list subsequent events in order. Include imports, manual changes, customer orders, cancellations and integration retries. Use consistent timestamps and retain the original references.
A useful reconciliation explains each change. If a warehouse feed overwrote a quantity after an order was accepted, identify whether the feed represented physical stock, available stock or a value already reduced for commitments. Applying the same deduction twice can produce a persistent difference even when every individual system is functioning as configured.
Illustrative example: a warehouse reports ten units physically present, while several are allocated to open orders. The correct storefront availability depends on which system accounts for those commitments and how that value reaches Magento. The example is not a formula to apply blindly; it demonstrates why field meaning must be agreed before mapping values.
Distinguish inventory data from stale presentation
If internal inventory values look correct but the storefront does not, inspect the processing and presentation layers. Relevant indexing, caching, custom stock labels or a headless frontend can affect what the customer sees. Compare the product page, cart validation and checkout result rather than assuming they all use the same representation.
Our stuck indexer guide helps investigate processing delays. The full-page cache guide addresses a different layer. Clearing every cache is not a substitute for identifying where the wrong value first appears.
A controlled test should check both display and enforcement. A label saying “in stock” is not sufficient if the cart rejects the item. Equally, a stale label should not trigger unnecessary inventory changes when the purchase rules are already correct.
Investigate custom integrations and manual workarounds
Inventory problems often cross team boundaries. Warehouse staff, customer service and ecommerce administrators may each make reasonable local adjustments without seeing the whole process. List which systems can write stock-related fields and which one owns each value. Two authoritative writers for the same quantity require explicit conflict rules.
Review retry and ordering behaviour. A delayed older update must not silently overwrite a newer value simply because it arrives later. Record how updates are identified, whether their timestamps represent creation or delivery, and how exceptions are reported. These are integration-design questions, not problems that can be solved by one stock import alone.
Temporary manual adjustments should have an owner and a documented reason. Without that record, the next automated feed may undo the workaround and restart the incident. Midoriweb can help define the reconciliation and exception path through ecommerce integration support.
Correct the cause and verify representative cases
The recovery plan should follow the established cause. A mapping error, missing lifecycle event and delayed index require different changes. Before applying a correction broadly, test a limited affected set and verify that open orders and fulfilment remain consistent. Preserve a record of the original values and the intended adjustments.
Verification should include a normal purchase, insufficient stock, a cancellation and a partial fulfilment where those workflows apply. Use authorised test data and an appropriate environment; do not manufacture live customer orders merely to exercise the logic. Include the relevant website and product types rather than testing only a simple product in the default store.
After deployment, monitor fresh updates and the next operational cycle. A repaired historical discrepancy can coexist with a still-broken feed. The goal is agreement over time, with exceptions visible to someone who can act on them.
What to include when asking Midoriweb to investigate
Provide one or two affected SKUs, the website, the expected availability and the observed behaviour. Explain where the expected number comes from and whether the problem is constant or follows a particular import. Include the first known occurrence and recent inventory or integration changes.
We would use that brief to scope the inventory, order and integration evidence needed. The resulting recommendation should distinguish confirmed discrepancies from assumptions and explain the operational effect of any proposed repair. Credentials and customer records belong in the agreed secure access process, not the initial enquiry.
Inventory questions
Should salable quantity equal physical quantity?
Not necessarily. Open commitments and configured inventory rules can make them different. The difference needs to be explainable for the relevant SKU and sales channel.
Can I delete reservations to release stock?
Do not use deletion as a routine repair. First reconcile the order lifecycle and determine the supported corrective process for the installed implementation.
Why does only one website show the problem?
Check website-to-stock assignment, source configuration and scoped product settings. Testing the same SKU under a different sales channel can produce a different valid result.