Stocky’s full shutdown lands August 31 — only a few weeks away now.
I’ve been following many of the discussions here about what merchants are moving to next, and most of the conversation still focuses on purchase orders and reorder points.
From the retailers we’ve spoken with, the harder challenges usually begin after the PO exists:
• Receiving inventory
• Partial shipments
• Inventory discrepancies
• Bin locations
• Put-away workflows
• Cycle counts
• Inventory transfers between locations
• Connecting inventory activity back to finance
Over the past several weeks we’ve focused on those workflows inside NexuSphere — receiving with partial-shipment tracking, put-away with bin suggestions, cycle counts with variance review to catch discrepancies, and automated GL posting. The goal is to help retailers spend less time reconciling inventory activity across multiple systems and spreadsheets.
Inventory transfers between locations is the area we’re actively refining now.
We’re opening extended pilot access to a small group of retailers who want to help shape the final workflow design. If you’re actively managing inventory, purchasing, receiving, or warehouse operations, we’d love your feedback on what’s working and what’s still missing.
No pitch. No obligation.
Just looking to learn from operators dealing with these challenges every day.
Curious what has been the hardest operational challenge as your business has grown:
For us, the hardest part is keeping transfers and receiving accurate when staff are busy. A transfer marked complete too early creates phantom stock at both locations, and partial supplier shipments make it worse.
What has worked:
Keep transfers in transit until the receiving location scans and accepts each item. Do not add stock based on the ship date.
Receive against the PO line by line, with separate quantities for ordered, received, damaged, and backordered.
Require a reason code for every variance, then review variances over a set threshold daily.
Cycle count fast-moving bins weekly and the rest on a rotating schedule. Freeze that bin during the count so sales and transfers do not move the target.
The missing piece in many systems is a clean audit trail tying each stock adjustment to a person, document, location, and financial entry.
The transfer scenario you described is one we’ve been discussing internally as well. We’re leaning toward treating transfers similarly to receiving, where inventory moves into an in-transit state and isn’t considered available at the destination until it’s actually received.
I also agree on the audit trail point. As we’ve been building receiving, put-away, cycle counts, and pick/pack workflows, one of the goals has been making sure every inventory movement can be traced back to the originating document, user action, location, and corresponding financial impact.
Curious whether you’ve found any systems that handle both the operational workflow and the financial reconciliation side well, or if you’ve mostly seen those split across separate platforms.
Thankfully, that system already exists. I mean, others may be trying to build tools to address a perception of need, but that will be an uphill battle. Saying things like “many systems” may be true, but there are also systems (affordable too) that do this audit trail (and everything else in this thread) well already. Is there really space for yet another one?
There are definitely good inventory and warehouse systems already in the market, and many merchants will be well served by them.
What we’ve been hearing from retailers is that they often end up stitching together purchasing, receiving, inventory movements, warehouse workflows, and finance across multiple tools.
We’re exploring whether there’s value in bringing those operational workflows together in a more unified way.
The market will ultimately decide whether that’s useful, but the conversations have been interesting so far.
hat’s an interesting perspective because you’ve lived with Stocky longer than most.
In the conversations we’ve had so far, the answers have been surprisingly split.
Some merchants focus on forecasting and reorder decisions.
Others tell us the bigger pain starts after the PO is created—receiving, partial shipments, inventory accuracy, transfers, cycle counts, and warehouse organization.
It would be interesting to see whether merchants who operate multiple locations answer differently than single-location stores.
The systems I trust are not necessarily the ones with the most finance screens. They give the physical movement and the accounting entry the same transaction identity.
A partial receipt, damaged quantity or transfer should show the source document, user, location, quantity, cost basis, posting state and any reversal. If operations can edit an event after finance has posted it without creating a visible adjustment, reconciliation will still move back to a spreadsheet.
I’d test one ugly path end to end: partial receipt, variance, landed-cost allocation, posting, period lock, then correction. The exception queue and reversal trail will tell you whether the two sides are genuinely connected.
Icey.Lane’s four-item list is the real test, so here’s a concrete answer to it instead of another pitch around it.
Partial receipt: per-line running counts, each delivery its own dated receipt row. Variance: the received-vs-ordered gap stays visible per line until it closes - short or damaged quantities simply don’t get received, and the line shows it. Landed cost: freight, duty and discounts allocated across lines at receiving and written into Shopify’s cost field. Posting: in a Shopify-only stack, that cost write-back is the posting. There’s no general ledger behind it, and tools that imply otherwise are overselling. If you run real accounting, what matters is that the export carries receipt-level rows, not PO totals.
Two items from the operational list we don’t cover: bin locations and put-away. If those are core to your floor, you want a WMS-shaped tool, not a PO-shaped one. Different animal, usually a different price class, and pretending one tool is both is how demos disappoint.
The thread’s framing is right though. The PO was never the hard part. Receiving is where inventory, cost and accounting meet, and most tools only hold one of the three.
The transaction identity point is interesting because that’s very similar to how we’ve been thinking about it.
One of the design goals has been making sure inventory events don’t become disconnected from their financial impact over time. A receipt, variance, adjustment, transfer, or reversal should remain traceable back to the originating document, user action, and posting history.
I also agree that the “ugly path” is usually the real test. Happy-path demos are easy. Partial receipts, damaged inventory, variances, corrections after posting, and period-close scenarios are where the architecture either holds up or falls apart.
Out of curiosity, have you seen many systems handle that full lifecycle well, or do most still end up pushing reconciliation back into spreadsheets?
Hey, I built Replenly as a focused Stocky replacement for the reorder to PO to receiving workflow. Adding a concrete data point since the thread is asking for specifics rather than pitches.
On partial receiving: Replenly does per-line received quantities with PARTIAL/RECEIVED status tracking. If someone fat-fingers a receive, there’s an adjust flow that corrects under a locked transaction rather than silently editing the original event. The PO detail page also surfaces “received units not yet posted to Shopify” separately so you can see where the sync stands.
On the reorder side: open POs (SUBMITTED/PARTIAL) are netted from reorder calculations. DRAFTs are deliberately excluded. So the “don’t double-order” problem Icey.Lane mentioned is handled at the calculation layer, not left to the merchant to eyeball.
What we don’t have, being honest: landed cost allocation. No freight/duty/FX fields. If that’s core to your workflow, Binly or a heavier tool is the right call. We also don’t have bin locations or WMS-level put-away. Denyslg’s point about those being a different animal is right.
Where we sit: the Stocky reorder to supplier PO to partial receive to Shopify sync loop, with one-click Stocky CSV import, at $20/month. If your problem is the operational workflow without needing the accounting layer, that’s the gap we’re built for.
the bin location / put-away / GL-posting stuff is genuinely a different category than POs - that’s warehouse software territory, and most of the stocky-replacement apps (mine included, stockyard) don’t touch it. we do partial receiving against a PO with per-line quantities, nothing on bin suggestions or GL posting. if you’re single-location that gap usually doesn’t matter, multi-location with real warehouse ops is a harder swap and probably needs something built for that specifically, not a PO app stretched to cover it.
Yeah, there are lots of good solutions here. A lot of the Stocky replacements are really PO / reorder / receiving tools and a few folks here already called that honestly.
If your pain is mostly “what to buy and how to receive it into Shopify,” those fit. If the pain is the floor after that (where the unit lives, put-away, pick path, wrong shipments when someone’s new), you’re in WMS territory. Different job. Spreadsheets + ShipStation + a PO app is how that gap usually shows up.
I work on SKUSavvy which is a mobile WMS, 3D bin map, pick routing, directed put-away, forecasting, and two-way Shopify sync. Happy to answer ops questions either way to any merchant dealing with this upcoming change.
Hi there @kthoppae
From my experience, accuracy in receiving and inventory reconciliation are the first things to cause headaches when a store starts to take off. Part shipments, differences and transfers can create gaps between what the system tells you about and what you really have on hand.
Having a good receiving and cycle count process does help, but uniformity from store to store is really what makes the difference. The closure of Stocky makes this an ideal moment to document those flows and see where Shopify’s native inventory management tools can fill the voids.
One operational gap I’d add is what happens when the supplier invoice doesn’t exactly match the PO or what was actually received.
In practice, quantity and cost discrepancies are pretty common. Someone still has to compare the invoice lines, identify the differences, update the correct Shopify variants, and ideally keep a record of what changed.
That’s often where the spreadsheet/manual work starts even if the receiving workflow itself is good.
We’ve been looking specifically at that supplier-invoice → Shopify step rather than trying to build another full WMS. Curious whether you see invoice reconciliation as part of receiving in NexuSphere, or something that happens later on the finance side?
You’re highlighting the exact operational reality most merchants miss during the Stocky transition. Moving purchase order creation to basic tools is simple, but execution—receiving partials, bin allocation, and location transfers—is where multi-channel inventory control breaks down.
Location transfers and receiving discrepancies specifically introduce two major risks if state updates aren’t synchronized in real time:
Phantom Stock Visibility During In-Transit Transfers: When stock moves between physical store locations or warehouse bins, standard systems mark inventory as deducted at Location A before it physically lands at Location B. Without an “in-transit” state lock, online channels either under-report total stock or expose phantom inventory.
Un-reconciled Receiving & Financial Drift: Partial shipments and receiving variances that aren’t tied atomically to inventory unit costs create continuous discrepancies between ledger counts and GL reporting, forcing manual end-of-month reconciliations.
To keep post-PO warehouse workflows synchronized without ledger lag:
Atomic In-Transit Location Locking: Hold moving inventory in a dedicated “In-Transit” virtual location that maintains channel availability rules until the receiving location confirms scan verification.
Event-Driven GL & Unit Cost Sync: Mutate inventory counts and cost basis via single-transaction database operations immediately upon receiving approval, ensuring unit costs update synchronously across accounting and fulfillment channels.
We engineered an autonomous inventory state engine that manages real-time multi-location state locks and automated receiving reconciliation. Happy to share technical details or offer a free 30-day inventory audit if you’d like to benchmark your transfer and receiving pipeline!
Just following up in case you’re currently reviewing solutions for your post-Stocky workflow!
If you’d like to get rid of manual end-of-month reconciliations and want us to set up automated in-transit locking for your store, we are currently onboarding merchants through our $99 Managed Migration & Audit.
If you run more than one Shopify location (stores + warehouse) and you’re looking for a cleaner way to move inventory — without spreadsheets or endless admin clicks — I wanted to share what we’ve built.
Stock Transfer Pro helps multi-location merchants:
Transfer stock between locations (draft → sent → received, including partial receipts)
Create smart transfer drafts from sales history or stock targets
Raise purchase orders, email PDF POs to suppliers, and track partials / backorders
Update weighted COGS on receipt (shipping + adjustments)
Run physical stocktakes that sync back to Shopify
Receive inventory on Shopify POS / mobile
Admin is available in English, French, German, Spanish, and Italian.
If something you need isn’t there yet, we can also customize features on request — just tell us your workflow and we’ll look at what we can build for you.
The phantom-stock example is particularly interesting — once a transfer or partial receipt is recorded differently from what physically happened, the inventory number can look valid while the underlying operational state is wrong.
Founder disclosure: I’m building VedaSuite for Shopify merchants around this detection/reconciliation layer — surfacing operational discrepancies, the evidence behind them and what needs attention in one Action Center.
The variance-threshold workflow you mentioned is especially relevant to how we’re thinking about prioritising operational issues.
