Odoo 13 landed last week, and the part of the release that will matter most to the businesses we work with is not the accounting engine rework or the tidier interface. It is the point of sale. The Odoo 13 point of sale transformation continues a direction the product has been travelling for several versions: treating the till not as a separate retail system that occasionally talks to the back office, but as the transaction edge of the ERP itself. That sounds like a marketing distinction. It is actually an architectural one, and it changes which problems you have.
What the till being inside the ERP actually means
In the conventional retail stack, the point of sale is a specialist product, chosen for its checkout speed and its hardware support, and it writes summarised sales into finance and inventory once or twice a day through an interface. That interface is where the problems live: stock that is accurate at nine in the morning and fictional by four, margins that cannot be seen until the next day, promotions configured twice, and a reconciliation exercise every month that somebody's entire job depends on. When the till writes directly into the same inventory and accounting tables as everything else, those problems disappear and are replaced by a different set. Stock moves as the sale is rung up. The margin on the transaction is known at the moment it happens. A product created once is sellable everywhere. There is no interface to reconcile because there is no interface. The different set of problems is about resilience and specialisation. A specialist till keeps selling when the network dies because it was designed around that assumption. An ERP-embedded till has to be engineered to do so, and the offline behaviour, what is cached, what happens to stock accuracy while disconnected, how sessions reconcile on reconnection, is the single most important thing to test before committing. The current release continues to improve this, and it should still be the first item on your acceptance plan rather than an assumption.
Where this version helps
The recurring theme across the point of sale work in this release is speed and session handling: faster loading, smoother operation on modest hardware, better handling of restaurant workflows such as table and order management, and tighter connections to the inventory and accounting sides. The accounting rework elsewhere in the release also matters here, because the way sale transactions post is cleaner than it was. The honest framing for a buyer is this: if your retail operation is a handful of outlets with a few thousand products, straightforward promotions and a need for stock and margin to be right, this is now a credible primary system rather than a compromise. If you are running high-volume checkout lanes with complex loyalty, queue-busting and deep payment integrations, you are still better served by a specialist product with a good integration, and you should not let a single-vendor argument override that.
| Architecture | Operating benefit described | Acceptance concern |
|---|---|---|
| ERP-embedded checkout | Sales share the inventory and accounting model. | Test offline sessions, reconciliation and workload isolation. |
| Specialist checkout with integration | Retail-specific resilience and specialised checkout capabilities. | Test interface reconciliation, stock latency and duplicated configuration. |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for an Odoo POS Implementation
- Test offline behaviour before anything else. Pull the network cable mid-session, ring twenty transactions, reconnect, and check stock, cash and accounting. Do this in the sales cycle, not after signature.
- Settle payment terminal integration early. This is the most common source of delay and disappointment. Establish exactly which terminals your acquiring bank will allow to be integrated, and design your reconciliation around the honest answer.
- Clean the product data before you go near hardware. Barcodes, units of measure, variants, tax codes, cost. A till exposes every data defect in the catalogue within an hour of opening.
- Design cash control deliberately. Opening floats, cash in and out, voids, refunds, discounts, session close and variance handling, each with an authorisation level. Retail losses are overwhelmingly procedural rather than technical.
- Model pricelists and promotions against your real calendar. Seasonal campaigns, bundles, staff discounts. Build the three most complicated ones you actually ran last year and see if the system expresses them.
- Decide the multi-outlet stock model up front. Per-outlet locations, transfer procedures, who can see and move what. Retrofitting this after go-live is painful.
- Train for the exceptions, not the sale. Cashiers learn to ring items in a morning. What costs money is the return without a receipt, the partial refund, the price override and the failed card that was actually charged.
- Budget for the upgrade cycle. Annual releases are an advantage only if you stay reasonably current. Keep customisation minimal and configuration-led so that moving forward stays a project rather than a rebuild.
The Regional Angle
Three regional realities should shape any retail point of sale decision here, and none of them appear in a product comparison. The first is tax on the receipt. Value added tax has been in force in the Emirates and Saudi Arabia for nearly two years now, and the requirements for what a simplified tax invoice must display, registration number, tax amount, and in the Saudi case the invoice content in Arabic, are not optional formatting preferences. Any till configuration must produce a compliant receipt in the local requirement, correctly handle zero-rated and exempt lines, and retain the transaction records for the statutory period. Tax authorities in both countries have been moving from education toward enforcement, and retail receipts are the most visible, most easily inspected artefact a business produces. Regional practitioners are also watching for the move toward electronic invoicing, which has been signalled clearly enough that no one should be implementing a till today without asking the vendor about its roadmap for it. The second is mall tenancy, which is a far bigger operational factor here than in most markets. A large share of regional retail sits in shopping centres under leases with a turnover rent component, meaning the landlord is contractually entitled to reported sales figures, frequently through a direct data feed or a certified monthly report. Your point of sale is therefore not only a finance system; it is the source of a number your landlord will audit. Configure the reporting so the figures reconcile exactly to what is declared for tax, and establish before go-live how the landlord's feed will be produced. I have seen this discovered in week two of trading more than once. Third, payment and cash. The card acquiring landscape here is bank-led, terminals are usually supplied by the acquiring bank, and integration between those terminals and a non-mainstream point of sale is often unavailable or requires a specific certification. The practical consequence is a terminal sitting beside the till with amounts keyed twice, which reintroduces exactly the reconciliation error the integrated approach was meant to remove. Get the bank's position in writing early. And despite the growth of contactless, cash remains materially more significant in regional retail than in Western Europe, particularly outside the premium malls, so cash control procedures deserve genuine design attention rather than a default configuration. Two smaller points. Trading patterns here are extreme, with late evening peaks, very heavy Ramadan and Eid periods and long mall hours, so performance testing should target your worst hour rather than an average. And cashier turnover is high, which argues strongly for configuration that is simple enough to teach in a morning and permissions tight enough that inexperience cannot become loss.
The objection worth taking seriously
The objection from anyone who has run a retail chain is straightforward: the till is the one system that cannot be down, and an integrated suite makes it a dependent of everything else. When the ERP is being upgraded, the database is under load from a month-end close, or a customisation in accounting misbehaves, the shop floor should not care, and in an integrated architecture it might. Specialist point of sale products exist because retail solved that problem separately for good reason, and the appeal of one vendor and one database is an argument made by finance departments rather than store managers. The second objection is the release cadence. A new major version every year is only a benefit if you move with it, and the organisations that customise heavily find themselves stranded two or three versions back, at which point the single-suite advantage inverts and the upgrade becomes the reimplementation that was supposed to have been avoided. Both objections are fair, and both have practical answers rather than rebuttals. On resilience, the mitigation is architectural and testable: verify offline operation honestly, separate the workload serving shops from the workload serving heavy back-office processing, and never schedule an upgrade against a trading peak. On the cadence, the mitigation is discipline: configure rather than customise, treat any code extension as a liability with an owner, and plan an upgrade rhythm rather than an upgrade event. What tips the balance for mid-market regional retail is the quiet cost of the alternative, which is the reconciliation function, the day-old stock position and the margin that nobody can see until the month closes. That cost is invisible on a vendor comparison sheet and is usually larger than the risks being weighed against it.
Common Questions
Is this suitable for a chain of twenty stores?
Usually yes, if the catalogue is manageable and the promotions are expressible in configuration. Judge it on your peak-hour performance test and your payment integration answer, not on the store count.
What happens to sales made while offline?
They are held locally and synchronised on reconnection. What matters is how your specific configuration handles stock accuracy and session close during that window, which is why the disconnection test belongs in your acceptance criteria.
Should we upgrade an existing deployment to this version for the point of sale improvements alone?
Only with a plan. The accounting changes in this release are substantial, so treat it as a proper upgrade project with a tested copy of your data rather than an in-place update chasing a checkout feature.
What should we expect over the next twelve months?
Expect electronic invoicing requirements in the region to firm up and to become a real selection criterion for retail systems. Expect payment integration to improve as regional acquirers broaden the terminals they will certify. And expect the gap between suite point of sale and specialist point of sale to keep narrowing for mid-market retail, which will make the integration cost of the specialist option harder to justify at this end of the market.
Odoo POS Implementation — we test the offline behaviour before you sign, settle the payment terminal question with your bank, and make sure the receipt satisfies the tax authority and the landlord.