Catalog, inventory, and sales data can quietly disagree
A Magento store keeps product data, stock data, and order data in separate systems of tables that are supposed to stay consistent. Over years of imports, deletions, and integrations, they drift apart.
The results are customer-facing: products showing the wrong stock, orders referencing products that no longer exist, and salable quantities that do not match reality. Overselling is the most expensive version of this.
This article covers where these three data sets disagree, why Magento's inventory reservations are a common culprit, and how to find the inconsistencies before customers do.
Three data sets that must agree
The catalog lives in the catalog_product_entity family, stock lives in the inventory tables, and orders live in the sales tables. Each is authoritative for its own domain, and they reference each other constantly.
When a product is deleted, an import runs partially, or an integration writes stock directly, the references can break. An order item can point at a product ID that no longer exists, or a stock record can survive a product that is gone.
None of this stops the store immediately. It surfaces later as wrong numbers on the storefront or in reports, which is harder to trace than an outright error.
Inventory reservations and salable quantity
Multi-Source Inventory calculates salable quantity as the stock on hand minus reservations. Reservations are placed when an order is made and cleared when it ships or is cancelled, and the math only works if that lifecycle stays clean.
When reservations are left behind, salable quantity drifts away from the real stock. Products can show as out of stock while inventory sits in the warehouse, or oversell because the reservation math is wrong.
Finding reservation inconsistencies
Magento ships a command specifically for this. It compares reservations against the orders that should own them and reports the mismatches.
bin/magento inventory:reservation:list-inconsistenciesThe output lists the SKUs and orders where reservations do not line up with order state. When inconsistencies exist, the companion inventory:reservation:create-compensations command generates the corrective reservations to bring salable quantity back in line.
Running the list command periodically, and especially after any bulk order or import operation, catches this drift while it is small.
Orphaned order items and deleted products
When a product is deleted, its order history should remain, but the link between them changes. Order items reference a product that no longer exists in the catalog, and code that assumes the product is still there can error.
This shows up as errors on order views, in reports, or in exports that try to load product data for old orders. The order data is intact, but the catalog it points to has moved on.
The fix is usually defensive: code that reads order items should not assume the referenced product still exists. Finding these cases means checking where product data is joined to historical orders.
Stock status versus quantity
A product's stock status and its quantity are stored separately, and they can disagree. A product can show a positive quantity but a status of out of stock, or the reverse, when an import or a direct write updated one and not the other.
Reindexing the inventory and stock indexers resolves the derived data, but only if the underlying rows are consistent. When status and quantity contradict each other at the source, a reindex propagates the contradiction rather than fixing it.
This is why direct writes to inventory tables, common in ERP integrations, are a frequent source of stock display problems.
Bulk imports are where drift begins
Most catalog and inventory drift traces back to bulk operations. A product import that partially failed, a stock update that wrote directly to the tables, or a feed that ran without proper validation all leave the data sets slightly out of step.
Direct writes are the most dangerous, because they bypass the logic that keeps related tables consistent. An ERP that updates cataloginventory_stock_item directly, without going through Magento's API, can set a quantity without updating stock status or triggering the reindex that would reconcile them.
The safer path is to write through Magento's service contracts and APIs, which maintain the relationships between tables. When an integration insists on direct writes, it becomes a standing source of the drift this article describes, and it belongs on the audit list for that reason.
Consistency is a revenue question
Data integrity across catalog, inventory, and sales is not an abstract concern. It decides whether the store shows correct stock, sells what it actually has, and reports numbers you can trust.
Knowing whether your reservations are consistent, your order history references intact products, and your stock status matches quantity turns quiet data drift into a fixable list. That kind of integrity check is a core part of any checkout-focused platform review.