Reservation audit report

The reservation audit report can be found in Brightpearl's Magento module 3.

The Reservation audit report can be found:

  • Magento module 3.x: Brightpearl > Brightpearl Integrations > Reservations

The Reservation audit report cross-references items allocated within Brightpearl with Magento's reservations system. The report can clearly identify when inventory is balanced, is in an undersell or is in an oversell state to allow merchants to more easily troubleshoot MSI discrepancies.


The Reservation audit report, along with the Allocations report, will only be active if MSI is installed and enabled.

Status definitions and troubleshooting guide

Underselling (expected behavior)


There are more Magento reservations than corresponding allocations for a given product (i.e. insufficient allocation records).


Underselling can occur when:

  • The functionality providing allocations is first installed into a site that has previously exported orders to Brightpearl.
  • Allocation records are deleted via the database or via the admin screen

The situation is expected during an upgrade when allocations are first introduced, and is automatically resolved over time as the system converges towards accuracy with each new order exported and shipment created (i.e. each new allocation record created / old Magento reservation released).

Once the orders that existed in Brightpearl prior to installation of the allocations mechanism are fulfilled (i.e. the Magento reservations are resolved), the accounting process achieves accuracy and the system naturally maintains that state going forward.


Temporary. The extent of the underselling inaccuracy is affected by:

  • The number of inaccurate inventory levels depends on the number of SKUs sold per day
  • The duration of the inaccuracy (the underselling) depends on how long it takes to fulfill orders
  • The frequency of MSI imports affects how often the numbers are recalculated - higher frequency can converge accuracy sooner, or make it worse if fulfillment is slow.

If orders are shipped the same day, accuracy should be achieved within 24 hours.


None. Continue normal operation and allow accuracy to naturally improve as data aligns.


The imported Brightpearl on hand stock levels (which accounts for the existing unfulfilled orders in Brightpearl) have no corresponding allocation records within Magento to indicate adjusting this value upwards.

Therefore the Magento saleable quantity can be smaller than it should be, which can result in the under-selling of affected SKU.

Balanced (expected behaviour)


The Magento reservations and allocation records are aligned for a given product


This can occur when:

  • The module is first installed on a site which has no orders in Brightpearl. The accounting mechanism functions accurately immediately regardless of any existing Magento reservations.
  • When convergence is naturally reached following an underselling scenario (above).


MSI stock levels are imported accurately.


None, the system is working as intended.


The imported Brightpearl stock on hand values (which includes deductions for items on exported orders) correspond to allocations, which correspond to Magento reservations for Brightpearl exported orders.

The allocation adjustments resolve the double deduction (of on hand stock and Magento reservations) to yield an accurate saleable quantity.

Overselling (critical)


There are more allocations than corresponding Magento reservations for a given product.


This state should never occur under normal operation, and requires fixing. It could be introduced by:

  • Manually deleting Magento reservations from the database.
  • External code interfering with standard mechanisms that yield allocations or reservations


High. Overselling represents an urgent problem as it will not resolve itself, and will likely get progressively more severe.


This problem cannot resolve itself, and requires intervention. If the system becomes misaligned like this (and provided the underlying code causing the problem has been resolved), the data solution is to empty the allocation table (this can be done via the Brightpearl / Allocations menu). Emptying the allocation table temporarily causes underselling whilst allocations and reservations align, but restores stability.


If an allocation exists (without any corresponding Magento reservations), and the Brightpearl on hand stock level is zero, the next MSI import will adjust the stock level upwards from zero (by the allocation amount) resulting in a saleable SKU.

If a customer then buys that nonexistent SKU, another allocation is created, and the next MSI import adjusts the stock level upwards even more than before (so that stock increases with each sale until the problem is detected and resolved).

Have more questions? Submit a request