Who Owns Stock and Price? Multi-Store Integration Architecture 

“We’re managing two versions of the truth.” We hear some form of that sentence in almost every conversation about stores. The store says there are six units. The website says four. The ERP says nine, two of which are already on a truck. A trade customer walks up to the counter, gets quoted list price, and calls their rep to complain. 

None of this is a connector problem first. Most of these businesses are already integrated; their stores and storefront are connected but still don’t agree. It is an ownership problem. Every multi-store business must answer four questions, whether it answers them on purpose or by accident: 

1. Stock: which system holds the number everyone else trusts? 
2. Price: which system decides what a given customer pays, in a given place, today? 
3. Customer and loyalty: which system holds the account, the points balance, and the store credit? 
4. The sale: where does the financial record of a transaction live, and when does it get there? 

Owning store truth means being the system whose answer wins when two systems disagree on one of those questions. There is no single right multi-store integration architecture. There is a right owner for each of those four things, and the common setups are just the four common ways of assigning them. Most price mismatches between the website and the register come from one avoidable mistake: running two pricing engines and hoping they agree. 

This guide lays out the four setups, shows who owns what in each, and gives you the factors that pick one for your business. It then goes deep on the two areas where architectures usually break in practice: pricing and the branch counter. 

Each setup is defined by which system owns stock, price, customer, and the sale. Read across a row to see a whole design. Read down a column to see how differently the same question gets answered. 

Setup	Stock owner	Price owner	Customer and loyalty owner	Financial record	Typical stacks	Best for	Breaks when
A. The ERP runs the stores	ERP (each store is a warehouse or site)	ERP pricing engine, calculated at the register	ERP or its commerce module	ERP, natively	D365 Commerce with Store Commerce and CSU; Business Central with LS Central; NetSuite POS or SuiteCommerce InStore (retiring)	Many stores, high volume, complex pricing, offline needs	The website runs its own prices and promotions, so the two engines drift
B. Shopify runs the stores	Shopify for sellable stock; ERP for valuation and replenishment	ERP authors; Shopify executes through catalogs and price lists	Shopify plus a loyalty app	ERP, through posted orders or daily summaries	Shopify POS and Shopify online with D365 BC, F&O, NetSuite, Acumatica, SAP Business One	Retail-led brands, D2C plus stores, pricing that fits in price lists	Contract pricing is too complex to express as catalogs, or posting volume overwhelms the ERP
C. A separate POS in the middle	Must be chosen; usually the ERP	Must be chosen; often split by accident	Split between POS and web unless one is named	ERP, through POS exports or an integration	Lightspeed, Retail Pro, or similar with Adobe Commerce (Magento) or BigCommerce and an ERP	Retailers with a POS they like and a site they won’t replatform	Three systems each keep a stock number and nobody says which one wins
D. Orchestration	An order management layer owns available-to-promise; the ERP owns on-hand and value	ERP or a pricing engine the layer calls	A customer or loyalty platform the layer reads	ERP	An OMS or integration hub across several channels, sometimes several ERPs	Ship-from-store, store pickup at scale, multiple banners or ERPs	It is added to hide unclear ownership instead of fixing it

 

Two things stand out. First, the financial record lands in the ERP in all four setups; what changes is how and when it gets there (see posting POS sales to the ERP]). Second, stock and price are the two columns where setups B and C most often fail, because ownership was never written down. 

In Setup A, the register is part of the ERP. Each store is a site or warehouse in the ERP, the POS reads the ERP’s pricing and discount rules, and every sale lands in the ERP’s own tables. Stock, price, customer, and the financial record all have the same owner. 

The common versions: 

• Dynamics 365 Commerce. The Store Commerce app talks to a Commerce Scale Unit (CSU), which runs the pricing and discount engine and holds a channel database synced from headquarters. Trade agreements, discounts, loyalty, and gift cards are all configured in headquarters and calculated at the register. If you are deciding how your website should reach that same engine, start with What Is Commerce Scale Unit (CSU)? and OData vs Commerce Scale Unit. 
• Business Central with LS Central. LS Central adds a retail POS, store replenishment, offers, and member management on top of BC, so the store and the back office share one database model. 
• NetSuite POS and SuiteCommerce InStore. Both run on NetSuite records directly. Oracle has stopped licensing them to new customers and support ends on January 31, 2029, so every retailer on these products will need a replacement. 

Where it is strong. One pricing engine means a price change in the ERP reaches every register. Store stock is the ERP’s stock, so there is no reconciliation between a POS count and an ERP count. Offline modes are mature: D365’s Store Commerce, for example, can keep selling against a local database when the connection drops. Account customers, credit limits, and charge-to-account work because the register can see the same customer record as accounts receivable. 

Where it breaks. The stores are rarely the problem. The website is. If the online store is a separate platform, such as Shopify, Adobe Commerce, or BigCommerce, it needs the same prices and promotions the registers calculate. Teams often sync a price list to the site and rebuild promotions there by hand. That creates a second pricing engine, and the drift begins. The fix is to have the site ask the ERP’s engine for the price, or to sync calculated results, not to re-implement the rules (more in the pricing section below). 

Setup A also carries the ERP’s implementation weight. Store-floor usability depends on the ERP vendor’s POS design, and the rollout runs as an ERP project rather than a standalone retail project. 

In Setup B, Shopify POS and the Shopify online store share one product catalog, one inventory model, and one customer record. The ERP sits behind them as the back office through a Shopify ERP integration: purchasing, replenishment, costing, finance, and often the master for products and prices. 

This is the “Shopify POS vs ERP POS” decision most retailers are making. Shopify POS wins on store experience, hardware speed, and the fact that online and in-store are already one system. The ERP’s POS wins when pricing and account rules are too complex to live anywhere but the ERP. 

Who owns what. Shopify should own the sellable stock number, because both channels sell from it and it updates on every sale. The ERP should own on-hand valuation, receipts, transfers, and replenishment. That means stock moves in two directions: receipts and transfers flow from the ERP to Shopify, and sales flow from Shopify to the ERP. Pick one direction for each event type and document it. 

Where ERP pricing must flow in. The ERP usually author lists prices, costs, and trade terms. Shopify executes them. Shopify’s B2B features model each trade customer as a company with locations, catalogs, and payment terms such as Net 30, and those can apply at the register as well as online. The question is fit: can your ERP’s price structure be expressed as Shopify catalogs and price lists? Simple tiers and group prices usually can. Thousands of customer-item contract prices with date ranges and quantity breaks often can’t, or not without an app or a price lookup back to the ERP. 

Where it breaks. Two places. First, pricing complexity, as above. Second, posting volume. A 40-store chain doing 300 transactions per store per day sends 12,000 orders a day toward the ERP. Posting each one as a full sales order can swamp an ERP sized for wholesale. Many Setup B designs post daily summaries per store and tender instead, with line detail kept in Shopify. How to choose between those is the subject of Posting Store Sales to Your ERP 

Setup C is the typical design for retailers on Adobe Commerce (Magento) or BigCommerce, because neither platform ships a store POS of its own. The stores run a dedicated retail POS. The website runs on its own platform. The ERP runs finance and purchasing. Three systems, each built to hold its own inventory and its own prices. 

The three-stock-numbers problem. Out of the box, the POS tracks store stock, the eCommerce platform tracks sellable stock, and the ERP tracks on-hand. All three are “right” by their own rules, and they disagree within minutes of opening. A customer buys the last unit online, the store sells it again at the register, and someone has to call the customer. 

The fix is to name a master for each number and make the others subscribers: 

1. On-hand by location: the ERP, fed by POS sales and web orders as they happen. 
2. Available to sell online: calculated from ERP on-hand minus safety stock and open orders, then pushed to the website. Pushing raw on-hand instead is why inventory sync still breaks customer trust. 
3. Store stock at the register: the POS can keep a working copy for speed and offline use, but counts and adjustments post back to the ERP, and the ERP wins any disagreement. 

Pricing in Setup C. Every one of the three systems has a pricing engine, and that is the danger. Decide which one calculates. In most distribution and B2B-heavy businesses, it should be the ERP, with the POS and the website either receiving calculated prices or calling the ERP at checkout. Retailers with simple pricing sometimes let the POS own store promotions, which is fine if the website never needs to match them. 

Where it breaks. When nobody writes down which system wins. Setup C works well when ownership is explicit. It is where most “two versions of the truth” complaints come from when it isn’t. 

Setup D adds an order management or orchestration layer between the channels and the ERP. That layer owns available-to-promise across stores, warehouses, and channels and decides where each order is fulfilled. The ERP keeps on-hand costs and the books. 

It earns its cost when you route orders across many nodes: ship-from-store, store pickup at volume, several banners, or several ERPs after an acquisition. For a mid-market retailer with one ERP and a dozen stores, it is usually overkill. An orchestration layer cannot fix unclear ownership; it gives unclear ownership another place to hide. 

Which system should be the master for store stock? 

The right owner depends on seven factors. None of them picks a setup alone, but two or three pointing the same way usually settle it. 

Factor	Tilts toward the ERP owning stores (A)	Tilts toward Shopify owning stores (B)	Tilts toward a separate POS (C) or orchestration (D)
Store count	Dozens to hundreds of stores on one rulebook	A handful to a few dozen, retail-led	Many stores across banners or ERPs (D)
Transactions per store per day	High volume where posting detail to the ERP must be native	Moderate volume, posted as summaries	Very high volume with fulfillment across nodes (D)
Pricing complexity	Contract prices, trade agreements, quantity breaks, date ranges	List, sale, and a few customer tiers	Store-run promotions on a POS the team know (C)
Trade accounts at the counter	Charge to account, credit limits, and net terms checked against AR	Occasional B2B buyers who fit company catalogs	Counter sales handled in the POS with an ERP price lookup (C)
Loyalty	Points and store credit already in the ERP	Points tied to the online store and Shopify customer	A dedicated loyalty platform both channels call (D)
Offline tolerance	Stores must keep selling at full pricing with no connection	Short outages are acceptable	Depends on the POS; check its offline pricing
Existing POS commitments	No POS contract worth keeping	POS contract ending or Shopify already online	A POS contract with years left, or a POS the stores won’t give up (C)

Read the table by rows that matter most to you, not by counting ticks. A distributor with 15 branches and heavy counter trade can land in Setup A even with a small store count, because the counter factor dominates. A fashion brand with 60 stores and simple pricing can land in Setup B, because pricing and loyalty favor one system with the website. 

Can you run different POS setups in different stores? Yes, and some businesses should. Shopify POS in small-format or pop-up stores with the ERP’s POS in flagships is a legitimate mix. So is the ERP’s POS at trade counters and Shopify POS in consumer showrooms. The test is whether stock and price still have one owner each across every store. If they do, a mixed estate is just two front ends on one rulebook. 

The cost is real, though. You run two POS products, two sets of hardware and training, and two posting integrations into the ERP. Promotions and loyalty need to work identically in both, which usually means configuring them once in the owner and pushing results to both front ends. Budget for that as a permanent cost, not a migration expense. 

How to move from one setup to another without a big-bang cutover. Change ownership one domain at a time, in this order: 

1. Stock first. Make the target system the master for on-hand while the old POS still rings sales. Stores keep working, and you find count and transfer problems early. 
2. Pricing second. Move price authoring and calculation to the target owner, and have the old POS receive prices from it. Price disputes at the register will tell you quickly if anything is missing. 
3. The POS last. Swap registers store by store, starting with a low-risk location. By now stock and price already come from the new owner, so the register swap is a front-end change, not a data migration. 

This order also works for the NetSuite POS retirement: whichever replacement you choose, including Shopify POS with NetSuite, keep stock and pricing owned by NetSuite itself, connect the replacement to them, and only then change the registers. 

Why do prices differ between the website and the register? 

“Our B2B customers are calling us to get their prices.” When a customer has to phone in to learn what they pay, the price exists in the ERP but never reached the channel they are using. Price drift between the website and the register has three usual causes: 

• Two engines. The ERP calculates store prices, and the website recalculates from a synced list with its own promotion rules. Every rule added to one and not the other becomes a mismatch. 
• Stale syncs. A price change goes live in the ERP at 9:00, the website picks it up at the next nightly batch, and the register shows the new price all day while the site shows the old one. 
• Missing context. The website received the list price but not the customer’s group, contract, or quantity breaks, so a logged-in trade customer sees retail. 

If the ERP has the right price but the website shows the wrong one, it is almost always the second or third cause. For how this shows up in revenue, see Why Pricing Sync Still Breaks Revenue and Why ‘Real-Time’ Sync Isn’t Always Real-Time. 

What is the difference between syncing a price and calculating a price? 

Price sync: the owner system produces a price or a price list, and the integration copies the result into the channel on a schedule or on change. The channel shows what it was given. 

Price calculation: the channel asks the pricing engine for a price now it needs one, passing the customer, store, quantity, date, and cart. The engine applies every rule and returns the answer. 

Sync is enough when prices depend on a small number of things you can enumerate: one list per store or region, a handful of customer groups, scheduled sales. Calculation is needed when the price depends on combinations you can’t pre-compute: customer-item contracts, quantity breaks on mixed carts, stacked promotions, or prices that change by date. 

Store-specific, regional, customer-specific, and contract prices can coexist, as long as one engine applies them in a known order. That one engine is what makes consistent pricing online and in store possible. 

Price type	Owner	How it reaches each channel
List price	ERP	Sync to POS and website
Store or regional price	ERP	Sync as a price list per store, region, or market
Customer group or tier price	ERP	Sync if there are few groups; calculate if groups combine with other rules
Customer-specific contract price	ERP	Calculate at checkout and at the register, or sync per customer if volumes are small
Promotion or discount	One engine, usually the ERP or POS pricing engine	Calculate; never rebuild by hand in a second system
Loyalty discount or redemption	The loyalty owner	Calculate against the shared balance at checkout

If you run D365 F&O or Commerce, the Commerce Scale Unit series covers how the website can call the Commerce pricing engine directly, and 7 Retail Scenarios Where CSU Makes All the Difference shows it in practice; we won’t repeat that here. 

The trade counter, and counter sales pricing for distributors in particular, is where architecture decisions get tested hardest, and it is the part most guides skip. 

A contractor walks into a branch at 7:00 a.m., wants 40 items, expects their contract price, and wants it on their account. Five things have to work, and each one depends on an owner. 

Counter task	What must happen	Which system must answer
Account lookup	Staff find the account by number, company name, phone, or card, and pick the right job or ship-to	The customer owner, usually the ERP
Contract and tier pricing	Every line prices from the customer’s price book: contract prices first, then tiered pricing and quantity breaks, then list	The pricing engine, calculated at the register
Charge to account	The sale goes on the account under net terms, after a credit limit and on-hold check	Accounts receivable in the ERP, in real time or from a recent cache
PO and tax details	The customer’s PO number, job reference, and tax exemption are captured on the sale	Stored with the sale and posted to the ERP invoice
Will-call pickup	An order placed online or by phone is picked at the branch, released at the counter, and signed for	The order owner, with branch stock reserved at order time

The common failure is a counter POS that can look up the customer but not price for them. Staff then override prices by hand from a printed list, margins leak, and the customer’s next online order shows a different number. The second failure is charge-to-account without a live credit check, which turns the counter into an unsecured credit line; the same gap online is covered in Why Payment Terms Sync Still Creates Financial Risk. 

What good looks like. The register sends the customer, branch, and cart to the same engine the website uses, gets back customer-specific pricing at POS, checks credit against AR, and posts an invoice rather than a cash receipt. Online, the same customer logs in and sees the same price book. The price lives in one place; both channels ask it. 

In Setup A this is native. In Setup B, it depends on how much of the price book fits into Shopify’s company catalogs and whether credit checks can reach the ERP. In Setup C, the POS needs an ERP price and credit lookup, which is an integration to design deliberately, not a sync to schedule. 

How do you run one promotion across every channel? Configure it once, in the system that owns price, and let every channel calculate against it. If marketing builds “20% off outerwear this weekend” in the ERP and again in the website’s discount tool, the two will differ on exclusions, rounding, or end time (Why Discount Sync Still Breaks Promotions walks through the failure modes). One configuration point means one set of rules, one start and stop, and one report of what it cost. 

Where a channel can’t call the owner’s engine, push the promotion’s result (the discounted price per item and store) rather than asking someone to rebuild the rule. 

How do loyalty points, gift cards, and store credit stay the same online and in store? Unified loyalty online and in store comes down to one rule: each balance has one owner, and every channel reads and writes that balance live. Points earned at the register must be spendable online the same afternoon. A gift card sold in store must redeem at the website checkout. Store credit issued for a return must show on the customer’s online account. 

The failure pattern is two balances: the POS keeps one, the website keeps another, and a nightly sync reconciles them. That works until a customer spends the same credit twice before the batch runs. Balances that represent money should never be synced on a schedule. They should be checked and decremented in one place, now of use. 

One multi-banner retailer in our Commerce Scale Unit work runs a single loyalty wallet across all its banners, with earn and burn rules enforced centrally in D365 Commerce. Every banner’s register and website call the same balance, so a customer sees one points total wherever they shop. 

The four setups are not a ranking. Each one works when stock, price, customer, and the sale each have a named owner, and each one fails when two systems both think they’re in charge. Write the ownership down first. The products, connectors, and posting design follow from it. 

Next step: score your current setup against the seven factors with our multi-store architecture scorecard, or take the ERP-eCommerce alignment audit. If the answers point somewhere you aren’t, talk to us about an architecture review and we’ll show where ownership is split today. 

More in this series 

• Pillar: Multi-store ERP integration
• Piece 4: How to post POS sales to the ERP
• Piece 5: NetSuite POS retirement and your options
• Your Stores and Your Storefront May Be Connected. They Just Don’t Agree. 
• What Is Commerce Scale Unit (CSU)? and OData vs Commerce Scale Unit, for D365 F&O and Commerce readers 
• Beyond the Sync: the integration truths no one tells you