BigCommerce's native inventory tracking keeps one stock number per SKU or variant, sends a low-stock email alert at a threshold you set, and lets you choose whether to keep selling once that number hits zero, all configurable directly in the admin without an extra app. It has no native concept of more than one location holding that stock, and no purchase-order workflow for receiving it. Both of those are what we build on top.
Turn on inventory tracking per SKU or variant, and BigCommerce decrements the count automatically as orders come in. A low-stock threshold triggers an email notification to the store admin, and a separate setting controls whether the product keeps selling, shows as out of stock but still orderable, or gets hidden entirely once inventory hits zero.
Bulk stock updates run through CSV import and export, which covers most day-to-day adjustments, a price change, a restock count, without needing to edit products one at a time in the admin. There's no native purchase-order feature tracking what's been ordered from a supplier or when it's expected to arrive; a restock is just a manual number change whenever someone updates it.
BigCommerce doesn't natively split a SKU's stock across more than one physical location. A business running multiple warehouses, or selling the same catalog through BigCommerce and a separate physical point of sale, has no built-in way to represent that split; without something layered on top, either one number gets forced to represent several real locations, or someone's manually reconciling it by hand.
The same applies across sales channels outside BigCommerce itself, a marketplace listing, a wholesale channel, a retail register. BigCommerce's own count only reflects what happens inside BigCommerce; a sale that happens somewhere else doesn't touch that number unless something's actively syncing it back, which is how overselling usually happens even when the BigCommerce number itself looks perfectly accurate.
A sale on a marketplace, a shipment received at a second warehouse, and a BigCommerce order all update the same underlying count, so BigCommerce's own number stays true to what's actually on hand everywhere, not just what happened inside BigCommerce.
Hitting the low-stock threshold creates a draft purchase order in your inventory or ERP system automatically, ready for someone to review and approve instead of starting the reorder from a blank page.
A second warehouse, another sales channel, a restock nobody's tracking against a real purchase order: tell us where, and we'll scope what fixing it would take.
BigCommerce's own count is only ever as accurate as the inventory moving inside BigCommerce itself. Anything happening in a second warehouse or a separate sales channel needs an actual sync feeding that number, not a person checking two systems and doing the math themselves. Inventory is just this page's example; n-frames automates whatever's currently being reconciled by hand anywhere in your business.
Let's talk →Not natively. BigCommerce tracks a single stock number per SKU or variant with no built-in concept of separate locations. Multi-location inventory requires a custom integration against whatever system actually tracks stock by warehouse or store.
You set a threshold per SKU or variant, and BigCommerce emails the store admin once stock falls to that level. It's a notification only; nothing's reordered or flagged anywhere else automatically when the alert fires.
Not on its own if those channels exist outside BigCommerce, a separate marketplace, a wholesale channel, a physical register. BigCommerce's native stock count only reflects activity happening inside BigCommerce itself; preventing overselling elsewhere requires a sync keeping every channel against the same real number.
No. BigCommerce has no native workflow for creating a purchase order, tracking what's on its way from a supplier, or logging when a shipment's received. Restocking is a manual stock-count update unless a connected inventory or ERP system is handling that workflow instead.