Odoo POS: The In-Store Point of Sale Module

What Is the Odoo POS Module?

Odoo Point of Sale (POS) is the in-store and in-restaurant terminal application inside the Odoo suite. It is a web app that runs in Chrome, Firefox, or Safari on PCs, tablets, industrial touch terminals, Android, and iOS—so you do not need a proprietary OS image on every lane.

Unlike a standalone POS that syncs to a separate retail system overnight, Odoo POS sits in the same database as Inventory, Accounting, Sales, Loyalty, and eCommerce. Every confirmed order decrements stock, posts payment journals, and can attach a customer record for CRM and loyalty without retail middleware or batch reconciliation jobs.

Beyond the cashier register, the same module supports self-ordering (kiosk or customer phone), preparation displays for kitchen or bar, multi-cashier badge/PIN control, gift cards, eWallets, and franchise-style multi-shop deployments under one company or multi-company setup.

Searchers asking what the Odoo POS module is usually want three answers: it is the terminal UI for physical sales; it is natively integrated ERP retail rather than a bolt-on; and it supports both retail Shop mode and hospitality Restaurant mode from one product family.

• →Web-browser POS — any modern browser device, no dedicated POS OS required
• →Native ERP link — inventory, accounting, CRM, loyalty, and eCommerce share one database
• →Shop and Restaurant modes — retail counter vs floors, tables, courses, and tips
• →Offline continuity — keep selling after the session is open; auto-sync on reconnect
• →Self-order and kiosk — customers order and pay on a dedicated screen or their phone
• →One database, many POS configs — each shop or lane with its own warehouse and cash control

Shop Mode vs. Restaurant Mode

Each POS configuration is set in Point of Sale → Configuration → Settings. You choose Shop mode for retail or Restaurant mode for hospitality. One Odoo database can host both—a flagship store in Shop mode and a cafe in Restaurant mode—each with its own payment methods, receipt header, and warehouse.

Shop mode is built for retail speed: quotations, import of sales orders, Ship Later when stock is not on the shelf, barcode scanning, discount tags, product variants (size/color grids), and parallel orders so a cashier can park one ticket while finishing another.

Restaurant mode is built for table service and bars. The interface exposes navigation among Tables, the register, and open orders. You get floor plans, table occupancy, course-by-course ordering, tips (including tip-oriented hospitality flows), bill splitting across guests or items, and hooks for online delivery partners where configured.

Shared features across both modes include employee management (badges or PINs), preparation displays, self-ordering, loyalty programs, and the same payment-method and hardware stack. Hybrid venues often run two POS configs rather than forcing one mode to do both jobs poorly.

Daily Workflow: Open Session to Accounting Close

Operations people evaluating the Odoo POS module care less about feature lists than about how a shift actually runs. The unit of control is the POS session: open the cash drawer float, sell all day, then close with counted cash so Accounting receives a clean journal entry.

You must be online to open a session. Once the session is live, the frontend can continue through temporary outages (see Offline mode below). Cashiers identify with badge or PIN so discounts, refunds, and cash movements are attributable. Parallel orders let a busy lane park a cart without losing line items.

At close, the session summarizes sales by payment method, cash in/out adjustments, and differences versus expected drawer content. Closing posts revenue, tax, cash, card receivable, and gift-card liability into Odoo Accounting—no CSV export into a separate ledger. Cash payment methods are intentionally not shared across multiple POS configs so drawer control stays clean.

Managers then use POS reporting for sales by hour, cashier, product category, and payment type—enough for most SMEs without a separate BI tool for store-level performance.

1. 01
   Open the session

   Start online, set opening cash float, and confirm payment methods and printer connectivity before peak traffic.

2. 02
   Identify the cashier

   Badge scan or PIN switches employee context so voids, discounts, and cash movements are audit-ready.

3. 03
   Sell and take payment

   Scan or pick products, apply pricelists/loyalty, split tender if needed, print or email receipt, and fire kitchen tickets where preparation displays are enabled.

4. 04
   Handle mid-day cash control

   Record cash in/out (safe drops, paid-outs) so the end-of-day count is not a black box.

5. 05
   Close the session

   Count the drawer, enter actual cash, review payment totals, and close so Accounting receives the session journal entry.

6. 06
   Review reporting

   Check hourly peaks, top SKUs, and discount activity; investigate variances before the next open.

Offline Mode and Automatic Sync

Offline mode is the reliability feature that keeps a dinner rush or Saturday retail peak alive when the ISP fails. After a session is opened online, the cashier frontend can keep processing while product catalog, pricelists, and customer data are available from local browser storage.

Orders and payments made offline are stored locally and synchronized automatically when connectivity returns. Cashiers do not re-key tickets, and inventory, accounting, and reporting catch up as if the outage never happened. Official product pages also note that a POS session can be closed offline without data loss, with offline orders reconciling on reconnect.

Two practical caveats matter for implementation design. First, opening a session requires network access—you cannot cold-start a lane with zero connectivity. Second, card-present offline behavior depends on the payment terminal and provider; cash and many local terminal flows continue, but not every gateway supports the same offline card path. Plan a short offline test with your exact terminal model before go-live.

Odoo’s general offline framework documents multi-gigabyte browser (IndexedDB) reservation for offline use. For multi-lane stores, treat each browser profile as its own local cache and avoid clearing site data mid-session.

• →Open session online, then keep selling through temporary outages
• →Orders stored in the browser and auto-synced on reconnect
• →Session close offline is supported without re-keying
• →Validate card-terminal offline behavior per provider before launch
• →Do not wipe browser storage while a session is open

Payments, Receipts, and Hardware

Payment methods are configured per POS. Out of the box you can combine cash, checks, card terminals, QR code payments, customer account credit, gift cards, and eWallets, and split a single order across multiple methods. Each method maps to accounting journals so the close-session report aligns with the general ledger.

Integrated card terminal documentation covers providers including Adyen, Ingenico, Stripe, Mollie, Mercado Pago, Razorpay, Pine Labs, SIX, Tyro, Viva.com, Worldline, DPO Pay, and QFPay. Stripe and Adyen terminals do not require an Odoo IoT Box; they talk to the POS over the local network once API keys and terminal pairing are set. Availability is country- and currency-specific—confirm the provider’s coverage for your market.

Cash automation machines (Cashdro, Cashmatic, Glory) and peripherals such as receipt printers, customer-facing displays, scales, and electronic shelf labels commonly connect through the Odoo IoT system. Barcode scanners often work as keyboard-wedge USB or Bluetooth devices without IoT. Multi-lane retail typically assigns IoT and payment pairing per lane so one offline printer does not block the store.

Receipts and customer invoices generate from the register. Customize receipt footers for promotions and hours, and use customer displays so totals and line items are visible before card capture—reducing disputes at the counter.

• →Split tender across cash, card, gift card, and customer account on one order
• →Card terminals: Adyen, Stripe, Mollie, Ingenico, Razorpay, Worldline, and more
• →Stripe and Adyen: no IoT Box required; same-network pairing + provider keys
• →IoT path for printers, scales, customer displays, ESL, and cash machines
• →Per-POS cash methods avoid shared-drawer accounting collisions

Loyalty, Self-Ordering, and Preparation Displays

The differentiator versus a thin register is that promotions live in the same Odoo engine as eCommerce. Loyalty programs, coupons, gift cards, and eWallets can be earned and redeemed at the POS with the same rules customers see online. Identify a customer by search, loyalty barcode, or registration at the counter; points can accrue by product, order, or amount, and eWallet balances top up from refunds or explicit loads.

Self-ordering turns a kiosk or the customer’s phone into an ordering surface. In POS settings under Mobile self-order & Kiosk, enable the mode that fits the venue: QR-menu style self-order for tables or takeaway, or a dedicated kiosk flow where customers browse the catalog, place the order, and pay. Orders flow into the same kitchen and inventory path as cashier-entered tickets.

Preparation displays (kitchen/bar tablets) show what to prepare and when, reducing lost tickets between front of house and the line. Restaurant course management and, in newer Odoo 19 hospitality flows, tip-related improvements such as tip splitting between staff keep hospitality operations closer to purpose-built restaurant POS without leaving the ERP.

Pricelists still apply automatically when a customer is identified—VIP, wholesale, staff, eat-in vs takeaway, or time-boxed promotions—so cashiers are not typing percentage discounts from memory.

• →Shared loyalty and gift cards across POS and eCommerce
• →Kiosk and mobile self-order from the same POS configuration family
• →Preparation displays for kitchen and bar ticket flow
• →Customer display mirrors the order for transparency at checkout
• →Pricelists and promotions without manual cashier math

Inventory Awareness and Multi-Shop Deployments

Because Odoo POS is part of the ERP, inventory is native. A sale writes stock movement at order confirmation rather than an end-of-day batch, which is what keeps eCommerce from overselling the last unit already sold at the counter. Restaurants can link menu items to bills of materials so ingredient-level consumption follows the ticket.

Ship Later is the retail pattern for endless aisle: sell an item that is not in the store and create a delivery from the warehouse to the customer without leaving the register. Product availability flags can hide or mark out-of-stock items at a specific POS.

Multi-shop design is one POS configuration per physical location (or lane group), each linked to its shop, warehouse, payment methods, receipt template, and cash control. The product catalog and customer master stay shared. Inter-site replenishment uses standard routes and reordering rules; multi-company setups isolate POS and warehouses per legal entity while still allowing group-level product strategy.

Franchise-style operators can pre-configure store templates and still roll up sales and stock centrally—useful when the alternative is five disconnected registers and a monthly spreadsheet merge.

• →Real-time stock moves at confirmation—not nightly batch only
• →Ship Later creates warehouse delivery from the register
• →One POS config per shop with its own cash and warehouse
• →Shared catalog and customers; optional multi-company isolation
• →Routes and reordering rules for inter-store replenishment

Community vs Enterprise, and When POS Alone Is Not Enough

Odoo’s Community edition includes a capable POS core for basic selling, but several production features operators assume are “just POS” are documented as Enterprise strengths: graphical floor and table management for restaurants, native offline mode, and deeper retail/hospitality packaging. Teams evaluating “free Odoo POS” should map required floor features to edition before promising offline restaurant service on Community alone.

Even on Enterprise, Odoo POS is not a magic replacement for every Toast- or Square-only workflow on day one. Implementation still needs product master quality, tax/fiscal positions, payment terminal certification in your country, printer topology, and staff training. Complexity is the common complaint in independent 2026 reviews: power comes from ERP depth, not from zero-config onboarding.

Choose a standalone lightweight POS when you only need card capture and a simple catalog with no multi-warehouse or accounting integration. Choose Odoo POS when the register is one surface of a broader stack—inventory valuation, purchase, eCommerce, CRM, and financial close in one system. Mid-market multi-location retail and multi-unit hospitality with shared recipes or stock are the sweet spot.

If you already run Odoo for back office, bolting on an external POS reintroduces the sync tax the module was designed to remove. If you have no ERP yet and a single counter, a simple SaaS POS may be faster to open—then reassess when inventory and multi-channel truth become the bottleneck.

The Dynamics 365 Equivalent: Store Commerce

The Microsoft Dynamics 365 analogue is the Store Commerce app—the next-generation POS for Dynamics 365 Commerce. It unifies the older Modern POS (MPOS) and Cloud POS (CPOS, now Store Commerce for web) into a single application available on Windows, Android, and iOS.

Microsoft deprecated MPOS and the Retail hybrid apps in October 2023 and recommends Store Commerce or Store Commerce for web for all new deployments, with existing MPOS customers directed to migrate. Store Commerce supports cash-and-carry, shift management, clienteling, endless-aisle ordering, order fulfillment, inventory, and reporting for first-line store workers.

Two deployment topologies are available. In-app keeps components local, supports a local hardware station, and enables offline mode via a dedicated SQL Server offline database installed with the offline parameter. Hybrid renders Cloud POS from the Commerce Scale Unit and does not support offline. Payments run through the Adyen Payment Gateway with PayPal for order fulfillment, plus a Payments SDK for ISV connectors; Dynamics 365, SVS, and Givex gift cards and digital wallets are supported.

When Each Fits an SME

For an SME choosing between Odoo POS and Dynamics 365 Store Commerce, the decision usually comes down to scale, omnichannel depth, and total cost of ownership rather than raw feature counts.

Odoo POS fits SME retailers, cafes, restaurants, and multi-location operators who want one Odoo instance covering POS, inventory, accounting, loyalty, and eCommerce without separate retail middleware. The POS app ships as part of the Odoo application set; growing chains add terminals and configs without re-architecting a second commerce stack.

Dynamics 365 Commerce Store Commerce fits mid-to-enterprise retail and hospitality chains that need deep omni-channel capability, enterprise compliance, ISV payment connectors, and centralized control from a commerce headquarters. It is the natural path when an Odoo POS prospect outgrows SME retail patterns and needs enterprise-scale channel management.

Because Flectic implements both platforms, we stay platform-neutral on which terminal stack is right for a given operation—the answer depends on transaction volume, number of locations, compliance, and existing Microsoft or Odoo investment.

1. 01
   Start with locations and volume

   One to a handful of stores with shared inventory needs tends to land on Odoo POS; dozens of locations with complex fulfillment and DOM lean toward Store Commerce.

2. 02
   Evaluate integration depth

   If POS, inventory, accounting, and eCommerce in one database is the goal, Odoo POS is usually cleaner. If you need HQ control and ISV payment ecosystems, Store Commerce pulls ahead.

3. 03
   Factor in compliance and payments

   Enterprise gift-card networks (SVS, Givex) and regulated payment paths are mature in Dynamics 365. Odoo POS covers mainstream terminals and cash machines for typical SME retail—validate local providers early.

4. 04
   Plan the implementation as ERP retail

   Scope warehouses, taxes, pricelists, loyalty, hardware, and session procedures before configuring a single terminal. A POS go-live is an operations project, not a device unboxing.

Frequently asked questions