Magento 2, MSI, and inventory_reservation after ERP integration

Magento 2 with MSI can handle multi-source inventory, reservations, and salable quantity very well. The problem starts when this mechanism lands in an implementation where the real source of truth for stock is not Magento, but an ERP or an external WMS. In that model, the reservation logic often still works technically, but from a business perspective it is no longer needed. Instead of helping, it starts distorting the view of availability.

This is one of those issues that can look harmless for a long time. The store works, orders keep coming in, stock imports complete correctly, and yet after some time questions start to appear:

• why salable quantity does not match the stock level from ERP
• why a product is unavailable even though ERP shows it as available
• why there are hundreds of thousands or millions of entries in inventory_reservation
• why diagnosing stock-related issues in Magento becomes increasingly difficult

In practice, this is a very common scenario in stores that are already mature from an integration perspective and operate in an ERP-first model.

Where the problem begins

In standard Magento 2 with MSI, entries in inventory_reservation are created when orders are placed and later compensated by subsequent operations such as shipment or cancellation. In theory, everything is consistent. In practice, if the store regularly overwrites stock from ERP, Magento is no longer the only source of truth and does not manage inventory independently.

That means two different logics start working in parallel:

• ERP defines the actual stock availability
• Magento still maintains its own reservation layer

If that architecture has not been deliberately organized, discrepancies start to appear. Not always immediately, but over time, almost always.

Symptoms we see in projects

Most often, the problem shows up in one of several forms.

1. salable quantity is lower than the stock level from ERP

This is the most common case. The store team sees that ERP shows availability, while Magento still blocks sales or lowers the number of units that can be purchased.

2. The inventory_reservation table keeps growing

In stores with higher order volume, this table can grow very quickly. Growth alone is not necessarily a bug, but in an ERP-first model it often becomes just an unnecessary maintenance cost and another place that obscures the real stock picture.

3. Harder diagnosis of stock problems

When product availability depends at the same time on ERP import, Magento indexing, and stored MSI reservations, diagnosis stops being simple. The team has to analyze whether the issue is caused by import, index, stock, source assignment, or the inventory_reservation table itself.

4. Conflicts between import and Magento’s current logic

In some implementations, Magento behaves correctly from the perspective of its own rules, but not according to business expectations. This is an important distinction. A system does not have to be technically broken to behave incorrectly in a given operating model.

Why the standard approach is not always enough

In theory, you could say: if Magento has MSI, just let it work. The problem is that MSI was not designed specifically for every ERP integration model. In some implementations, it is the ideal architecture. In others, it requires deliberate simplification.

This is not about fighting Magento. It is about removing from the process the elements that no longer create value in a given implementation and instead start causing damage.

In an ERP-first environment, the priorities are usually:

• consistency with stock levels from ERP
• predictable behavior
• fast automation
• a small number of places where discrepancies can arise

If MSI reservations are not actually used as a real stock protection mechanism, cleaning them regularly is often simply the most practical solution.

How we approach the solution

In such projects, we do not try to "fix MSI" or rebuild reservation history. That usually leads to unnecessary complexity. Instead, we start with the question of what operating model the store actually uses.

If the store works in a model where there is:

• ERP as the source of truth
• cyclical import of stock into Magento
• acceptance of a short delay between ERP and the store
• no need to maintain persistent reservations on the Magento side

then the most reasonable direction is controlled, fast, and safe cleaning of inventory_reservation.

What matters in this type of solution

Simply "deleting records" is not enough. Such a solution must be operationally predictable.

That is why we pay attention to several elements:

• the ability to run automatically with CRON
• the ability to run manually from CLI
• protection against parallel execution
• diagnostic mode without deleting data
• optional reindexing after the process
• the ability to run only in specific environments
• a sensible performance model for large tables

This is exactly the approach behind our module.

Kowal Reservation Cleaner for Magento 2

For projects where the MSI reservation problem kept coming back, we created our own module: Kowal Reservation Cleaner for Magento 2.

We built this tool for ERP-first implementations where inventory_reservation should be kept clean, or at least fully under control.

The module does not remove MSI from Magento and does not modify core behavior. Its task is to organize the reservation layer so that the store keeps:

• consistency with the adopted stock synchronization model
• predictable behavior after ERP import
• simpler availability diagnosis
• lower risk of understated salable quantity

How our module works

The module supports three main operating modes.

full_reset

This is the simplest mode and usually the most practical one. If cleaning should cover all stocks, the module uses the very fast:

TRUNCATE TABLE inventory_reservation

That matters, because in large stores with large tables, a regular mass DELETE can be unnecessarily heavy.

log_only

This mode is used for diagnosis. It does not remove data, but it lets you observe how quickly the reservation table grows and whether the implementation actually needs automated cleaning.

clean_after_erp_sync

This variant is intended for teams that want to clearly link the cleaning moment with the ERP import schedule. For example: ERP synchronizes stock at 02:00, and the module cleans reservations at 02:10.

Cleaning only selected stocks

This is one of the functions that works particularly well in more complex multi-stock implementations.

Not every store wants to clean the entire inventory_reservation table. Sometimes the problem concerns only selected stocks, specific channels, or a separated logistics model. In such cases, the module lets you limit cleaning only to indicated stock_id values.

That means:

• for all stocks, you can use very fast TRUNCATE
• for selected stocks, the module switches to selective DELETE

This is a compromise between performance and control. In many implementations, that is exactly the right compromise.

CRON, CLI, and process safety

The module can run automatically from Magento CRON or manually through CLI. This matters because different stores follow different integration models.

In practice, we usually see two scenarios:

• cleaning triggered at a specific time from the Magento schedule
• cleaning triggered directly after ERP import by an integration script

The module includes:

• a locking mechanism
• file logging
• execution time control
• dry-run mode
• optional reindexing
• optional cache clean

These are details that may look technical in a product description, but in production they decide whether the solution can be maintained without stress.

What this gives from a business perspective

From an operational perspective, the most important benefits are quite concrete:

• fewer product availability issues
• better consistency between Magento and ERP
• less time wasted on stock diagnostics
• a simpler MSI maintenance model in the store
• the ability to automate the process without modifying core

This is not a module "for every Magento store". And that is exactly its advantage. It was designed for a specific type of implementation that genuinely struggles with this problem.

When it makes sense to consider this approach

If in your store:

• stock is regularly overwritten from ERP
• Magento should not be the main stock management layer
• inventory_reservation keeps growing and makes analysis harder
• salable quantity diverges from the real stock level
• your team needs a simpler operating model

then regular reservation cleaning may be a reasonable direction.

Of course, not always. In stores that rely on native MSI logic as the key stock-control mechanism, this approach will not be correct. That is why you first need to understand the business model, and only then choose the solution.

Summary

The problem with inventory_reservation in Magento 2 usually does not come from MSI being "bad". It comes from the fact that a mechanism designed for one operating model is used in another model, most often heavily integrated with ERP.

In such implementations, the priority is not maximum complexity, but predictability and consistency with the real warehouse process. That is why in some stores the best solution turns out not to be expanding MSI logic, but deliberately simplifying it.

If you are looking for a ready-made solution for this scenario, take a look at our module: Kowal Reservation Cleaner for Magento 2.

If instead you first want to assess whether your store really has this problem, it is worth starting with an analysis of the stock synchronization model, the way MSI is used, and the behavior of salable quantity after ERP import.

Sources

• Product page for Kowal Reservation Cleaner for Magento 2: https://kowal.store/kowal-reservation-cleaner-dla-magento-2