Why Does My Brightpearl-Shopify Inventory Go Out of Sync?
Development

Why Does My Brightpearl-Shopify Inventory Go Out of Sync?

July 24, 2026OpenMalo7 min read

Inventory drift between Brightpearl and Shopify almost always traces back to a handful of causes — interval sync delays, multi-warehouse logic, bundles, field mapping gaps, and API rate limits. Here is what actually goes wrong and why.

Brightpearl and Shopify inventory go out of sync when the two systems update on different clocks or count stock differently. The most common causes are interval-based (not real-time) syncing, multi-warehouse allocation logic, bundle and kit handling, field mapping gaps, edge-case orders, API rate limits, and race conditions where two updates collide. Each is fixable once you know which one is biting you.

What are Brightpearl and Shopify, in plain terms?

Brightpearl is a retail ERP (enterprise resource planning) system — more precisely an order and inventory management system (OMS) built for retailers and wholesalers. It holds the "true" stock count, purchasing, and accounting. Shopify is the storefront where customers actually buy. In most setups, Brightpearl is the system of record for inventory and Shopify is a sales channel that should mirror it.

A SKU (stock keeping unit) is the unique code that identifies a sellable product. When people say "inventory is out of sync," they mean the available quantity for a SKU in Brightpearl no longer matches the quantity Shopify is showing shoppers.

Is your sync real-time or interval-based?

This is the single biggest cause of drift. Many integrations push stock updates on a schedule — every 5, 15, or 30 minutes — rather than the instant a number changes. During that gap, Shopify keeps selling against a stale figure.

If you run flash sales, have low stock on popular SKUs, or sell the same item across multiple channels, an interval sync will oversell. Real-time (event-driven) syncing — where a change in Brightpearl fires an immediate update to Shopify, and a Shopify order immediately decrements Brightpearl — closes that window.

How does multi-warehouse logic break the count?

Brightpearl can hold stock across several warehouses or locations. Shopify needs one clear "available to sell" number per SKU. If the integration sends the wrong warehouse's quantity, sums locations you do not actually fulfil from, or ignores allocations already committed to open orders, Shopify shows a number that was never real.

  • Sending total on-hand instead of available-to-sell (on-hand minus allocated)
  • Including a warehouse that does not fulfil online orders
  • Not accounting for stock reserved against unshipped orders

What happens with bundles and kits?

A bundle or kit is one sellable product made of several component SKUs. Brightpearl tracks the components; Shopify often sells the bundle as a single line. If the integration does not translate between them, selling one bundle either fails to decrement the components, or the components run out without the bundle's availability updating. Bundles are one of the most frequent sources of silent drift.

Are your field mappings complete?

Field mapping is the rulebook that says "this field in Brightpearl equals this field in Shopify." Gaps here cause partial syncs. Common mapping problems:

  • SKU codes that do not match exactly between systems (a trailing space or case difference is enough)
  • Variants in Shopify not mapped to the right Brightpearl product
  • New products created in one system that never get linked in the other
  • Unit-of-measure mismatches (selling in packs vs. singles)

Which edge-case orders cause drift?

Standard orders usually sync cleanly. The drift hides in the exceptions: partial shipments, cancellations, refunds, returns/restocks, pre-orders, and manual stock adjustments made directly in one system. If the integration only handles the happy path, every return or cancellation nudges the two counts further apart.

How do API rate limits and race conditions matter?

Both Brightpearl and Shopify cap how many API (application programming interface) calls you can make per second. During busy periods, updates get throttled or dropped, and a delayed update can overwrite a newer one. A race condition is when two changes happen at nearly the same moment — say, a warehouse adjustment and an online order — and they collide, leaving the count wrong. Robust integrations queue, retry, and respect the most recent change rather than blindly overwriting.

How do you fix recurring drift for good?

The durable fix is two-part: move to event-driven syncing where it matters, and add reconciliation. Reconciliation is a scheduled job that compares Brightpearl and Shopify SKU-by-SKU, flags mismatches, and either auto-corrects or alerts you — so small errors never compound into oversells.

  • Sync available-to-sell, not raw on-hand
  • Handle bundles, returns, and cancellations explicitly
  • Queue and retry against API limits instead of dropping updates
  • Run a daily reconciliation pass and log every correction

Need a Brightpearl-Shopify sync that actually holds up? See Brightpearl ↔ Shopify Integration.

FAQ

Frequently Asked Questions

Usually because Shopify is working from a stale number. If the sync runs on an interval rather than in real time, Shopify keeps selling against the last figure it received until the next update arrives. It can also happen when the integration sends on-hand stock instead of available-to-sell, ignoring quantities already allocated to open orders.

Share this article

Help others discover this content