n-BigCommerce Tracks Stock per SKU Accurately. Per Location, It Has No Opinion.
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.
How native BigCommerce inventory tracking actually works
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.
Where one number per SKU stops matching reality
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.
What we build on top of BigCommerce inventory
One real stock number across every warehouse and channel
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.
A low-stock alert that starts a reorder, not just an email
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.
Where does your BigCommerce stock count actually stop being accurate?
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.
Reconciling BigCommerce stock against another location by hand?
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