Running Odoo Point of Sale for Retail

The Retail Operations Playbook for Odoo POS

If you already know what Odoo Point of Sale is — the browser-based terminal that posts every sale into Inventory and Accounting — the next question is operational: how do you run a shop on it day in and day out without till variances, oversells, or hardware deadlocks? This guide assumes the module intro and focuses on the mechanics of running retail.

That means the workflows that break or cost money when they are wrong: opening and closing sessions cleanly, controlling cash (including the profit/loss difference entry on close), wiring hardware with known failure modes, deploying multi-store warehouses, configuring loyalty and pricelists per register, surviving an outage, processing returns, shipping or holding stock with Ship Later, and reading the day at close. Each is a documented Odoo workflow with a right sequence.

Everything here is grounded in Odoo's official Point of Sale documentation (v19 path) and pricing. Where a step depends on another app — Inventory for barcodes and routes, Accounting for posting, IoT for hardware, eCommerce for shared stock — we name the dependency so you sequence setup before launch day, not at the counter.

Setting Up a POS for a Retail Store

A POS in Odoo is a configuration record, not a device. Create one per selling context — one per store, or per register within a store — and open it as a session when trade begins. Start at Point of Sale → Configuration → Settings and select your POS from the dropdown. Per Odoo's configuration documentation, these settings are only editable by users whose access rights are set to Settings, so plan the admin role before you configure.

Two setup steps are easy to miss. First, products are not available at the register until you explicitly opt them in: open a product, Sales tab, enable 'Available in POS'. The system loads a limited product set for a fast session open, so use 'Search more' if a SKU is missing at the counter. Second, organize the register with PoS Product Categories (Configuration → PoS Product Categories). Set a Start Category to open on, and use Restrict Categories to limit departments on a given register — useful for a dedicated electronics or pharmacy counter and for keeping the grid small enough that cashiers do not hunt during peak.

Payment methods are configured separately and attached to the POS. Each method maps to a journal (cash, bank, or a card terminal), and the methods you enable here are exactly the buttons a cashier sees at checkout. Get this list right before go-live: adding or renaming a payment method mid-day splits your reconciliation reporting. Map gift cards, customer account (credit), and each card provider to distinct journals so the closing control screen groups cleanly.

Session Management: Opening, Cashiers, and the Daily Close

The session is the atomic unit of retail accounting in Odoo POS. From the dashboard click New Session, confirm the Opening Cash Control balance, and Open Session to start selling. A session can only be open once on the same browser, but per Odoo's documentation multiple employees can be logged into the same session simultaneously — so one register can serve several cashiers across a shift.

Cashier identity matters for security and analytics. Enable 'Multi Employees per Session' in the PoS Interface settings so each staff member logs in with a PIN or scanned badge before they transact. Odoo splits access into two tiers: basic rights cover selling, refunds, setting customers, applying pricelists and discounts, and viewing order history; advanced rights add cash-in/cash-out, backend access, and closing the session. Leave basic rights empty and every employee can log in — rarely what you want at a till.

Cash handling during the session uses Cash In/Out entries (menu icon → Cash In/Out), each recording an amount and a reason so float top-ups and petty-cash withdrawals are auditable. At end of day, Close Session opens Closing Control: order count, totals taken, and expected amount by payment method. Count the drawer with the built-in calculator (coins and bills into the Counted column). Any difference is flagged before you post. Closing the session is what posts the day's sales to accounting — a clean close is what makes books match the till.

When counted cash does not match expected, accepting the difference creates a journal entry typically labeled for the POS closing difference (profit if over, loss if under). That entry is mandatory for the books to balance; investigate patterns later in the orders pivot and cashier reports rather than forcing the count to match. Odoo strongly advises closing the POS session at the end of each day — leaving sessions open across days blurs per-day analytics and complicates shrinkage review.

Multi-Store and Multi-Location Deployment

Multi-store in Odoo POS means one configuration per store, each linked to its own shop and warehouse, all hosted in a single Odoo database. Because every sale decrements stock in the linked warehouse, the per-store linkage keeps on-hand counts honest: ring a sale at Store A and Store A's bin loses the unit, not Store B's. Head office sees one real-time picture rather than nightly exports.

Practical setup: create a POS configuration per location, point its warehouse at the correct stock location, and assign payment journals and pricelists for that market. Inter-store replenishment uses standard Inventory routes and reordering rules — there is no separate retail transfer module — so a short warehouse can pull from a sister store through the same procurement logic used elsewhere in the system.

Pricing and loyalty scale the same way: attach store-appropriate pricelists to each POS (regional promotions, outlet markdowns, VIP lists) while keeping one product master. Loyalty programs live in the shared customer database, so points earned at Store A redeem at Store B when the same customer is set on the order — configure program scope deliberately if a franchise needs isolation. Analytic tags or company-level cost centers keep multi-location P&L readable without spreadsheet merges.

When each store is a different legal entity, you enter multi-company territory. Per Odoo's pricing FAQ and plan model, multi-company on a single database is a Custom-plan concern (installing companies or Studio shifts you there), and each company can keep its own POS configurations, warehouses, and chart of accounts while still consolidating operational reporting where useful.

• →One POS configuration per store, each tied to its own warehouse so stock decrements at the right location
• →Per-store pricelists and payment methods; shared product master and customer loyalty balance
• →Inter-store replenishment reuses standard Inventory routes and reordering rules — no extra retail module
• →Multi-company retail groups need the Custom plan path; each company keeps its own POS, warehouse, and ledger

Pricing, Pricelists, and Discounts at the Register

Pricing flexibility at the till is configured once and reused. In POS settings under Pricing, enable Flexible Pricelists. Odoo offers two modes that apply database-wide: 'Multiple prices per product' (fixed prices per product, optionally gated by minimum quantity or date window) and 'Advanced price rules' (percentage discounts, mark-ups, and formulas on top of fixed prices). The mode you pick also governs Sales and eCommerce, so choose for the whole commercial model, not only the shop.

Advanced rules compute a price from the sales price, cost, or another pricelist; layer a discount or mark-up; add a fixed fee; and enforce rounding so a result lands cleanly — for example, rounding to a multiple of 1.00 with a -0.01 fee forces prices to end in .99. Scope a rule to all products, a category, a product, or a variant, and bound it by minimum quantity and validity dates for promotions.

At the register, cashiers pick an available pricelist with the pricelist button (multiple must be enabled for the button to appear), and a customer's default pricelist applies automatically once that customer is set. Cashiers can still apply manual discounts and price overrides from the numpad where policy allows; fiscal positions handle tax mapping; cash rounding keeps tender exact when the currency no longer mints the smallest coin. For multi-store groups, restrict which pricelists each POS can offer so an outlet register never accidentally sells head-office list prices.

Loyalty Programs and Rewards at the POS

Loyalty turns a one-time buyer into a returning one, and Odoo POS runs it without a third-party plugin. Per Odoo's loyalty documentation, activate Loyalty Program under Pricing features of your POS settings, then design the program: reward type (discount or free gift), product scope, and earn/redeem rules.

The mechanism is customer-attached. A customer must be set on the order for points to accrue; the cashier sees points the transaction will earn and the running balance. Points accumulate until a reward threshold is met; the Rewards button spends them and updates the price instantly. Accurate customer capture at the register is the discipline: no customer record, no loyalty history.

Gift cards and eWallets sit in the same commercial toolkit (Sales / products & prices loyalty stack). Sell a gift card at the register against a dedicated payment or product setup, and redeem it on a later POS order or — when eCommerce shares the database — online, without a separate loyalty SaaS. Coupons issued from marketing campaigns can also apply at checkout when the rule engine is shared. Setting the customer early still unlocks the full set: default pricelist, points, gift-card balance, and printable invoice from one attachment.

Hardware, the IoT Box, and Payment Terminals

The register is only as reliable as the hardware behind it. Odoo connects peripherals through an IoT system: install Point of Sale and Internet of Things, set up an IoT Box (or Windows virtual IoT), and connect devices — receipt printers, cash drawer (RJ25 to the printer), barcode scanner (scans must end with ENTER), scale, and customer display. In POS settings under Connected Devices, enable IoT Box and select devices for that register. Odoo publishes supported hardware lists so you buy against a known-compatible set.

Receipt printing: ePOS printers (networked ESC/POS) can connect directly; for secure HTTPS or self-signed certificate setups follow the dedicated docs so the browser does not silently block printing. ePOS printers on the same local network as the POS can print without the device sitting next to the till. Label printers (ZPL Zebra class such as ZD410/ZD420) need an IoT Box; printing starts automatically for supported Zebra models. Electronic shelf labels are a first-class hardware path in current docs when you want price changes to push to the floor without paper.

Card payments integrate through payment terminals rather than only the IoT box. Per Odoo's payment terminals documentation, enable the provider module and configure it — native integrations include Adyen, Ingenico, Mercado Pago, Razorpay, SIX, Stripe, Vantiv, Viva Wallet, and Worldline. The terminal becomes a payment button: send amount, wait for 'Payment Successful'. If the connection drops mid-transaction, 'Force Done' (available after an error) lets the cashier validate the order so the queue keeps moving — use only when the terminal already captured payment, then reconcile against the provider settlement report.

Failure modes to train before Black Friday: printer certificate or LAN drop (no receipt — fix network/HTTPS before blaming Odoo); scanner not sending ENTER (SKU never lands in cart); drawer not cabled to printer (cash sales still post but drawer stays shut); shared IoT Box mis-assigned after v13 multi-POS device selection (wrong printer for the lane); terminal timeout without Force Done discipline (ghost payment or unpaid order). One IoT Box can serve multiple Points of Sale via device assignment (with exceptions such as some Ingenico setups); payment terminal combinations Odoo documents include Adyen–Adyen, Adyen–Ingenico, Adyen–SIX, Ingenico–Ingenico, and Ingenico–SIX, and the same Adyen or Ingenico unit can serve more than one POS when configured correctly.

Offline Mode: Keep Selling, Then Reconcile

Odoo POS is engineered to keep working through temporary network outages. Official product and documentation copy states the app runs on any device with a web browser and continues processing transactions when temporarily offline — the cashier frontend persists orders locally and syncs them to the Odoo server automatically when connectivity returns, without re-keying. For a shop, that is the difference between a five-minute ISP blip being invisible and a stopped line.

Operationally, offline mode covers the core retail loop: adding products, applying prices and discounts, taking cash, and closing orders. What it does not cover is anything that requires a live round-trip — real-time stock reservations across stores, server-side payment-terminal authorization in many setups, or fetching a customer record that was not already loaded. Pre-load while online: open the session so product data and customer lists cache locally; treat card payments as best-effort during an outage and prefer cash or already-paired local terminal behavior when your provider supports it.

Reconciliation is automatic but worth verifying. When the connection restores, queued orders sync and post to inventory and accounting as if they had been online. Still close and reconcile the session properly at end of day so offline-captured cash is confirmed against the counted drawer before books post. If a long outage leaves a large local queue, keep that browser tab open until sync completes — clearing browser storage mid-outage is how offline orders disappear.

Inventory Sync, Barcodes, Serial Numbers, and Returns

Every validated POS sale decrements stock in the linked warehouse — that native sync is the main reason to run POS inside an ERP rather than bolted on. Real-time deduction also protects eCommerce on the same database: a unit sold at the till is no longer available online without a middleware lag. Enable barcodes in Inventory settings (Barcode section) and assign a barcode on each product's General Information tab. Scanning adds the product to the cart; scanning again adjusts quantity. The same scanner can log employees when multi-employee mode restricts access.

Discount tags are special barcodes that apply a percentage reduction (useful for near-expiry grocery or markdowns). Odoo's default discount nomenclature uses a pattern such as 22{NN} — scan the product, then the discount tag, and the reduction applies to the last product in the cart. Adjust the pattern in POS settings Inventory → Barcode Nomenclature when you need three-digit discounts (for example 100%).

For traceable goods, track by unique serial number or by lot on the product Inventory tab. When a tracked item is added, the POS prompts to type or scan the serial or lot; you can import them from a linked sales order. Lot and serial numbers are required on tracked products but not enforced to block the sale — train cashiers if traceability is compliance-critical.

Returns and refunds: from an open session, click Refund, select the original order, choose items and quantities, then process the refund as a payment. Odoo generates a credit note referencing the original receipt or invoice, partially or fully canceling it — refunds stay tied to the source sale rather than anonymous negatives. You can also refund by setting a negative quantity on the returned product in an open session when process allows.

Omnichannel: eCommerce Stock, Ship Later, and In-Store Pickup Patterns

When POS, Inventory, and eCommerce share one Odoo database, every validated POS sale writes a stock move at confirmation — not an end-of-day batch. That is the structural fix for overselling: the same on-hand figure feeds the web store and every register warehouse. Multi-store still depends on each POS pointing at the correct warehouse so online pickup and in-store stock are not confused.

Ship Later is the official shop feature for sell-now, deliver-or-hold-later. In POS settings under Inventory, enable Allow Ship Later. Optionally choose the shipping Warehouse, a Specific route (or default), and Shipping Policy — As soon as possible to ship lines as they are ready, or When all products are ready for a single shipment. At payment, set a customer (with an address), select Ship Later, confirm a shipping date, and complete payment; Odoo creates a delivery order from the warehouse to the shipping address immediately.

Retailers use the same pattern for bulky goods, special-order fulfillment, and 'pay in store, deliver later' without leaving the POS. For click-and-collect style flows, many teams pay online or reserve stock via Sales/eCommerce routes into the store warehouse, then complete or pick at the register against the customer and sales order tools (quotations and sales orders can be settled or partially settled at POS with down payments). Sequence it deliberately: reserve or route stock so the register cannot double-sell the last unit while a web order is open.

Shared loyalty and gift cards across channels only work when the customer is identified. Train associates to set the customer before payment on any omnichannel order so points, gift-card redemptions, and history stay consistent whether the journey started online or at the till.

• →Real-time POS stock moves protect eCommerce availability on the same database
• →Allow Ship Later: customer + address + date → delivery order created at payment
• →Shipping Policy and warehouse/route settings control partial vs complete ship
• →Settle sales orders / down payments at POS when the journey started in Sales or eCommerce

Peak-Hour Performance and Reliability Tips

Peak retail is where weak configuration shows up as queues. Keep the POS product grid lean: use Restrict Categories and a sensible Start Category so cashiers never scroll a thousand SKUs; rely on barcode scanning for long-tail items and 'Search more' only as fallback. Prefer barcode-first workflows over touch-grid browsing when volume spikes.

Hardware and network: open sessions while online so catalogs and customers cache before the rush; keep the POS and printers on a stable LAN (ePOS local-network printing avoids depending on the public internet for receipts). Test payment terminals on the same day-part as your peak — authorization latency that is fine at 10:00 can stall a lunch queue. Document the Force Done rule so staff do not invent workarounds mid-line.

People and process: assign advanced close rights to supervisors only so a junior cashier cannot post an unfinished day; use multi-employee login so refunds and discounts attribute correctly under pressure. Close sessions daily even on peak days — multi-day open sessions make it harder to isolate which shift produced a variance. Review the Orders pivot by hour and employee the next morning to rebalance staffing, not only to audit cash.

Scale path: self-ordering (kiosk or customer mobile) is a documented POS extra that takes entry off the primary till for simple SKUs or food-adjacent retail; preparation displays and customer-facing screens reduce 'what did I order?' disputes. Odoo 19's POS UX work (including easier presets for order types such as takeaway vs in-store modes in mixed environments, and dark mode) is worth evaluating on a pilot register before a multi-store push so cashiers learn one flow under load.

Reporting and Analytics for Retail Operations

Odoo turns each closed session into a structured report. Once a session is closed and posted, the session report shows who opened the session, which employee handled each order, order references and receipt numbers, customers, and totals paid — the detail a store manager needs to audit a day. Reach it from the POS card (Sessions under View, then open a session and use the Orders smart button), or browse all sessions under Point of Sale → Orders → Sessions.

Above the session level, Point of Sale → Reporting → Orders gives graph and pivot views you can filter and group — by store, employee, product, day, or hour — to answer operational questions: which register is busiest, which cashier refunds most, which SKUs move when. Because the data is the same record operations and finance use, there is no separate retail reporting database to license or reconcile.

For multi-store groups, consolidation across shops makes analytics strategic: compare locations on like-for-like data without spreadsheet merges. Pair the orders pivot with inventory and accounting reports (including cash-difference gain/loss from closing control) for a closed loop from till to ledger. After peak days, sort by hour first — staffing and hardware bottlenecks show up as time-of-day shape, not only as total sales.

Odoo POS Pricing and Rolling It Out

Odoo POS is included on every Odoo plan — it is not a separately licensed retail module. On the One App Free plan you can run POS alone for unlimited users at no software fee, which makes a single-store pilot low risk. On paid plans, POS is bundled with the rest of the apps for one per-user fee on Standard and Custom. Odoo's pricing page notes introductory discounts that apply for 12 months on initial users, so budget the ongoing rate after the intro window, not only the first-year number. Regional list prices move; always confirm on odoo.com/pricing for your country rather than a blog table.

Plan choice matters more for retail groups than for single stores. Multi-company on one database, Studio customization, and external API-driven integrations push you toward Custom. A single-store independent can run indefinitely on One App Free or Standard; a multi-entity group usually lands on Custom. Portal customers and eCommerce shoppers are not paying users — only backend users who create or edit documents count.

For the full sourced breakdown of plans, Odoo.sh hosting, and implementation cost, use our Odoo pricing guide rather than this summary. Whatever plan you choose, sequence rollout as configure → connect and test hardware → pilot one register through a full open/close cycle → scale store by store, so cash control and reconciliation are proven before volume hits.

Frequently asked questions