Same stores, different ERP, and the answer changes. Multi-store POS integration for NetSuite looks nothing like it does for Business Central or SAP Business One, because each ERP reaches your registers a different way. NetSuite’s own POS is retiring. Dynamics splits into two very different paths. SAP Business One relies on a separate POS. Pick the path that matches your ERP, not the loudest demo.
This guide shows how each ERP represents stores, what POS options it realistically has today, and when its vendor’s own connector is enough. It is written for NetSuite admins, Dynamics customers and partners, and SAP Business One IT leads at retailers and distributors with stores. You can read it on its own. If you want the wider overview of connecting stores, registers, and a website to one ERP, our multi-store ERP integration guide covers it.
Find your ERP: NetSuite, Business Central (BC cloud and on-prem), F&O, or SAP B1.
What are the four ways stores connect to an ERP?
Every multi-store setup answers one question: which system owns the truth about stock, price, customer, and the sale in each store? Four common setups answer it differently. The ERP runs the stores, Shopify runs the stores, a separate POS sits in the middle, or an orchestration layer decides. The rest of this guide uses these four names.
| Setup | Who owns store truth | Typical stacks | Where it breaks if designed badly |
|---|---|---|---|
| The ERP runs the stores | The ERP’s own retail or POS layer | Dynamics 365 F&O with Dynamics 365 Commerce (Store Commerce, Commerce Scale Unit); Business Central with LS Central; NetSuite with its own POS (retiring January 2029) | The website connects to the ERP’s data, not its retail engine, so web and store calculate prices and stock differently |
| Shopify runs the stores | Shopify (online store, Shopify POS, and locations); the ERP is the finance and supply-chain back office | Shopify Plus and Shopify POS with NetSuite, Business Central, F&O, or SAP Business One | ERP pricing and trade terms don’t reach the register; every POS sale posts as a full order and floods the ERP; transfers and receiving live in two places |
| A separate POS sits in the middle | A standalone POS product | Adobe Commerce (Magento) or BigCommerce, which have no built-in POS, with any ERP; also NetSuite businesses replacing their POS | Three systems, three stock numbers, and nobody decided which one is master |
| An orchestration layer decides | A separate order management system routes fulfillment | Larger multi-region operations | Adds a fourth system; overkill below a certain scale |
There is no single best setup. The right one is the one where each of stock, price, customer, and the sale has a clear owner. For the full comparison, see our guide to multi-store integration architecture.
How does each ERP represent stores, and what POS options does it have?
NetSuite models stores as locations (with subsidiaries above them), Business Central as locations, F&O as retail channels, and SAP Business One as warehouses. The POS options differ more: NetSuite’s own POS is retiring, Business Central has two paths, F&O uses Dynamics 365 Commerce, and SAP Business One uses SAP Customer Checkout or a partner POS.
Here is the comparison, as of October 2026.
| ERP | How stores are modelled | POS options today | Usual setup | How the website connects | What to watch |
|---|---|---|---|---|---|
| NetSuite | Locations, mapped to each POS location; subsidiaries where used | NetSuite’s own POS (SCIS, NSPOS) retiring 31 January 2029; Shopify POS; third-party or partner POS | The ERP runs the stores today; moving to Shopify runs the stores or a separate POS sits in the middle | NetSuite’s own Shopify connector, or an integration | Choosing the replacement POS before the 2029 deadline |
| Business Central | Locations | LS Central; Shopify POS through Microsoft’s connector; third-party POS | The ERP runs the stores (LS Central) or Shopify runs the stores (Shopify POS) | Microsoft’s Shopify connector, or an integration | Microsoft’s connector is for Business Central online only |
| F&O | Retail channels in Dynamics 365 Commerce | Store Commerce POS with Commerce Scale Unit | The ERP runs the stores | Commerce Scale Unit (see our CSU guides) | Web and store calculating prices differently |
| SAP Business One | Warehouses | SAP Customer Checkout; partner add-ons or third-party POS that post sales into SAP Business One | Shopify runs the stores or a separate POS sits in the middle | An integration, with the POS posting into SAP Business One | One owner of stock per store |
How does NetSuite handle multiple stores and POS?
NetSuite POS integration for multiple stores starts with locations: each store is a location, and one account can run different POS systems in different stores, each mapped to its own location. That mapping decides which subsidiary and location a sale lands in. The harder question today is which POS you will run, because NetSuite’s own is being retired.
How NetSuite models stores: locations and subsidiaries
Give every store one NetSuite location, then map each platform location ID and each register to it. Locations organize operations. Subsidiaries are the legal and accounting boundaries above them. With NetSuite OneWorld, one account can manage records and transactions for multiple legal entities (subsidiaries), which is what a NetSuite OneWorld multi-store setup relies on. Source: Oracle NetSuite documentation. Each store therefore needs to belong to the right subsidiary as well as the right location.
Do POS orders post to NetSuite as Cash Sales or Sales Orders?
POS sales entering NetSuite are typically created as either a Cash Sale or a Sales Order. Sales Orders suit sales that need a fulfillment step in NetSuite, such as buy online, pick up in store or ship from store. Cash Sales suit simple counter sales that complete on the spot. How much detail to post is a finance decision. Our guide to posting store sales to your ERP covers it, and you should settle it with your finance team before you build.
NetSuite POS end of life and SCIS replacement: what it means for your stores
NetSuite POS end of life arrives on 31 January 2029. NetSuite’s own POS products, SuiteCommerce InStore (SCIS) and NetSuite POS (NSPOS), reach end of support that day, after an end-of-life announcement in February 2026. They are no longer licensed to new customers and there is no native replacement. Replacing the POS is really an integration decision, because it changes who owns store stock, price, and posting.
Customers are pointed to third-party and partner POS products instead. Source: ERP Advisors Group.
NetSuite POS alternatives: the three replacement paths
Leaving NetSuite’s POS moves you from “the ERP runs the stores” to “Shopify runs the stores” or “a separate POS sits in the middle.” A partner POS app built to work with NetSuite is a third route, and which of those two setups it lands in depends on which system it treats as master for stock. That is the part most teams underestimate.
| Path | What changes |
|---|---|
| Shopify POS (Shopify runs the stores) | Shopify owns store stock and the register price. NetSuite becomes the finance and supply-chain back office. ERP trade pricing and terms have to reach the register, and you decide whether every sale posts or a daily summary does. |
| A standalone third-party POS (a separate POS sits in the middle) | The ERP, the website, and the POS each hold a stock number. You must pick a master per location, and the POS has to exchange stock, price, sales, returns, and tenders. |
| A partner POS app built for NetSuite (setup depends on the product) | Oracle points customers to partner POS products, and there is no first-party replacement. Whether the app, NetSuite, or the website holds the stock number differs by product, so ask each vendor which system is master and how sales, returns, and tenders reach NetSuite. |
What happens to the website integration during a POS migration?
For each store, the owner of stock changes on the day it cuts over. If the integration still deducts sales from the old POS, you get double counting or none, and the website shows the wrong number. Test the website integration at every wave, not only at the end.
Avoid a Q4 POS cutover, and migrate in waves
A phased POS migration in waves beats a big-bang cutover. Start with one low-volume pilot store, fix what it teaches you, then move groups of stores. Avoid Q4 entirely: peak season is when a stock or posting mistake costs the most, and the new POS has had the least time to prove itself.
Illustrative example. A sports and fashion retailer with 120 stores on NetSuite plans to move to Shopify POS. It maps every store to a NetSuite location, pilots one store after the holiday peak, and moves the rest in waves, testing the website integration at each one.
What should NetSuite multi-store businesses do in the next 12 months?
Pick the target setup first, then the product, then pilot, then migrate in waves with no Q4 cutovers. If you are reading this in Q4, use it for the checklist below and schedule the pilot after peak.
A 90-day checklist:
- List every store, its POS, and the NetSuite location it maps to.
- Write down who owns stock, price, customer, and the sale in each store today. Usually more than one system thinks it does.
- Choose the target setup (Shopify runs the stores, or a separate POS sits in the middle) before choosing a product.
- Ask every POS vendor which system is master for stock, and how sales, returns, and tenders reach NetSuite.
- Agree the posting level with finance: every sale, or a daily summary per store.
- Draft the wave plan: pilot store, waves, and a no-cutover window for Q4.
What does NetSuite’s own Shopify connector cover for stores?
NetSuite’s own Shopify connector syncs product, pricing, inventory, sales orders, and fulfillment between NetSuite and Shopify or Shopify Plus storefronts, and it covers Shopify POS. Source: Shopify App Store listing. For a Shopify POS and NetSuite integration with one store and simple pricing, that may be all you need. Businesses that need more usually have stores on Adobe Commerce or BigCommerce, a non-Shopify POS in some stores, customer-specific prices at a branch counter, or no named owner after go-live. See our Shopify and NetSuite integration and Adobe Commerce and NetSuite integration pages.
Does Business Central have a POS, and how do Dynamics 365 stores work?
Business Central POS integration follows two common paths: LS Central, which adds POS and store operations inside Business Central, or Shopify POS through Microsoft’s Shopify connector. Business Central itself is the finance and supply-chain core. Finance & Operations is different. Its stores run on Dynamics 365 Commerce. The right path depends on which system you want to own the register.
| Business Central | Finance & Operations (F&O) | |
|---|---|---|
| Store model | Locations | Retail channels in Dynamics 365 Commerce |
| POS | LS Central, Shopify POS (via Microsoft’s connector), third-party POS | Store Commerce POS |
| Real-time retail services | Through LS Central or the connector | Commerce Scale Unit |
| Usual setup | The ERP runs the stores (LS Central) or Shopify runs the stores (Shopify POS) | The ERP runs the stores |
Business Central POS options: how does the Shopify connector handle multiple shops, locations, and Shopify POS?
Microsoft’s Shopify connector for Business Central supports more than one Shopify shop, each with its own products, the locations used to calculate inventory, and price lists. It can import orders from Shopify POS. Source: Microsoft Learn. That makes Business Central Shopify POS with multiple locations workable for consumer retail. The design work is deciding which Business Central locations feed each shop’s stock and which price list each shop uses. Third-party POS products also integrate with Business Central, and each one puts you in “a separate POS sits in the middle”, so ask every vendor which system is master for stock.
LS Central vs Shopify POS for Business Central: which one makes more sense?
LS Central (from LS Retail) extends Business Central with POS, store operations, loyalty, and retail inventory in one database, and its POS can keep selling offline and resync. Its Shopify BC Connector extends Microsoft’s standard integration and maps Shopify locations to LS Central stores for click-and-collect routing. It requires Business Central and the Shopify Connector at version 28 or later. Source: LS Central Help.
A rule of thumb. If the ERP should run the stores, with store operations, loyalty, and offline selling in one system, LS Central fits “the ERP runs the stores.” If Shopify runs the site and the stores and pricing is simple, Shopify POS fits “Shopify runs the stores.”
Business Central (BC cloud and on-prem): does the Shopify connector work with on-premises?
No. Microsoft’s FAQ says the connector is available only for Business Central online and isn’t available for on-premises deployments. It is preinstalled for new environments, and you need both a Business Central license and a Shopify license to use it. Source: Microsoft Learn FAQ. It also doesn’t work with other Dynamics 365 applications such as Supply Chain Management. If you are on Business Central on-premises, you need a different integration, and that applies to LS Central’s Shopify connector too, since it builds on Microsoft’s. i95Dev supports Business Central on-premises as well as online.
How do stores work in Dynamics 365 F&O?
On Dynamics 365 F&O, stores run on Dynamics 365 Commerce, which is Microsoft’s retail layer on F&O. Each store sits in a retail channel, the POS is Store Commerce, and Commerce Scale Unit exposes real-time retail services. Dynamics 365 Commerce is not a standalone storefront that pairs with NetSuite or SAP.
Here the misconception “Our ERP has a POS, so we don’t need integration” bites hardest. Your website still has to use the same stock, prices, and customers as the registers, and that connection is the integration. If it reads the ERP’s tables instead of the retail engine, web and store calculate prices differently.
Illustrative example. A perfume manufacturer runs F&O, its own stores, and a Magento site. The stores run on Dynamics 365 Commerce. Magento reads store stock and prices from the same retail engine, through Commerce Scale Unit.
For depth, read our Commerce Scale Unit guide, OData vs Commerce Scale Unit, and the 7 retail scenarios. For the base integration, see Adobe Commerce and Dynamics 365 F&O.
What changes for a GP or navision company with stores moving to Business Central?
Dynamics GP product support, enhancements, and regulatory updates end on 31 December 2029, and security patches continue until 30 April 2031. Source: Microsoft Learn. For a company with stores, moving to Business Central is also a decision about who owns store stock, price, and posting. List every feed between your stores, website, and the old ERP first, then decide which Business Central path (LS Central, Shopify POS, or a third-party POS) replaces them. Avoid changing the ERP and the POS in the same cutover window. The same stores-first approach applies to navision to Business Central stores.
Does SAP Business One have a POS, and how do stores share its warehouses and price lists?
SAP Business One POS integration starts from its warehouses: it supports multiple warehouses and transfers between them, so each store can be its own warehouse. Its POS options are separate from the ERP: SAP Customer Checkout, SAP’s own POS application, or partner and third-party POS products that post sales into SAP Business One. Source: ERP Research.
What is SAP Customer Checkout, and how do partner POS products work with SAP Business One?
SAP Customer Checkout is a point-of-sale application that can run standalone or connect to SAP Business One, and it talks to Business One through the B1 integration framework (B1if). Source: SAP Community. A partner POS add-on or third-party POS works the same way in principle: it holds the register, takes the sale, and posts it into SAP Business One. Ownership is the question that decides everything: which system owns sellable stock for each store, and does the sale post per receipt or as a daily summary? Because the POS is a separate product, you are in “a separate POS sits in the middle” unless Shopify POS runs the stores.
How do POS and storefronts share SAP Business One warehouses, price lists, and special prices?
Storefront-to-SAP-Business-One designs commonly map stock per warehouse with safety buffers, and route each storefront to the right company, currency, and price list. Special prices should have one owner, with the storefront and the POS reading from it. Otherwise the register and the website show different prices for the same account.
| Platform | What maps to an SAP Business One warehouse | Watch out for |
|---|---|---|
| Shopify | A Shopify location ID | A non-Shopify POS needs its own integration to deduct stock from the right location |
| Adobe Commerce / Magento | An MSI source | The store’s POS has to keep source quantities current |
| BigCommerce | A BigCommerce location | Native pickup APIs support a single storefront channel and no in-store stock transfers |
How do multiple storefronts route to the right company and currency?
Each storefront, and each shop within it, should map to one SAP Business One company, one currency, and one price list, decided once and written down. A storefront that has to guess is where wrong prices and wrong totals start. See our Shopify and SAP Business One integration and Adobe Commerce and SAP Business One integration pages. For SAP Business One multiple stores, the rule is the same: one integration, each store a mapped warehouse.
How does your ERP change things for Adobe Commerce and BigCommerce stores, not just Shopify?
Oracle’s and Microsoft’s own connectors cover Shopify. Adobe Commerce, Magento, and BigCommerce have no built-in POS, so they land in “a separate POS sits in the middle” whatever the ERP. Your integration has to map ERP locations to Magento MSI sources or BigCommerce locations, and keep a third-party POS in step. The ERP changes the names, not the problem.
| Platform | ERP location maps to | What to plan for |
|---|---|---|
| Shopify / Shopify Plus | A location with its own ID | Stores usually set lower in fulfillment priority than warehouses |
| Adobe Commerce / Magento | An MSI source, aggregated into stocks for sales channels | An ERP can update source quantities. Which system the POS reports to is the open question. |
| BigCommerce | A BigCommerce location | Pickup APIs support one storefront channel and no in-store transfers, so that logic lives in the ERP or integration |
Can NetSuite show per-store stock to Magento and BigCommerce? Yes, through an integration that maps each store to a source or location. Does Business Central work with Magento or BigCommerce POS setups? Microsoft’s connector covers Shopify, so these need a different integration. See Adobe Commerce and Business Central, Shopify and Business Central, and BigCommerce and NetSuite.
Which ERP versions and deployments matter for POS integration?
Version and deployment decide whether a connector or POS works at all. Ask every vendor for exact versions in writing, because “we support Business Central” is not an answer. These are the facts that matter most today.
| ERP | What to confirm | What we know |
|---|---|---|
| NetSuite | Standard or OneWorld edition | OneWorld adds subsidiaries (multiple legal entities) in one account |
| Business Central | Online or on-premises | Microsoft’s Shopify connector is online only; LS Central’s Shopify BC Connector needs version 28 or later |
| F&O | Current F&O version, or AX 2012 R3 | Microsoft states AX 2012 R3 support has ended; upgrade and N-1 support for Commerce end with Commerce version 10.0.40 |
| SAP Business One | Version and database | Version 10.0 is available on both Microsoft SQL Server and SAP HANA |
Sources: Microsoft Learn on Commerce upgrade and SAP on Business One 10.0.
When is the ERP vendor’s own connector enough, and when do you need a managed integration?
A native connector is enough when you have one store, simple pricing, and someone in-house who will own it. You need a managed integration when you have several stores, trade pricing, a mix of POS products, or nobody accountable after go-live. The difference is not features. It is who owns the mapping and the fixes.
Updates are where the gap shows. Microsoft’s FAQ says the latest Shopify API version is adopted in major Business Central releases, so the connector and Shopify move on different calendars. That is how “every time our ERP updates, the connector breaks” happens.
The native connector vs managed integration question, without brand names:
| Question | Vendor’s own connector | Managed integration |
|---|---|---|
| Scope | One platform, usually Shopify | Several platforms, including Adobe Commerce and BigCommerce |
| Multiple stores and POS | Works for simple cases; mixed POS and trade pricing need extra work | Designed around a store being a mapped location |
| After an ERP or platform update | You test and fix it | Someone else owns testing and fixing |
| After go-live | You own monitoring and field mapping | The partner owns monitoring and documents the mapping |
“Adding stores means adding connectors” is how sprawl starts. A new store should be set up on one integration, not another build. This is also where burned buyers come from: “we are not setting a clear mapping for the connector” and “our last integration partner disappeared after go-live.” If you’ve been there, you were right to want an owner.
Where i95Dev fits
We see the same five breakdowns in almost every multi-store project: stock published as on-hand, prices built in two places, duplicate customers, store sales flooding the ERP, and a mapping nobody wrote down. i95Dev has delivered more than 450 integrations, works deep on the ERP side, and owns the integration after go-live.
Not sure where you stand? If you already know your ERP and your next store is coming, talk to an i95Dev integration architect about your ERP.
Frequently Asked Questions
The Multi-Store Integration Series
Part of i95Dev’s series on connecting stores, registers, websites, and ERPs.
- Multi-Store ERP Integration: How to Get Every Store, Register, and Your Website to Agree
- Real-Time Inventory by Location: Why Your Website Sells Stock Your Store Already Sold
- POS, eCommerce, or ERP: Which System Should Own Your Stores’ Stock and Prices?
- Should Every Store Sale Post to Your ERP?
- Same Stores, Different ERP: NetSuite, Dynamics 365, and SAP Business One (you are here)
- 12 Multi-Store Integration Mistakes, and the Vendor Question That Catches Each One
- For Dynamics 365 F&O specifically: Commerce Scale Unit (CSU): The Complete Guide
