Unleashed Inventory: Multi-Location Stock, BOM and POs

What does an unleashed inventory setup actually track for a product brand?

An unleashed inventory setup is built to answer one question a spreadsheet cannot: what do you actually own, right now, across every location that holds stock. For a product brand running $3M to $30M in revenue on Shopify Plus or a paid subscription platform, that means raw materials, work-in-progress, finished goods, and the bill of materials that turns one into the other, all reconciled against purchase orders still in transit. It is not a bigger version of Shopify’s native inventory field. Shopify tracks one number per SKU per location; a platform in this category tracks the components that make that number true, the orders that will change it next week, and the assemblies that convert several line items into one sellable unit.

If your stock lives in one warehouse, you sell finished goods only, and you reorder by walking the shelf, this category of tool is solving a problem you do not have yet. The rest of this article assumes you have outgrown that: two or more stock-holding locations, at least one product that gets assembled or kitted before it ships, and a purchasing cycle long enough that “what’s on order” matters as much as “what’s on hand.” Confirm the specific modules, plan tiers and named integrations Unleashed offers directly with the vendor; what follows describes how this class of system behaves, not a feature list for any one product.

How does multi-location stock stay accurate across two warehouses and a 3PL?

Multi-location stock accuracy depends on every physical movement being logged against a specific location, not a company-wide total. A unit that leaves your owned warehouse for a 3PL is not simply “still in stock.” It needs to pass through a transfer record: decremented from the origin location the moment it ships, held in an in-transit state, then incremented at the destination once someone there confirms receipt. Skip the in-transit state and you get a gap where the unit exists on paper in two places or in neither.

The 3PL boundary matters most, because it sits between systems you control and systems you do not. Your own warehouse team can be trained to scan a transfer out. A 3PL’s receiving team is on someone else’s payroll, working to someone else’s SLA, and the accuracy of their scan is the accuracy of your inventory data whether you like it or not. A brand with one owned location and one 3PL should treat the 3PL’s confirmed-receipt feed as the single source of truth for that location, not a number your own team adjusts by hand after a phone call.

The failure mode that catches people out is the reconciliation cadence. If the platform pulls a 3PL’s counts once a day, a stockout at that location can go unnoticed for most of a working day, which is long enough for a popular SKU to sell through on the storefront while showing available. Ask what interval a 3PL integration actually polls on, whether it is push or pull, and what happens to an order placed inside that gap, before you assume “integrated” means “instant.”

What is a bill of materials, and why does it break a single-SKU stock field?

A bill of materials, usually shortened to BOM, is a recipe: it lists the components and quantities that go into one unit of a finished good, and it is what lets an inventory system decrement raw materials automatically when an assembly is built rather than requiring someone to adjust three stock lines by hand every time. A candle brand’s finished 8oz jar might consume one jar, one lid, 180g of wax, one wick and one label — a five-line BOM behind a single SKU.

Shopify’s stock field has no concept of this relationship. It holds one available count per SKU, full stop. If you sell the finished candle on Shopify and manage the wax, wicks and jars in a separate system or spreadsheet, nothing tells you that selling 40 candles this week should also pull 7.2kg of wax out of the raw-materials count. The two ledgers drift apart quietly, and the first time anyone notices is when production runs out of wick mid-batch with no warning.

A BOM-aware platform closes that gap by treating the assembly as an event: build ten units, and the system consumes the components for those ten units and adds ten finished units to available stock in the same transaction. Partial builds add another wrinkle. A batch that is only partway through production at the end of a shift needs to sit in a work-in-progress state with its own partial component consumption, not be recorded as either “not started” or “finished,” or the raw-materials count will be wrong in one direction and the finished-goods count wrong in the other.

Where this gets genuinely hard is variant-level BOMs: the same base product in three scent variants each consuming a different fragrance oil at a different rate. Confirm with the vendor whether variant-specific BOMs are a native feature or something you have to model as separate parent SKUs, because the workaround changes how your reporting reads.

How do purchase orders reconcile with what lands on the goods-in shelf?

A purchase order reconciles with received stock in three stages: ordered, expected, and received, each a distinct state rather than a single “incoming” bucket. Ordered is what you committed to a supplier. Expected is that quantity against a promised date, which is what a buyer should be watching for lead-time slippage. Received is what a warehouse team actually counted and signed for, which is very often not the same number as what was ordered.

The gap between ordered and received is where most purchasing pain lives. A supplier ships 480 units against an order for 500, and unless someone flags the shortfall at goods-in, the system either silently accepts 480 as complete or leaves the PO open forever waiting for 20 units that are never coming. Neither is right. The correct behaviour is a partial-receipt state: the PO stays open for the outstanding 20, the 480 land in available stock immediately, and the buyer gets a flag to chase the supplier or write off the shortfall as a formal adjustment.

Landed cost is the other place this gets missed. The unit cost on a purchase order is rarely the true cost of the stock once freight, duty and any inspection fee are added. A platform that lets you allocate those costs back across the received units gives you a margin number you can trust; one that only tracks the PO’s line-item price will overstate margin on anything shipped internationally, sometimes by a wide enough margin to change a pricing decision.

Set a reorder point per SKU, not a single company-wide rule of thumb, and review it against actual lead time rather than the lead time a supplier quoted a year ago. Lead times drift, especially on anything manufactured overseas, and a reorder point calculated on stale data will either trigger too late or tie up cash sitting in stock that arrived early.

What is the integration surface between the platform and the storefront?

The integration surface is the set of events that pass between the inventory platform and the storefront: an order placed, a stock count updated, a return processed, a manual adjustment made. Get the direction of each one wrong and you get either a storefront that oversells or an inventory system that never learns what actually sold.

The core loop looks like this: an order fires on the storefront, a webhook (or a polled check, depending on the integration) tells the inventory platform to decrement available stock, and the platform pushes a recalculated available count back to the storefront for every channel selling that SKU. That handoff plays out as a single round trip; in practice it runs continuously, order after order, all day.

Three things sit on that surface and each needs its own answer. First, what happens on a cancelled or edited order: the platform needs to see the reversal, not just the original decrement, or cancelled stock never comes back as available. Second, what happens on a manual count adjustment made inside the inventory platform, such as a cycle count correcting a shrinkage discrepancy: that should flow to the storefront on the same interval as a sale, not sit until the next scheduled sync. Third, what happens across multiple sales channels selling the same SKU: the platform, not any one channel, needs to hold the master count, or two channels can each believe they have the last unit at the same moment.

Why does the obvious approach fail past a certain volume?

The obvious approach — a spreadsheet for raw materials, Shopify’s own field for finished goods, and someone updating both by hand — fails not because spreadsheets are bad tools, but because the two ledgers have no mechanism forcing them to agree. Nothing stops the spreadsheet count and the Shopify count from drifting apart other than a person remembering to update both every time something moves, and people forget, especially at the end of a long shift or during a promotion.

At low volume this is survivable because the gap between “the numbers disagree” and “someone notices” stays small: a handful of orders a day, one warehouse, one person doing the updating. It stops being survivable at three inflection points. The first is a second stock-holding location, which doubles the number of manual updates and the number of places drift can start. The second is any assembled product, because now a single sale should trigger multiple component decrements and a spreadsheet has no way to enforce that automatically. The third is order volume itself: past a certain number of daily orders, whatever that threshold looks like for your team’s capacity, the person doing manual updates cannot keep pace, and the backlog of unentered adjustments becomes the actual state of your inventory, invisible to everyone else.

The tell that you have crossed this line is not a single dramatic stockout. It is a slow accumulation of small disagreements: a SKU that shows eight available on the storefront but six on the shelf, discovered only during a cycle count. By the time that discrepancy is visible, it has usually been compounding for weeks.

What should replace manual reconciliation instead?

What should replace manual reconciliation is a single system of record that both the warehouse team and the storefront read from and write to, so there is exactly one place a count can be wrong rather than two places that can disagree with each other. That is the actual value proposition of a platform in this category: not more features, but fewer ledgers.

Getting there is a migration, not a flip of a switch. Start with a clean opening stock count taken physically, location by location, because any platform is only as accurate as the numbers it is seeded with. Build the bill of materials for every assembled product before you go live, not after, since retrofitting a BOM onto stock that has already been selling without one means reconciling a backlog you cannot fully reconstruct. Configure the reorder points using actual historical lead time, not a supplier’s quoted figure. Then run the new system in parallel with the old process for a defined window, comparing counts daily, before you cut the spreadsheet off entirely.

The step teams most often skip is training the warehouse floor on the discipline the new system requires: every movement scanned, every adjustment logged with a reason code, no more “I’ll update it later.” A platform this precise is only as accurate as the least disciplined person touching stock that day, and one warehouse worker who “just moves it and updates it tomorrow” reintroduces exactly the drift the system was bought to remove.

What breaks at volume: oversells, phantom stock and negative counts

Oversells, phantom stock and negative counts are the three failure modes that show up once order volume rises, and each has a distinct cause worth knowing separately rather than treating “inventory is wrong” as one undifferentiated problem.

An oversell happens inside the sync gap: two orders for the last unit land within the same interval between stock updates, and both get confirmed before either decrement registers. A wider safety buffer on high-velocity SKUs and a shorter sync interval both narrow this window; a launch day or a flash sale is exactly when the gap matters most, because order velocity spikes right when the sync interval matters most.

Phantom stock is the opposite problem: the system shows available units that do not physically exist, usually because a return was logged as received before it was actually inspected, or because a manual count adjustment was applied to the wrong location. Phantom stock is more dangerous than an oversell because it does not trigger an error; it just quietly promises a customer something you cannot ship, and you find out at the pick-and-pack stage, not at checkout.

A negative count means the ledger allowed a decrement past zero, which some systems permit as a configuration choice to avoid blocking a sale outright and reconcile later. Whether that is the right default depends on your tolerance for backorders versus your tolerance for a customer service ticket from an order you cannot fulfil; treat it as a setting to decide deliberately, not one to discover after the fact.

What does this cost to run, beyond the monthly subscription line?

The subscription line is the smallest part of what this costs to run. The larger costs are integration setup, the ongoing labour of maintaining accurate BOMs as products change, and the internal training cost of getting a warehouse team to work with the discipline the system assumes.

Integration setup is a one-time cost but rarely a small one: connecting the platform to your storefront, any additional sales channels, and a 3PL if you use one, then testing each sync path under real order volume before trusting it. This is engineering and operations time, not a line item on a vendor’s price sheet, and it varies enough by the number of channels and the state of your existing data that no single figure describes it — budget it as a project, not an afternoon.

The recurring cost that catches people out is BOM maintenance. Every time a supplier substitutes a component, a recipe changes, or a new variant launches, the bill of materials needs updating or the system starts consuming the wrong raw materials against the wrong finished goods. Assign this to someone by name; “the team will keep it updated” without an owner is how BOMs quietly go stale.

Training is the cost most often left off the budget entirely. A platform this precise depends on consistent scanning and logging from everyone who touches physical stock, and that discipline does not arrive automatically with the software. Plan for a deliberate rollout period with real supervision, not a one-off demo and an assumption that the new habits will stick.

Who should not adopt a dedicated inventory platform yet?

A brand should not adopt a dedicated inventory platform yet if it sells finished goods only, from a single location, at an order volume a couple of people can reconcile by eye without last week’s numbers already being stale. Below the $3M revenue floor this article assumes, the operational overhead of configuring and maintaining a platform like this usually costs more in time than the drift it prevents; a disciplined spreadsheet and a weekly cycle count are the right tool at that stage, not a limitation to apologise for.

A platform this precise is also the wrong fit for a brand mid-way through a major SKU rationalisation or a supplier switch, where the bill of materials for half the catalogue is about to change anyway. Migrating onto a precise system while the underlying data is in flux means rebuilding the same BOMs twice. Finish the rationalisation first, then migrate onto a clean structure once.

Getting the fundamentals — one warehouse, clean SKUs, a stable supplier base — right first is not a permanent no, just a sequencing question, because a platform this exact will faithfully enforce whatever structure you give it, disorganised or not.

Reconciling stock across locations, assemblies and purchase orders by hand is an ops automation problem before it is a software-selection one, and it is the kind of process work Pointerflow’s ops automation practice is built to untangle.