G2 Customer Reviews
What do you like best about Stok.ly – Inventory-Centric Cloud ERP?
“We have gone from a pen and paper warehouse to a completely digital system that has streamlined our business immensely. The customer support has been superb since the day we onboarded with Stok.ly and we continue to build a great relationship with the team.We use Stok.ly daily in our warehouse and have found a number of features to now be invaluable. The ease of integration is incredible and has streamlined tasks within our business ten fold.”
Shopify POS may not be the problem
Retailers often reach a point where something in the technology stack must change, then assume the point of sale has to be replaced as part of the same project.
That can confuse two different layers:
- The commerce layer: how store colleagues serve customers, take payment, issue receipts and process in-person transactions.
- The operational layer: how the business controls inventory, purchasing, warehouses, transfers, replenishment, fulfilment, returns, costs and reporting across every location and channel.
If store teams are comfortable with Shopify POS and the customer experience works, changing the till first may add disruption without solving the underlying control problem.
The more useful question is:
Is Shopify POS failing, or has the wider inventory operation outgrown the systems behind it?
Inventory Management Software Built for Retail, Wholesale and Manufacturing
What Shopify already does—and where Stok.ly adds depth
Shopify supports inventory across multiple locations. Its current inventory model distinguishes On hand, Available, Committed, Unavailable and Incoming quantities. Shopify POS can also display these states, and Shopify provides transfer-receipt workflows for qualifying POS configurations.
That means the argument for Stok.ly should not be that Shopify lacks inventory functionality. Stok.ly becomes relevant when a retailer needs an operational backbone that connects store and ecommerce demand to deeper control across warehouses, stock movement, buying, replenishment, fulfilment and finance-facing data.
| Operational requirement | Shopify and Shopify POS role | Stok.ly role |
|---|---|---|
| In-store selling | Checkout, payment, receipt and customer-facing store transaction | Receives and reflects the operational consequences of the sale through the integration |
| Ecommerce | Storefront, checkout and online customer experience | Brings Shopify orders into the wider order, inventory and fulfilment model |
| Product and variant identity | Presents products and variants to customers and store teams | Can act as the governed product-information hub, depending on the agreed configuration |
| Location inventory | Displays Shopify inventory by mapped location | Controls the wider operational stock record, states, movements and availability rules |
| Warehouse execution | Limited role in the target architecture | Goods-in, bins, barcode-led picking, packing, dispatch, returns and stocktakes |
| Transfers | Shopify provides native transfer capabilities | Controls transfer request, authorisation, pick, dispatch, in-transit state, receipt and variance handling across the wider operation |
| Replenishment | Native features and apps can support parts of the process | Rules, proposals, approvals and warehouse-to-store execution connected to demand and inventory |
| Purchasing | Shopify capabilities vary by setup and apps | Purchase orders, supplier receipts, landed costs, approvals and inbound visibility |
| Planning | Shopify reporting and apps may support planning | AI-supported forecasting, purchasing, stock balancing, transfers and replenishment |
| Accounting data | Shopify supplies commerce transactions | Connects wider operational documents and mappings to supported accounting platforms |
The exact boundary must be agreed during solution design. A coexistence architecture only works when each data object and workflow has a clearly defined owner.
The operating model: Shopify at the front, Stok.ly behind it
The target architecture is straightforward in principle:
- Shopify POS remains the store interface. Store colleagues continue using the familiar customer-facing selling flow.
- Shopify or Shopify Plus remains the ecommerce channel. Online orders continue through the existing storefront and checkout.
- Stok.ly becomes the operational control layer. Inventory, orders, locations, warehouses, transfers, replenishment, purchasing and fulfilment are controlled within one connected model.
- The integration keeps both layers aligned. Relevant products, locations, orders, inventory availability, fulfilment events, returns and other agreed updates move between the systems.
Stok.ly’s Shopify integration uses two-way, real-time communication. Its Shopify POS ERP model supports multi-location mapping, order and inventory updates, returns and exchanges, while the Stok.ly layer controls transfers, replenishment and WMS execution.
What “one stock truth” means in this architecture
One stock truth does not mean every screen has the same gross quantity. It means every system receives the correct operational answer for its purpose from one governed inventory model.
For example:
- Stock dispatched from a warehouse should no longer be available at the sending location.
- Stock in transit should not become available at the destination until receipt is confirmed.
- Damaged, quarantined, reserved or safety stock should not be published as freely sellable.
- Stock already committed to orders should not be offered again to another channel.
- Returns should not re-enter available inventory until the agreed inspection outcome permits it.
The quantity sent to Shopify should therefore follow an agreed available-to-sell rule, not simply mirror gross stock on hand.
The five controls that make coexistence work
Keeping Shopify POS is the easy part. Designing reliable ownership and synchronisation is the real work.
1. One owner for each data object
The implementation must state which platform is authoritative for:
- Products, variants, SKUs, barcodes and bundles.
- Store, warehouse and virtual locations.
- Inventory quantities and stock states.
- Prices and channel-specific product content.
- Customer and order records.
- Purchase orders and supplier data.
- Returns, exchanges and fulfilment status.
- Accounting documents and mappings.
If both platforms can independently overwrite the same data without a rule, the integration can create loops, unexplained changes and reconciliation work.
2. Exact location mapping
Every Shopify location used by Shopify POS or ecommerce needs an explicit relationship to the correct Stok.ly operational location.
Shopify itself tracks inventory separately by location and uses location configuration and order-routing rules to determine fulfilment.
The design must address:
- Stores that sell in person but do not fulfil online orders.
- Warehouses that fulfil ecommerce but do not sell in person.
- Locations holding quarantine, damaged or non-sellable stock.
- Temporary, pop-up, concession, 3PL or virtual locations.
- Location closures, additions and renaming.
- The difference between a physical bin and a Shopify-level location.
A location name is not enough. The mapping needs a stable system identifier and an accountable owner.
3. A controlled available-to-sell calculation
Retailers must agree what Shopify is allowed to sell from each location and channel.
A simplified starting rule is:
Available to sell = sellable on-hand stock − commitments − reservations − operational buffers
The final rule may also account for safety stock, damaged goods, quarantine, channel buffers, pre-orders, backorders, bundles, inbound supply or business-specific promises.
4. End-to-end event ownership
Each inventory-changing event needs one controlled path:
- POS sale.
- Ecommerce order.
- Order edit or cancellation.
- Goods receipt.
- Warehouse pick and dispatch.
- Store or warehouse transfer.
- Customer return or exchange.
- Stocktake or cycle-count adjustment.
- Bundle or component consumption.
- Manufacturing or kitting activity.
The integration should define what starts the event, which system records it first, what is sent to the other platform and what happens if synchronisation fails.
5. Exception monitoring and reconciliation
Real-time integration does not remove the need for control. It makes failures visible sooner—if someone is responsible for reviewing them.
The operating model should include:
- Failed or delayed update monitoring.
- Duplicate-event protection.
- SKU, barcode and location mapping exceptions.
- Inventory difference reports.
- Transfer and return variances.
- A retry and escalation process.
- Named owners across ecommerce, stores, warehouse, finance and IT.
What usually breaks as Shopify retailers scale
Gross stock is mistaken for sellable stock
The business knows how many units exist, but not how many are committed, quarantined, in transfer, reserved or safe to promise.
Transfers become quantity adjustments
One team subtracts stock from a warehouse and another adds it to a store. There is no controlled request, pick, dispatch, in-transit record, receipt confirmation or variance investigation.
Store replenishment lives in spreadsheets
Store teams request stock locally, the warehouse works from separate lists and buyers cannot see whether the problem is purchasing, allocation or stock in the wrong location.
Warehouse activity updates inventory too late
Paper picks, manual packing and delayed adjustments allow the physical operation and the system record to drift apart.
Returns cross channels without one rule
A customer buys online, returns in store and exchanges for another item. Without a defined cross-system workflow, order status, refund state and inventory availability can disagree.
Finance receives the result, not the explanation
Inventory valuation or accounting data may show a mismatch, but the operational history needed to explain the receipt, transfer, return, landed cost or adjustment sits elsewhere.
Common approaches that fail
Delaying every operational improvement because POS feels sensitive
This avoids immediate store disruption but leaves the inventory, warehouse and movement problem in place. As locations and order volume increase, the workaround burden normally grows.
Adding one app for every exception
An app may solve a narrow requirement. A collection of overlapping apps can also create multiple product masters, competing inventory updates and unclear support ownership. Evaluate the combined operating model, not the feature list of each app in isolation.
Letting both systems control inventory independently
Two writable inventory masters create ambiguity. Teams stop knowing which number is authoritative and manual corrections can be overwritten by the next synchronisation event.
Changing the entire retail stack at once
A full replacement may be justified when POS itself is the problem. If it is not, broadening the project can add training, payments, hardware and store-rollout risk without improving the operational outcome.
A lower-disruption implementation sequence
“Keep Shopify POS” should not mean “plug in an app and hope.” A controlled programme normally follows these stages.
1. Diagnose the real constraint
Map the current order, inventory and stock-movement lifecycle. Identify where teams stop trusting the system and start checking shelves, exporting data or building spreadsheets.
2. Define system ownership
Agree the master for products, variants, locations, inventory, orders, fulfilment, returns, purchasing and finance-facing documents.
3. Clean and map the data
Resolve duplicate SKUs, inconsistent barcodes, inactive products, bundle definitions, location mappings and units of measure before synchronisation begins.
4. Reconcile opening inventory
Establish the physical and system baseline at the same SKU-location-state level. Moving bad data into a stronger platform does not create stock trust.
5. Prove complete workflows in a pilot
Use representative stores, products and exception cases. Test normal and failure paths—not just a straightforward sale.
6. Roll out with monitored ownership
Train teams on the new operational workflows, monitor synchronisation and reconcile early differences before expanding to every location.
7. Improve planning after execution is reliable
Forecasting and automated replenishment depend on accurate demand, inventory and lead-time data. Stabilise the operational events that create those inputs before relying on automation.
What to test in a Stok.ly and Shopify POS discovery session
Do not evaluate the architecture from slides alone. Use your products, locations and exception cases.
| Workflow | What to prove |
| POS sale | The correct Shopify POS location and Stok.ly location update once, with the correct order and stock state. |
| Ecommerce order | The order enters Stok.ly, stock is committed correctly and fulfilment updates return to Shopify. |
| Order edit or cancellation | Released and newly required quantities update without duplicate adjustments. |
| Warehouse receipt | Received, short, excess, damaged and quarantined quantities remain distinguishable. |
| Store transfer | Request, approval, pick, dispatch, in-transit state, part receipt and variance are traceable. |
| Return and exchange | Order, refund, inspection and inventory availability remain aligned across both systems. |
| Bundle or kit | Component availability and consumption produce the correct sellable quantity. |
| Stocktake | Count differences update the operational master and publish the correct result to Shopify. |
| Synchronisation failure | The exception is visible, retryable and assigned to an owner without creating duplicate inventory movements. |
| New store | Location creation, product activation, opening stock and Shopify POS device configuration follow a repeatable process. |
How Stok.ly supports the operational layer
Stok.ly is an order management-led, inventory-centric ERP platform for growing retail, wholesale and distribution businesses.
For a Shopify and Shopify POS operating model, Stok.ly can provide:
- Multi-location inventory mapped across stores and warehouses.
- Real-time order and inventory synchronisation with Shopify.
- Operational stock states and availability control.
- Barcode-led goods-in, bin movements, picking, packing and dispatch.
- Controlled warehouse-to-store, store-to-warehouse and inter-store transfers.
- Replenishment proposals, rules, approvals and execution.
- Purchase orders, supplier receipts, landed costs and inbound visibility.
- Returns and exchanges aligned across POS and online activity.
- Product, variant, bundle and channel-data management.
- AI-supported forecasting, purchasing, transfers and stock balancing.
- Courier, freight and accounting integrations.
- Custom operational reports, permissions and audit trails.
The objective is not to turn Shopify POS into an ERP. It is to let Shopify POS keep doing the customer-facing job while Stok.ly controls the operational workflows that determine whether stock can be trusted and orders can be fulfilled.
Customer evidence
One verified Stok.ly customer described moving from a pen-and-paper warehouse to a digital system and said the integration had streamlined the business substantially. (Read the five-star G2 review)
A Capterra reviewer specifically reported that after adopting Stok.ly, the team worked from one system, inventory was accurate and “our Shopify is always up to date.” (Read Stok.ly reviews on Capterra)
These are individual customer experiences, not guaranteed outcomes. Results depend on data quality, configuration, integration scope, adoption and operational discipline.
When this architecture is a strong fit
It is worth evaluating when:
- Shopify POS works for store colleagues and customers.
- The business operates multiple stores, warehouses or stock-holding locations.
- Shopify ecommerce and physical retail share products or inventory.
- Transfers, replenishment or store ordering rely on spreadsheets and manual decisions.
- Warehouse execution needs barcode-led goods-in, bins, picks, packing and dispatch.
- Wholesale, B2B, marketplaces or other channels add competing demand.
- Purchasing needs to reflect stock states, commitments, inbound supply and real demand.
- Finance and management cannot explain stock differences from the current audit trail.
- The business wants to improve the operational backbone without making POS replacement the first dependency.
When it may not be the right fit
It may be unnecessary or poorly matched when:
- The operation is a simple single-store business with limited stock movement.
- Shopify’s native inventory and selected apps already control the required workflows reliably.
- The main problem is the Shopify POS interface, payments, hardware or store experience itself.
- The business does not need warehouse, transfer, replenishment, purchasing or deeper ERP control.
- The team is unwilling to define data ownership and adopt governed operational processes.
Stok.ly also offers its own retail POS system for retailers that do want to review or replace the front end.
Frequently asked questions
Can I keep Shopify POS and use Stok.ly for ERP and inventory management?
Yes. Stok.ly supports retailers selling in store with Shopify POS and online through Shopify or Shopify Plus. Shopify remains the selling layer while Stok.ly controls the wider inventory, warehouse, transfer, replenishment, purchasing and fulfilment operation.
Does Shopify POS already manage inventory?
Yes. Shopify tracks inventory by location and supports On hand, Available, Committed, Unavailable and Incoming states. Stok.ly is considered when the retailer requires deeper operational control across ERP, WMS, purchasing, transfers, replenishment, multiple channels or more complex business models.
Which system should be the inventory source of truth?
In the architecture described on this page, Stok.ly is the operational inventory master and Shopify receives the agreed available-to-sell position. The exact ownership model must be confirmed during implementation; two uncontrolled inventory masters should be avoided.
How do Shopify locations map to Stok.ly?
Each relevant Shopify store or warehouse location is mapped to the corresponding Stok.ly operational location. The design must also define which locations can sell, fulfil online orders, hold non-sellable stock or participate in transfers.
What happens when an item sells through Shopify POS?
The POS transaction updates the mapped Shopify location and is synchronised with Stok.ly. Stok.ly reflects the sale within the wider inventory and order model, then keeps agreed inventory availability aligned across connected channels and locations.
Can Stok.ly manage warehouse-to-store transfers?
Yes. Stok.ly controls the transfer lifecycle from request and approval through warehouse picking, dispatch, in-transit stock, receipt confirmation and variance capture.
Can Stok.ly manage Shopify ecommerce orders as well as POS activity?
Yes. Shopify ecommerce orders can enter the Stok.ly order dashboard for allocation, picking, packing, courier processing and dispatch, with agreed fulfilment updates synchronised back to Shopify.
Can Stok.ly support returns and exchanges?
Yes. The Stok.ly Shopify POS model supports returns and exchanges. The exact workflow should be demonstrated for online purchases returned in store, store purchases returned elsewhere, exchanges, quarantined returns and refund timing.
Is this a plug-and-play project?
The Stok.ly Shopify app provides a streamlined connection without custom development for the standard integration. A successful multi-location rollout still requires data preparation, location and SKU mapping, ownership decisions, workflow configuration, testing and user adoption.
Will keeping Shopify POS reduce implementation risk?
It can remove POS replacement, store hardware, payments and front-end retraining from the first phase. It does not remove integration or operational-change risk, which still needs controlled implementation and testing.
Does Stok.ly replace Shopify?
No. In this model, Shopify and Shopify POS remain customer-facing commerce systems. Stok.ly provides the operational control platform behind them.
Keep the store experience. Strengthen the operation.
If Shopify POS works at the front but stock trust breaks across stores, warehouses, transfers, replenishment and fulfilment, the answer may not be a till replacement.
It may be a clearer system boundary:
- Shopify POS for the store transaction.
- Shopify or Shopify Plus for ecommerce.
- Stok.ly for order management-led, inventory-centric ERP control.
Contact Information
All our sales, support and development team are located in Hereford and Cheltenham in the U.K. Please submit the contact form and we will contact you within the same business day.