Notes
Unified commerce vs omnichannel: what changes in the data
Omnichannel means the customer can move between channels: buy online, pick up in a store, return anywhere. Unified commerce means the channels share one record for stock, orders and customers on one platform instead of keeping a database each. The difference shows up in how fast a sale in one channel reaches the others, and in what still has to be integrated with the ERP.
Updated
The difference in two sentences
Omnichannel describes what the customer can do: look online and buy in a store, buy online and pick up, return a web order at a counter. Unified commerce describes how the data sits behind that: one record for stock, orders and customers that every channel reads and writes, instead of a database per channel kept in step by integrations.
Shopify, which uses both terms, draws the line in the same place. In its description, omnichannel retailers connect front-end channels and still manage a separate database per channel; unified commerce runs channels, payments and customer data from one back-end platform. Neither term has a definition from a standards body, so the table below compares the three models on what can be checked.
| Multichannel | Omnichannel | Unified commerce | |
|---|---|---|---|
| Stock | A pool per channel | Shared, synced between channel systems | One record per item and location |
| Orders | Per channel, joined in the ERP | Per channel, visible across channels | One order record, tagged with its source |
| Returns | In the channel of purchase | Across channels, through integrations | Across channels in one system |
| Delay between channels | Hours, often a nightly run | The sync interval | None between channels on the platform |
Where the data lives in each model
In a multichannel setup, the webshop, the stores and a marketplace each keep their own copy of stock. The usual protection against overselling is a fixed split: 60 units for the web, 40 for the stores. A unit sold in a store is never offered online, and a unit left over online is never sold in a store.
An omnichannel setup connects those copies. A store sale is reported to the online store, an online order can be picked up in a store, and stock is offered across channels. Each connection is an integration with an interval, a failure mode and a mapping. The customer sees one business; the systems behind it are still separate.
In a unified setup, the POS and the online store are the same platform. In Shopify, an item has one InventoryLevel per location, and a POS sale and a web order change the same record. The data that still lives elsewhere is the ERP's: purchasing, receipts, costing, the general ledger, and often the warehouse. That boundary is where the integration work moves to.
What one shared stock record changes
Shopify keeps quantities per location in named states: incoming, on_hand, available, committed, reserved, damaged, safety_stock and quality_control. on_hand is the sum of all of them except incoming. committed is managed by Shopify itself as orders are created and fulfilled; the API cannot adjust it. Which of these numbers to show online is the subject of which stock counts.
A worked example. One item, 18 units on hand: 10 in the warehouse, 4 in store A, 3 in store B, 1 in store C. Stores A and B fulfill online orders and keep 1 unit each as safety stock; store C does not fulfill online orders.
- Offered online before any delay: 10 + (4 - 1) + (3 - 1) = 15.
- With the store POS on its own system and stock sent to the online store every 15 minutes, store sales of the last 15 minutes are not yet counted. Stores A and B sell this item 6 times an hour together: 6 x 15 / 60 = 1.5 units, rounded up to a buffer of 2. Offered online: 15 - 2 = 13.
- With the POS on the same platform, a store sale lowers the same
availablequantity the online store reads. The buffer for that delay goes, and 15 are offered.
The 2 units are not lost; they are not offered online. Across a catalog of 8,000 items, a buffer of 1 or 2 per item at the busy stores is the stock that a shared record makes available to sell.
Orders from every channel in one record
On one platform, a POS sale and a web order are the same object. Shopify's Order carries sourceName, with values such as web, mobile_app or pos, and retailLocation, the store where a POS order was created. Shopify splits every order into fulfillment orders per location automatically; they cannot be created by hand.
{
"name": "#20417",
"sourceName": "pos",
"retailLocation": { "name": "Store A, Columbus" },
"sourceIdentifier": "1042-3-2210",
"lineItems": [{ "sku": "HX-2210", "quantity": 1 }]
}
For the ERP, that one order type becomes different documents depending on the source and the location:
| Shopify order | What the ERP needs |
|---|---|
sourceName web, shipped from the warehouse |
Sales order at the warehouse location, then fulfillment |
sourceName pos, retailLocation store A |
Cash sale or invoice at store A, already fulfilled |
web, pickup at store B |
Sales order at store B; stock leaves store B on pickup |
A mapping from each Shopify location to an ERP location is the first table in this integration. Shopify allows 10 locations on Basic, Grow and Advanced and 200 on Plus, and every location with stock needs its counterpart in the ERP. How the order states line up is on order status mapping.
Returns across channels
Returns show whether the channels are actually connected. A web order returned at a store counter involves two locations: the one that shipped it and the one that takes it back.
Shopify POS documents the rule for its side. A restocked item goes back into the inventory of the location the POS is assigned to. Items fulfilled by a third-party logistics provider can only be restocked to their original location. Pickup of online orders in a store, managed from POS, requires the location to be on POS Pro.
The ERP has to follow the same rule. If the store takes back the item and Shopify adds 1 to store A, while the ERP books the return at the warehouse that shipped it, the two systems disagree by one unit at two locations. With 30 cross-channel returns a week, that is 30 corrections a week, found only at the next stock count. The integration sends the return with the location where it was restocked, and the ERP posts it there.
What stays outside the platform
One platform removes the integrations between channels on that platform. It does not remove these:
- Purchasing and receipts. A purchase order received in the ERP raises
on_handin the warehouse; that change has to reach the platform. - Accounting. POS and web orders post to revenue, tax and payment accounts in the ERP, per location and per day.
- Transfers. Stock moved from the warehouse to store B is a transfer in the ERP and in the platform; both sides change two locations.
- Marketplaces and B2B. Channels that are not on the platform keep their own stock record and need a buffer of their own, as in the multichannel model.
The direction per data type and the delay per stream are decided per flow, as described in real time vs batch.
What this means for your integration
Whether you run one platform or several, the work sits at the same boundary: every location mapped to the ERP, every order posted at the right location, every return restocked where it physically went, and every receipt and transfer sent back. We build that integration to your locations and rules, then host and run it, with retries and a queue so a store sale is not lost when the ERP is slow.
Stock across stores and warehouses is covered in multi-location inventory. Tell us which locations and channels you run, and we show you which stock and order flows connect them to your ERP.
Frequently asked questions
Is unified commerce just a new name for omnichannel?
Partly. No standards body defines either term, and vendors use them differently. The useful distinction is technical: omnichannel describes what the customer can do across channels, unified commerce describes channels sharing one data record. A retailer can offer pickup and returns across channels with separate systems; it then needs integrations to keep them in step.
What is the difference between multichannel and omnichannel?
Multichannel means selling in several channels that run separately: each has its own stock pool, its own orders and its own customers, and they meet in the ERP. Omnichannel means the channels are connected for the customer, so stock, orders and returns cross from one channel to another.
If we run Shopify POS and Shopify online, do we still need an ERP integration?
Yes, if purchasing, accounting or warehouse stock live in an ERP. One platform removes the integration between POS and the online store. Orders still have to reach the ERP with their location, returns have to restock in the ERP at the right location, and receipts and transfers in the ERP have to reach the platform.
How many locations can Shopify hold?
Two on Starter, 10 on Basic, Grow and Advanced, and 200 on Plus. Each store, warehouse and 3PL that holds stock is a location, and each one needs a matching location in the ERP for stock and orders to line up.
Where does a return made in a store go back into stock?
In Shopify POS, a restocked item goes to the location the POS is assigned to, not to the location that shipped it. Items fulfilled by a third-party logistics provider can only be restocked to their original location. The ERP has to post the return at the same location, or the two stock counts drift by one unit per return.
Tell us what you need
Tell us which systems you use and what needs to work better. We reply personally within one working day. We help you define the work, then agree the price and timing before you commit.
- You know the price and the timeline before you commit to anything
- We work out the connection that takes the work off your hands
- We handle the build, hosting, monitoring and maintenance
- Your team has less information to retype and fewer discrepancies to chase