OData is Microsoft's standard API framework for reading and writing records inside Dynamics 365 Finance & Operations. Commerce Scale Unit (CSU) is the retail services layer behind it that exposes real-time retail logic, including pricing, promotions, inventory, and loyalty, through its own APIs. One moves ERP data; the other runs retail decisions. Most confusion around “OData vs. CSU” comes from treating them as competing choices, when they answer different questions.
Any retailer running Dynamics 365 Finance & Operations behind an Adobe Commerce or Shopify storefront eventually runs into both terms, usually while figuring out how to support physical stores or real-time pricing. This is a decision works through with retailers regularly, and this article covers what CSU is, where it sits in Microsoft's retail architecture, where OData strains, and how integration needs mature as a retailer grows.
The Core Distinction, Stated Plainly
OData answers “what is this record?” Ask it for a product's price and it returns whatever value is stored, without evaluating whether a promotion applies or a shopper qualifies for a negotiated rate.
CSU answers “what should happen right now?” Ask it for a price and it runs the request through the same rules engine a cashier's register uses, factoring in the customer, the store, and any active promotions at that moment. Stored record versus computed answer: that distinction is what the rest of this article is built around.
Where CSU Sits: The Microsoft Retail Architecture
CSU isn't a bolt-on product competing for your storefront. It's one piece of a larger retail architecture extending Dynamics 365 Finance & Operations, and each piece has a distinct job.
| Component | What It Does |
| Headquarters (Dynamics 365 Finance & Operations) | System of record for products, pricing, inventory, customers, and financials |
| Commerce Scale Unit (CSU) | Deployable bundle exposing retail APIs without querying the ERP directly |
| Commerce Runtime (CRT) | Executes retail logic: pricing, discounts, promotions, tax, loyalty |
| Retail Server | Secure gateway that routes requests to Commerce Runtime |
| Channel Database | Local, retail-optimized data store for fast transaction performance |
| Commerce Data Exchange (CDX) | Syncs data between Headquarters and retail channels |
| Store Commerce / POS | In-store application associates use for sales, returns, and exchanges |
Headquarters is the Finance & Operations environment, governing product data, pricing, inventory, procurement, and financials. Nothing about CSU changes that; it remains the single source of truth.
Commerce Scale Unit packages the Channel Database, Retail Server, and Commerce Runtime as one deployable unit. Any connected client, whether a POS terminal, a kiosk, or an eCommerce integration, gets results from the same shared logic, which is why a price quoted online matches the price at the register: both are computed by the same engine.
Commerce Runtime is where the logic lives: pricing, discount validation, promotions, tax, and loyalty all run here, using the same rules applied at physical registers. It's a live calculation, not a value typed into a field last week.
Retail Server authenticates requests and routes them to Commerce Runtime, so external applications never reach retail logic directly. Channel Database keeps things fast: instead of hitting Headquarters per request, Commerce Runtime pulls data from this retail-optimized store. Commerce Data Exchange (CDX) syncs customer, product, pricing, and inventory data between Headquarters and the Channel Database so every channel stays aligned with the ERP.
For fashion retailers, CSU can be particularly valuable for supporting omnichannel experiences where pricing, inventory, promotions, and customer interactions need to stay consistent across online and physical retail channels. Learn more about .
CSU can be deployed more than one way. Most retailers use it as a cloud-hosted, Microsoft-managed service, the simpler default. Locations with unreliable connectivity can run a self-hosted CSU that keeps processing sales locally if the connection drops, resyncing once it's back. Microsoft has also been moving CSU toward CSU Core, a next-generation runtime built on ASP.NET Core with better performance; if you're scoping a new implementation, it's worth confirming with your Microsoft partner, or with an integration partner like , which runtime version your environment will run on. Either way, CSU becomes a second integration path alongside OData, used where the interaction is retail-specific.
Where OData Does Its Best Work
For a large share of retailers, especially those early in their omnichannel journey, OData handles the integration end to end: catalog publishing, customer sync, order transfer, standard inventory quantities, and financial reporting.
If a business sells through a single channel, fulfills from a central warehouse, and doesn't need pricing to flex in real time, OData alone can carry an integration for years. There's no reason to introduce CSU before it solves an actual problem.
Where OData Starts to Show Its Limits
The strain shows up in five recurring areas, all involving business logic rather than static data.
- Store-level inventory. OData can sync a stock quantity, but can't tell a shopper if it's available for pickup once reservations, in-progress transactions, and safety stock are factored in.
- Omnichannel pricing and promotions. Retailers with customer-specific or store-level pricing often recreate that logic inside the eCommerce platform, and the two versions drift out of sync.
- Loyalty and gift cards. Customers expect rewards earned in-store to be usable online, in real time; syncing balances on a schedule creates a lag they notice.
- BOPIS and store-based fulfillment. This needs live inventory validation, reservation, and store notification together, which batch sync can't support without heavy custom development.
- Channel consistency. Customers expect pricing and inventory to match regardless of channel, requiring both to draw from the same rules engine rather than two loosely synced copies.
OData also carries a transfer cap of roughly 10,000 records per page and is subject to API throttling. These limits rarely matter for ordinary sync, but they become real problems once a team stretches OData beyond that role, which is usually the moment CSU becomes worth evaluating.
How Integration Needs Typically Mature
Most retailers don't need CSU on day one; the right architecture depends on where the business is today.
Stage 1: Growing eCommerce business. Primarily online, one or two locations, standard pricing, centralized fulfillment. A single OData integration is usually enough.
Stage 2: Expanding retail operations. Multiple stores, growing BOPIS demand, and customers expecting consistent pricing across channels. This is where OData alone starts generating workarounds, and where CSU starts paying off.
Stage 3: Mature . Multiple stores, warehouses, and fulfillment paths operating as one connected business, with CSU central and OData still handling ERP data exchange in the background.
Retailers rarely need every CSU scenario at once. A sensible order: inventory availability first, the cleanest fit and usually the first thing customers notice missing; real-time pricing next, especially for B2B customers on negotiated rates; order capture once those two are stable; and loyalty last, since it depends on identity and order history already being consistent. Product data, customer records, and financial transactions stay on OData throughout.
That last point is worth stating directly, since it's the most common point of confusion once a team gets excited about CSU: certain things should never move there, regardless of how far the omnichannel roadmap goes. CSU doesn't expose them, and rebuilding access there adds cost with no functional gain:
- Product and category master data
- Customer master records and B2B company or contact hierarchies
- Customer groups and payment terms
- Warehouses and exchange rates
- Posted invoices, credit memos, and payment journals
These stay on OData permanently. In a typical Finance & Operations to eCommerce connector, only a handful of functional areas, generally inventory, pricing, order capture, and loyalty, are genuine CSU candidates, which is how scope this boundary by default. Everything else is exactly where it should already be.
Comparing the Two Approaches
| Business Requirement | OData | Commerce Scale Unit |
| Product catalog synchronization | Well suited | Supported |
| Customer synchronization | Well suited | Supported where retail context is needed |
| Standard order synchronization | Well suited | Supported |
| Financial data exchange | Primary use case | Not the intended purpose |
| Store-specific inventory availability | Limited | Purpose-built for this |
| Customer-specific / omnichannel pricing | Limited | Native retail pricing engine |
| Promotions | Limited | Native promotion support |
| Loyalty programs | No general OData surface | Native capability |
| BOPIS / ship-from-store | Requires heavy customization | Purpose-built for this |
| POS integration | Not designed for this | Native retail integration |
Conclusion
OData and Commerce Scale Unit aren't rivals; the right one depends on the capability being delivered. If the requirement is exchanging ERP data, OData is simpler. If it's a retail experience that behaves the same online or in-store, CSU is built for that. Most retailers eventually need both, just not on the same timeline. If you're mapping where that line falls for your own Adobe Commerce or Shopify integration, works through this decision as part of Dynamics 365 implementations.
Frequently Asked Questions
Is CSU a separate product I need to buy instead of Finance & Operations? No. CSU is a component of the Dynamics 365 Commerce architecture, generally licensed alongside it, and adopting it doesn't mean replacing an existing Finance & Operations investment.
Can OData and CSU run side by side without conflicting or slowing each other down? Yes. They're separate services on separate infrastructure, so the integration layer routes each request appropriately.
How should a team decide which integration to use, capability by capability? If the answer could change minute to minute, like a reservation or a loyalty redemption, it belongs on CSU. If it's a stored record that rarely changes, OData is the right fit.
Can Adobe Commerce or Shopify integrate with CSU, or is it Shopify-only? CSU is platform-independent on the storefront side. Adobe Commerce, Shopify, or any other platform capable of calling REST APIs can integrate with it while Finance & Operations continues to serve as the ERP.
Is OData being phased out in favor of Commerce Scale Unit? No. OData remains Microsoft's standard mechanism for ERP data exchange and isn't being deprecated in favor of CSU. The two are expected to keep operating together.