Counter billing
Fast product search, barcode scanning, quantity and discount entry, customer attachment where you want it, and receipt or GST invoice printing.
A point of sale has one requirement that outranks every feature list: it must keep billing when the internet does not. A queue at a counter does not care about an elegant interface.
Odoo POS runs offline and synchronises when the connection returns, and it reduces the same stock the rest of the ERP reads. This page is about the application; selling in a retail business is covered on Odoo ERP for retail.
Businesses running Odoo with OdooBots
Odoo POS bills at the counter, keeps working offline, and reduces the same stock the rest of Odoo reads. Sessions open and close with a cash count, products are found by search or barcode, payments split across cash, card and digital methods, restaurant mode adds tables, courses and kitchen printing, and every sale consumes stock from the outlet it was sold at.
Session closing is the control that makes a POS trustworthy. If nobody counts the drawer and signs the variance each night, the figures are a record of what the till was told rather than what happened.
Six parts make up the point of sale, and its advantage over a standalone till is everything behind the counter.
Fast product search, barcode scanning, quantity and discount entry, customer attachment where you want it, and receipt or GST invoice printing.
Billing and payment continuing without a connection and synchronising when it returns, which matters more at a counter than any other feature.
Cash, card, UPI and other digital methods on one bill, with split payment, change handling and a per-method breakdown at session close.
Floor plans and tables, course sequencing, order transfer between tables, bill splitting and kitchen or bar ticket printing.
Several outlets and counters under one database, each reducing its own stock, with outlet-wise sales and margin reporting.
A shift opened and closed with a counted drawer, expected versus actual cash, and a variance that is recorded and explained rather than absorbed.
A sale at the counter reduces stock at that outlet, so the replenishment suggestion for tomorrow is based on what actually sold today. The accounting entry posts with the session. If a central kitchen or warehouse supplies the outlet, the transfer is an internal move rather than a sale, so group stock stays correct.
A standalone till records takings. A POS inside an ERP records takings, stock, margin and replenishment from the same transaction.
These are the configuration decisions that are cheap to make now and structural to change once transactions exist. We walk through each one before a single record is migrated.
Printers, scanners, cash drawer, card terminal and the machine running the till, confirmed as compatible before anything is bought.
How long you can run disconnected, what is unavailable, and who re-syncs. Tested deliberately rather than discovered on a busy evening.
When a GST invoice is raised rather than a simple receipt, and how a customer is attached mid-sale without slowing the queue.
Who can discount at the counter and by how much, enforced in configuration rather than negotiated at the till.
Who counts, what variance is acceptable, and who signs it. The control that decides whether the numbers mean anything.
Which location a counter sells from, and how it is replenished from a warehouse or central kitchen.
Clean barcodes and prices before go-live, because a counter is the worst place to discover a missing product.
Odoo moves features between Community and Enterprise from one version to the next, so the list below is what holds today and is confirmed against your own version during the diagnosis rather than taken as permanent.
Community includes the till itself: sessions, offline billing, barcode, payments, discounts, receipts and multi-outlet operation with stock behind it.
Enterprise adds the service and loyalty layers, and the restaurant features are the ones most often worth the charge for a food business.
We would rather say this before you buy licences than after. These are the areas where we scope real development, recommend a bolt-on, or tell you another tool is the better answer.
Offline mode covers an outage, not a day. A site with no reliable connection at all needs its architecture discussed first.
Which card terminals integrate directly depends on the provider and region, and it is confirmed before purchase rather than assumed.
Layered offers, mix-and-match and conditional bundles go beyond standard pricelists and often need development.
Scales usually need the IoT box or a scoped integration, which matters for grocery and food counters.
Royalty calculation and franchisee-level reporting across outlets is a reporting build on top of the data.
Handheld ordering, self-checkout and kiosk flows are separate products connected to Odoo rather than POS features.
Implementing Odoo POS needs more than installing the application. It should reflect how your business already works, and change only what is worth changing.
Understand how many outlets and counters you run, what hardware exists, how reliable the connection is, and whether restaurant features are needed.
Settle the hardware list, offline expectations, invoice rules, discount authority and session closing process before go-live.
Set Odoo POS up around how you work rather than installing it at its defaults, and build only what configuration genuinely cannot reach. See Odoo customization.
Masters, open items and opening balances prepared and loaded. Data cleaning is scoped explicitly, because it is usually the largest single task. See Odoo migration.
Your team runs real transactions in a test database before go-live, including the awkward cases that never appear in a demonstration.
Role-based training for the people who key transactions daily, then cutover, hypercare and ongoing support and AMC.
We do not publish one price, because the same application costs very differently depending on the factors below. We do publish what moves the number, and the price is fixed in writing before work starts.
We test your offline behaviour on purpose before go-live — pull the connection during a mock session and watch what happens. Finding out on a Saturday evening with a queue is the alternative, and it costs more than the test.
Product capabilities stated on this page are documented by Odoo. The configuration advice, edition notes and limitations come from our own implementations.
Tell us how many counters you run and whether you need restaurant features. Those two answers shape the configuration, and the diagnosis call is free.