Magento’s Multi-Source Inventory prevents overselling through reservations. When a shopper places an order, MSI does not immediately reduce the warehouse stock; instead it creates a reservation record that lowers the product’s salable quantity. Salable quantity is the real stock minus the sum of active reservations for orders that have not yet shipped. This lets many shoppers check out concurrently without two of them buying the last unit, as long as the reservation system stays consistent and its cleanup cron runs.
Overselling, promising stock you do not have, is one of the most damaging things a store can do, because it turns a sale into a cancellation and a disappointed customer. Reservations are how Magento avoids it, but the mechanism is widely misunderstood, and when it drifts out of sync it causes both phantom out-of-stocks and real oversells. This guide explains how reservations actually work and how to keep them healthy on a busy store.
How salable quantity is really calculated
The number a shopper effectively sees as availability is salable quantity, and it is not simply the count in the warehouse. Salable quantity is the source stock minus the sum of all active reservation rows for that product. A reservation row is created when an order is placed and represents stock that is committed but not yet shipped.
So if a product has 100 units in the warehouse and 12 are in placed-but-unshipped orders, its salable quantity is 88. That 88 is what governs whether the next shopper can buy. This separation, physical stock in one place, committed stock tracked as reservations, is what lets Magento handle concurrent checkouts safely. Two shoppers racing for the last unit cannot both succeed, because the first reservation drops salable quantity to zero before the second can place an order.
The reservation lifecycle
A reservation is not permanent. It moves through a lifecycle tied to the order:
- Order placed. A reservation row is created that reduces salable quantity. Physical source stock is unchanged.
- Order shipped or invoiced. The source stock is decremented for real, and a compensating reservation is written so the two do not double-count.
- Cleanup. Once an order is fully resolved, its reservation rows sum to zero for that SKU, and the cleanup process removes them.
The key insight is that reservations are a running ledger. Each SKU accumulates rows that should net out as orders complete. By default the cleanup runs once a day and removes reservations whose sum is zero for a SKU, keeping the ledger from growing forever. When this lifecycle runs cleanly, salable quantity stays accurate. When it breaks, problems appear.
Why reservations drift out of sync
Inconsistencies are the source of most MSI pain. A reservation inconsistency means the reservation ledger no longer matches reality, so salable quantity is wrong. Common causes include orders canceled or modified outside the normal flow, data imports that change stock without adjusting reservations, custom code that touches inventory directly, and past bugs that left orphaned rows.
The symptoms are two-sided. If reservations over-count committed stock, products show as out of stock when they are not, and you lose sales to phantom stock-outs. If they under-count, salable quantity is too high and you oversell. Both are corrosive: one hides available inventory, the other promises inventory you cannot ship. On a high-volume store the drift accumulates quietly until a category looks half out of stock or cancellations spike.
Magento provides tooling to detect and repair this. You can list inconsistencies and generate compensating reservations to bring the ledger back into balance, which is the standard fix when salable quantity has drifted. Running that repair, and then addressing whatever caused the drift, is core to keeping a busy store honest, and it is the kind of maintenance a serious Magento development team builds into its operations.
Keeping reservations healthy and fast
Beyond correctness, reservations affect performance, because the reservation table grows with order volume and an unmanaged table slows inventory operations. Three practices keep MSI both accurate and fast:
- Run the reservation cleanup cron on a proper schedule. Clean up resolved reservations at least weekly, and for high-volume stores daily during off-peak hours, so the table does not bloat.
- Set the inventory indexer to schedule mode. As with other indexers, schedule mode keeps salable-quantity indexing efficient and off the critical admin path.
- Cache salability results with a short TTL. Caching whether a product is salable, with a brief expiry, reduces repeated computation on high-traffic product and category pages.
Together these keep salable quantity accurate under load without the reservation machinery becoming a bottleneck. Neglecting them is how a store that ran fine at launch develops mysterious inventory slowness and drift a year in.
Reservations on a Hyva storefront
Reservations are a backend mechanism, so they behave the same regardless of theme. What Hyva changes is how salable quantity is displayed. Because a Hyva theme fetches interactive data client-side and caches aggressively, showing accurate, current stock on a fast storefront takes care: the salable quantity must be fresh enough to prevent overselling but cached enough to keep pages fast. We cover that display challenge in multi-source inventory on a Hyva storefront, which pairs directly with the reservation mechanics here. The reservation system decides the true number; the storefront decides how freshly to show it.
When to reconsider the reservation model
Most stores should keep MSI reservations, because overselling protection is worth the complexity. But there are edge cases. A store with a single source, simple stock, and very high throughput sometimes finds the reservation overhead more than it needs, and there are ways to simplify inventory handling for those cases. That is an advanced decision that should be made deliberately, with a clear understanding of the oversell risk you take on, not a default reached for because reservations felt complicated. For the vast majority of multi-source or high-value catalogs, healthy reservations are the right answer.
Backorders, thresholds, and how they change the math
Reservations get more interesting once you allow backorders or set out-of-stock thresholds. If you permit backorders, salable quantity can go negative, because you are deliberately accepting orders beyond physical stock, and the reservation ledger tracks that negative commitment so you know how deep the backorder is. If you set an out-of-stock threshold above zero, say holding back a buffer of five units, salable quantity effectively hits zero while five real units remain, protecting you from the edge cases that cause oversells.
These settings interact directly with the reservation math, and misconfiguring them is a common cause of surprising availability. A store that thinks it disabled backorders but left a negative threshold can still sell into negative stock; a store with an aggressive buffer can look out of stock while inventory sits in the warehouse. Decide your backorder and threshold policy deliberately per product type, and test that salable quantity behaves the way you expect at the boundaries, because the boundary is exactly where oversells and phantom stock-outs happen.
A reservation health check for a live store
For a store already in production, a periodic reservation health check catches drift before it costs sales. Run it monthly, and after any event that touches inventory in bulk, a large import, a platform upgrade, or a migration.
The check has three parts. First, look for inconsistencies and generate compensating reservations if the ledger has drifted. Second, confirm the cleanup cron is running and the reservation table is not growing without bound, which signals resolved reservations are not being cleared. Third, spot-check a sample of products by comparing their salable quantity against physical stock and open orders, to confirm the number shoppers see matches reality.
Any surprise in those three checks points to a root cause worth fixing, custom code touching inventory directly, a cron that stopped, or an import bypassing the reservation flow. Catching it in a scheduled health check is far cheaper than discovering it through a wave of cancellations or a category that mysteriously shows half its products unavailable. Treat inventory accuracy as something you verify on a cadence, not something you assume.
Frequently asked questions
What is a reservation in Magento inventory?
A reservation is a record created when an order is placed that reduces a product’s salable quantity without immediately decrementing warehouse stock. It represents committed-but-unshipped inventory, and it is how MSI prevents two shoppers from buying the same last unit during concurrent checkouts.
How is salable quantity calculated?
Salable quantity is the source stock minus the sum of active reservation rows for that product. If 100 units are in the warehouse and 12 are in placed-but-unshipped orders, salable quantity is 88. That number, not the raw warehouse count, governs whether the next shopper can buy.
Why does my store oversell or show wrong stock?
Usually a reservation inconsistency: the reservation ledger no longer matches reality, so salable quantity is off. Over-counting causes phantom out-of-stocks; under-counting causes oversells. List the inconsistencies and generate compensating reservations to rebalance the ledger, then fix whatever caused the drift.
How do I clean up the Magento reservation table?
Run the reservation cleanup cron on a schedule, at least weekly and daily for high-volume stores during off-peak hours. Cleanup removes reservation rows that sum to zero for a SKU once orders are resolved, which keeps the table from bloating and slowing inventory operations.
Do reservations work differently on Hyva?
No. Reservations are a backend mechanism and behave the same on any theme. Hyva only changes how you display salable quantity, since a fast, heavily cached storefront must show stock fresh enough to prevent overselling while staying fast. The reservation system itself is unchanged.
Where this fits
Reservations are how Magento keeps its promises about stock: salable quantity is real inventory minus committed orders, tracked as a ledger that nets out as orders ship. Keep the cleanup cron running, the inventory indexer on schedule, and salability cached with a short TTL, and repair inconsistencies when they appear. Do that and a high-volume store prevents oversells without the reservation machinery becoming a drag.
Bemeir is the first US-based Hyva partner and a full Adobe Commerce agency, with a deep technology partner ecosystem across inventory, ERP, and fulfillment tools. We build and maintain reliable MSI and reservations on Hyva and Magento storefronts, and we also work across Shopify, Shopware, and BigCommerce. Read more about Bemeir and how we keep inventory accurate at scale.
External references: a guide to resolving Magento inventory reservation inconsistencies, the Magento inventory management documentation, and a walkthrough of how salable quantity is calculated.
