You already sell online. Then you open a shop, or a pop-up, or start selling at markets — and you discover that one stock figure now has to serve two places that update at different speeds. Four specific moments decide whether that works: a simultaneous sale, a click-and-collect hold, an in-store return of a web order, and the lag between a sale and everything downstream.
This is not the same problem as running a retail chain. It is the problem of an online business that has just acquired a physical channel, where the website was the system of record and now something else is selling from the same shelf.
Each of the four has a specific answer. None of them is “buy an ERP and it sorts itself out.”
Key takeaways
- Overselling between channels is a stock-ownership problem, not a reporting problem. Omnichannel inventory management comes down to which system holds the number.
- The fix is architectural. Either one system owns stock and the other reads from it, or you are maintaining a sync and its failure modes forever.
- In Odoo, POS and eCommerce read the same inventory records. There is no connector between them because there are not two stock systems to connect.
- Stock and accounting move on different clocks. A POS sale decrements stock immediately; the accounting entries post when the session is closed.
- Click-and-collect is a reservation problem. The hard part is holding the unit and handling the pick that fails.
- In-store returns of web orders are the messiest case — and the one to test before you commit to any system.
The four moments where the till and the website disagree
“Real-time inventory across channels” is on every feature list. It is not a specification. These four situations are what it has to mean in practice.
1. Two channels, one unit, same minute
Someone adds the last unit to their online basket. A customer in the shop picks the same unit off the shelf and takes it to the counter.
If your POS and your storefront hold separate stock counts and reconcile on a schedule, one of those two sales is going to fail after you have taken the money. The question to ask any vendor is not “is it real-time?” but “which system holds the number, and what does the other one do when it wants to sell against it?”
There are only two coherent answers. Either one system owns the count and everything else reads from it, or you are running a synchronisation — in which case you need to know its interval, its failure behaviour, and what safety buffer you are holding to cover the gap.
2. Click-and-collect holds a unit you can still sell
A web order for collection is a claim on a specific unit in a specific location. Until it is picked, that unit is physically still on the shelf, where a walk-in customer can buy it.
This is a reservation problem, and the parts that need answering are: when does the hold get placed, how long does it last, what does the counter system show the person serving, and what happens when someone buys it anyway?
Most systems handle the happy path. The exception path — the pick that fails because the unit is not there — is where the customer experience is actually decided, and it is the part worth testing before you buy.
3. An in-store return against a web order
A customer walks in with something they bought on your website and wants to return it over the counter.
Four things have to happen: the return is received, the stock is put somewhere, the refund is issued, and the accounting records it. Each carries a decision.
- Where does the stock go? Onto the shop’s shelf, or back to the warehouse it shipped from? Those are different stock locations and the answer changes your counts.
- How is the refund tendered? The original payment went through your online payment provider. Refunding at a physical till against a card that was never present is the specific thing that trips people up.
- Which document does it create? A credit note against the original order, not a fresh POS refund, if you want the paperwork to reconcile.
This is the case to test in a demo before you commit to any system. For a business that started online, it is also the most common cross-channel transaction after a straightforward sale — and the one most likely to be quietly unsupported.
4. The gap between a sale and everything downstream
Even when stock is shared, not everything moves at the same moment. Stock, accounting and reporting can each run on a different clock, and the differences are usually invisible until someone asks why two screens disagree mid-afternoon.
Ask what updates per transaction and what batches, because that difference determines what your reports show at 4pm on a Saturday.
What Odoo actually does here
We implement Odoo, so read this section accordingly. The architectural point stands regardless of what you end up buying.
In Odoo, Point of Sale and eCommerce are not two systems that need connecting. Odoo’s own Point of Sale documentation describes POS as integrated with Inventory, which installs alongside it — POS sales register directly against the same stock records the website reads. There is no connector between counter and web because there is not a second stock system to connect to. This is what POS and ecommerce integration looks like when it is architectural rather than bolted on.
That resolves moment 1 by removing the problem rather than managing it. It does not, by itself, resolve moments 2 and 3.
On timing, one precision worth having. A POS sale creates a stock move immediately — quantity on hand drops per transaction, not in a batch at the end of the day. What waits for session close is the accounting: the journal entries and reconciliation post when the session is closed and validated. Stock is live; the ledger catches up at session end. If somebody tells you Odoo POS is “real-time,” that is true of stock and not of the accounting entries, and conflating the two will cause an argument with your accountant.
Click-and-collect is a named feature. Odoo calls it Click & Collect, configured as a delivery method with the provider set to pick up in store and specific warehouses assigned as pickup locations. Per Odoo’s eCommerce delivery documentation, the product page shows availability per pickup location and blocks a location where the item is out of stock, unless you have explicitly allowed continued selling. That behaviour is only possible because the storefront is reading the same live stock the counter is selling from.
(Odoo documents these behaviours across recent versions; the citations above point to version 18 for Point of Sale and version 19 for eCommerce delivery. Check the pages for whichever version you are running, since details do shift between releases.)
In-store returns of web orders need checking against your version. Odoo’s POS return workflow is documented for returning POS orders. Returning a website order in-store is supported by the shared data model, but in practice tends to run through the Sales app’s return and credit-note workflow rather than the POS return screen. Confirm this against your own Odoo version and configuration before assuming it works the way you want — it is exactly the kind of thing that is fine in a demo and awkward in a queue.
What this costs
In our experience an Odoo implementation covering both an online store and a physical channel runs from roughly $5,000 to $100,000 (USD), and the widest variable is how much configuration your own team absorbs rather than your size. Teams that learn the system and configure it themselves typically land at $5,000–$10,000 in around four to eight weeks. Teams that hand it over entirely typically sit at $10,000–$100,000 over three to six months. The full breakdown is in what an Odoo ecommerce implementation actually costs.
For adding a physical channel specifically, the items that move the number are:
- How many selling locations, because each one is a stock location with its own counts and its own staff.
- Whether you need click-and-collect, which adds reservation logic and a pick process at the location.
- Payment and fiscal compliance, which varies enormously by country and is the item most often discovered late.
- Existing stock data quality, which is usually worse than anyone expects once a second channel starts reading from it.
When this does not apply to you
If you sell online only, none of the four moments arises. The question you actually have is whether you need an ERP at all, and we cover that in ERP for ecommerce: when your store actually needs one.
If you are a retailer first — several established locations, ecommerce as a secondary channel — your constraints are different from the ones described here, and the sequencing advice above is aimed the other way round.
If you have one location and a small website and stock rarely runs to the last unit, a simpler integration will serve you for a while. These four moments only become expensive when you are frequently selling the last of something.
The honest trigger is not location count or revenue. It is the first time you sell a unit twice and have to tell a customer.
Frequently asked questions
What is POS and ecommerce integration?
Connecting the system that takes payments in person with the one that takes orders online, so that both work from the same stock, customer and order records. Done properly it means selling a unit in one channel immediately removes it from the other, without anyone reconciling by hand.
What is omnichannel inventory management?
Keeping one accurate stock figure across every place you sell — counter, website, and any marketplace — so that selling a unit in one channel immediately removes it from the others. In practice it is decided by architecture: either all channels read one shared count, or you run a synchronisation between separate counts and manage its lag.
How do I keep POS and online stock in sync?
Either use a system where both read the same underlying stock records, or run a synchronisation and accept its interval and failure modes. In Odoo, Point of Sale and eCommerce both register against the same Inventory records, so there is no connector to maintain between them.
Does Odoo POS update stock in real time?
Stock, yes — a POS sale creates a stock move immediately and quantity on hand drops per transaction. Accounting is different: journal entries and reconciliation post when the POS session is closed and validated, not at the moment of each sale.
Does Odoo support click and collect?
Yes. Odoo calls it Click & Collect, set up as a delivery method with the provider set to pick up in store and warehouses assigned as pickup locations. The storefront shows stock availability per pickup location and blocks locations where the item is unavailable, unless continued selling is explicitly enabled.
Can a customer return a web order in my shop?
Architecturally the shared data model supports it, but the documented POS return workflow covers POS orders, and returning a website order in-store typically runs through the Sales app’s return and credit-note process instead. Test this specific flow against your own version before you rely on it.
What stops us overselling between the counter and the website?
One system owning the stock count, with everything else reading from it. Where two systems each hold their own count and reconcile periodically, overselling is a matter of timing rather than a question of whether it will happen.
How much does it cost to add a physical channel to an online store?
In our experience $5,000 to $100,000 (USD) for an Odoo build covering both, driven mostly by how much configuration your own team takes on. Location count, click-and-collect, and fiscal compliance requirements are the items that move it most.
Working out whether your channels actually agree
The four moments above are testable. It takes someone looking at how your current systems handle each one, and what it costs you when they do not.
Talk to us about your online and in-person build →
About the author
Nguyen Tran is the founder of Ministers.io. He has spent five years working on Odoo ERP implementations — five delivered directly and more than twenty advised on — across ecommerce, retail, manufacturing, and maintenance, repair and operations (MRO).
