Catalog, inventory, and sales data can drift apart
A Magento store keeps product data, stock data, and order data in separate groups of tables. Those groups are supposed to stay consistent, but imports, deletions, and integrations can make them disagree over time.
The results reach customers. A product can show the wrong stock level. An order can reference a product that no longer exists. Salable quantity can differ from the units the business can actually sell. Overselling is the most expensive result.
This article explains how these three data sets become inconsistent, why inventory reservations are a common cause, and how to find the problem before customers report it.
Three data sets must agree
The catalog stores product information in the catalog_product_entity family of tables. Inventory tables store stock information. Sales tables store orders. Each group is the main source for its own type of data, and the groups reference each other.
Those references can break if a product is deleted, an import stops partway through, or an integration writes stock directly. An order item may point to a product ID that no longer exists. A stock record may remain after its product is gone.
The store may continue running after this happens. The problem appears later as wrong numbers on the storefront or in reports, which makes it harder to trace than a direct application error.
Reservations change salable quantity
Multi-Source Inventory calculates salable quantity from stock on hand and inventory reservations. A reservation temporarily reduces the quantity Magento can sell after an order is placed. Magento should clear or compensate for that reservation when the order ships or is cancelled.
This calculation works only when the reservation lifecycle stays consistent. If a reservation is left behind, salable quantity can move away from the physical stock. A product may show out of stock while units sit in the warehouse, or the store may oversell because the reservation math is wrong.
Check reservations against orders
Magento includes a command for finding reservation inconsistencies. It compares reservation records with the orders that should own them and reports mismatches.
bin/magento inventory:reservation:list-inconsistenciesThe output lists the SKUs and orders where reservations do not match the order state. When Magento finds inconsistencies, the companion inventory:reservation:create-compensations command generates corrective reservation records. Those records bring salable quantity back in line with the order history.
Run the list command on a schedule and after bulk order or import operations. Finding a small mismatch is easier than repairing a large group of reservations later.
Deleted products can break historical links
When a product is deleted, its order history should remain. The link between the order item and the catalog product changes because the product no longer exists. Code that assumes the product is still available can fail.
This can appear as an error on an order page, report, or export that tries to load product data for an old order. The order data is still present. The catalog record it references is missing.
Code that reads order items should check whether the referenced product exists before using its data. To find these cases, inspect the queries and joins that connect product data to historical orders.
Stock status can disagree with quantity
Magento stores a product's stock status and quantity separately. A product can have a positive quantity while its status says out of stock. The reverse can happen too if an import or direct write updates one value and not the other.
Reindexing the inventory and stock indexers can rebuild derived data from the source rows. It cannot repair source data that already contradicts itself. A reindex can spread the contradiction to more parts of the store.
Direct writes to inventory tables are a common cause of this problem, especially in ERP integrations. The integration may update quantity without updating stock status or starting the reindex required to recalculate related data.
Bulk imports create data drift
Much catalog and inventory drift starts with bulk operations. A product import can stop partway through. A stock update can write directly to tables. A feed can run without validating the data first. Each case can leave the data sets out of sync.
Direct writes are risky because they bypass the logic that keeps related tables consistent. An ERP that updates cataloginventory_stock_item directly, without using Magento's API, can change quantity without updating stock status or triggering the reindex that should reconcile the data.
The safer path is to write through Magento's service contracts and APIs. Those interfaces apply the logic that maintains relationships between tables. If an integration requires direct writes, add it to the data-integrity audit and verify every related update.
Data integrity protects revenue
Data integrity across catalog, inventory, and sales controls what the store displays, sells, and reports. If those data sets disagree, the store can show incorrect stock, sell units it does not have, or report numbers the team cannot trust.
Check reservation consistency, product references in order history, and the relationship between stock status and quantity. These checks turn quiet data drift into a specific repair list for a checkout-focused platform review.