Odoo 20 POS Offline: Selling Through an Internet Outage

The internet drops at 12:15 on a Friday. The card terminal spins, the dashboard freezes — and nine people in line still want lunch. This is the moment Odoo's POS offline mode is built for. In Odoo 20, a register that was open and loaded when the connection failed does not stop selling: it keeps creating and managing orders locally, stores them, and synchronises everything to the backend when the connection returns.

But offline selling has sharp edges. Payment terminals stop working. Invoices wait. Stock figures go stale. And one careless browser refresh can put unsynced orders at risk. This article explains what the documentation actually promises, where the limits are, and how to prepare so an outage is an inconvenience rather than a write-off.

First, a distinction: two different offline modes

Odoo 20 talks about offline in two places, and confusing them leads to bad expectations.

POS offline mode is specific to the Point of Sale app. It keeps order creation and order management functional during an outage, using data cached in the browser. This is the mode this article is about.
The general offline mode covers the rest of Odoo. The Odoo 20 release notes expand it significantly: users can create, edit, archive, unarchive and delete records while offline, and execute searches they previously ran, with changes syncing when they are back online — pitched at warehouse floors, construction sites and field technicians with unreliable coverage.

The POS workflow documentation is explicit: POS offline mode refers only to Point of Sale-specific functionality, and a separate feature covers the rest of Odoo. A warehouse tablet offline in the back office and a till offline at the counter are related ideas with different mechanics — and different limits.

How POS offline mode works

The mechanism is cache-based, and starts before anything goes wrong. When a POS session starts, essential data — products and customers, in the documentation's examples — is loaded into the browser cache, so it remains accessible if the connection later fails.

From there, an outage plays out like this:

The connection drops and the POS switches to offline mode. An offline mode icon appears in the POS interface header so staff can see the state at a glance.
Cashiers keep working. Orders are created and managed against the cached products and customers, exactly as they were rung up.
Orders created offline are stored in the browser cache, not on the server — they do not exist in the backend yet.
When the connection is restored, the stored orders are synced to the backend automatically, and anything deferred during the outage catches up.

One consequence follows directly: offline capability is prepared at session start. The register builds its safety net when it opens. A till that was open and loaded before the outage is covered; the cache is its world until the network returns — which is why the preparation steps below matter.

What keeps working offline

Order creation and management. The core promise: selling does not stop. Staff build orders from the cached catalogue through the normal register flow.
The cached catalogue and customer list. Products and customers loaded at session start — plus data added to the cache as they are used during the session — remain available for lookup and sale.
Local-network devices. Devices on the local network, such as printers and scales, continue to work offline, as long as no changes are made to the local network. Receipts still print; weighed items still weigh.
Deferred invoicing. An invoice request is not lost: invoices requested while offline are generated automatically after the connection is restored.

What does not work offline — read this list twice

The documentation is unusually candid about the limits. Many POS features rely on backend information and are therefore not available offline:

Generating invoices immediately. As above, they are queued for when the connection returns — the customer cannot walk away with a backend-generated invoice during the outage.
Registering customers. New customers cannot be registered offline. If the person at the till is not in the cached data, the sale proceeds without a new record.
Accessing detailed product information. The cache holds what the register needs to sell, not the full backend product record.
Synchronising stock in real time. Quantities do not update across registers or against the warehouse while offline. Two tills selling the same item both work from the snapshot they loaded — overselling a nearly-out item is a real risk in a long outage.
Using payment terminals. Connected payment terminals rely on an active internet connection and do not work offline. This is the limit that bites hardest, and it is covered separately below.
Loading data on demand. Anything not cached — a product never loaded, a customer outside the loaded set — cannot be fetched until the connection returns.

When a cashier tries a feature that is unavailable offline, a popover appears with the message “Connection Lost”. To keep selling without that feature, the cashier clicks Continue with limited functionality — a small interaction worth training in advance.

The payment problem, stated plainly

Offline mode saves the sale, not the card payment. The documentation is blunt: connected payment terminals rely on an active internet connection and do not work offline.

For a store, that means an outage plan is mostly a payment plan:

Cash keeps the line moving. Order creation and cash handling are local activities; the order is stored and synced later. Float and change discipline matter more during an outage, not less.
Card customers need a policy, decided in advance. Asking them to wait, using a backup payment route arranged outside Odoo, or declining card sales until service returns are all operational choices — but the choice must be made before the outage, not improvised under pressure. Do not assume a terminal will “store and forward” payments through Odoo POS offline mode: per the documentation, it simply does not work offline.
Do not fake it in the register. Recording a card payment that never happened, to be “fixed later”, corrupts the session close. If a payment did not happen through a working method, it does not belong on the order.

The one rule that protects your orders

Because offline orders live in the browser cache until they sync, the documentation carries an explicit warning, and it deserves to be treated as store policy:

Do not close or reload the browser while offline orders are unsynced.
Do not clear the browser cache until the POS is back online and synced with the backend.

Put together, the offline till is a single point of fragility: that browser, on that machine, holding those orders. Staff should know not to “fix” a till by restarting the browser mid-outage, and nobody should run a cache-cleaning tool on a POS terminal as a troubleshooting step. When the connection returns, verify the sync completed — orders visible in the backend — before closing anything.

Preparing before the outage: load more, lose less

The amount of data available offline is configurable. Each time a customer or product is used, new data is added to the cache alongside what was loaded at session start — but if outages are frequent, the documentation recommends increasing the amount loaded at the start of the session, so everything necessary remains available offline.

Two system parameters control this, adjusted with developer mode activated:

point_of_sale.limited_customer_count — the number of customers loaded into the POS. Customers with the highest order counts are loaded first, up to the specified value.
point_of_sale.limited_product_count — the number of products loaded into the POS. Favourite products are loaded first, followed by services, then the most recently updated products, up to the specified value.

The trade-off is stated in the documentation too: more initialised data also increases the time required to open the register. A small café menu should load everything; a large catalogue store should load generously but accept a slower open, and recognise that a product outside the loaded set cannot be sold by lookup during an outage.

An outage playbook for Odoo 20 POS stores

Before anything happens: raise the cached customer and product limits to match your realistic selling set, test the register's open time, and brief staff on the offline icon and the Connection Lost popover.
When the connection drops: check for the offline icon, keep the browser open, switch card customers to your pre-decided payment policy, and keep selling — receipts still print locally.
During a long outage: watch near-out stock items, since real-time synchronisation is paused; avoid registering new customers or promising backend invoices on the spot.
When service returns: let the stored orders sync, confirm they appear in the backend, confirm requested invoices have been generated, and only then close or restart anything.
Afterwards: review what sold offline against physical stock, because the outage window is exactly where counts drift.

Odoo 20's POS offline mode will not make an outage invisible — the payment-terminal limit alone prevents that. What it does is narrower and more valuable: it keeps the register selling, keeps orders safe in the cache, and hands everything to the backend when the line comes back. Stores that prepare the cache, protect the browser and plan payments in advance will barely remember the outage.