An Odoo POS rollout needs to prove a complete trading day: opening the register, taking payment, handling an exception, issuing a receipt and explaining the closing balance. A successful sale in a demonstration does not establish that your actual cashier, terminal, printer and network work together.
This checklist is for a supervised pilot using a small, representative product selection. Product references were checked on 10 November 2026 against Odoo 19 documentation; match them to your installed release and enabled features.
1. Define one checkout to test
Record the shop, register, cashier role, payment methods and devices included. Give each test an owner and expected result. Use provider test environments where available; any live payment trial needs an agreed amount, responsible person and reconciliation process.
Include a barcode product, a manually selected product, a discount and a return. Add weighed goods, variants or customer-specific pricing only when they are part of your real operation. The aim is to expose the decisions a cashier must make, rather than create the largest possible test catalogue.
2. Check the actual hardware combination
Write down the model, connection type, browser and network arrangement for every device. Odoo’s hardware documentation describes different connection paths, including direct printer connections and IoT systems. A device category being supported does not establish compatibility for every model.
The Odoo 19 receipt-printer guide distinguishes supported ePOS and ESC/POS configurations, with some connections requiring IoT. Confirm the exact model and interface before purchase or rollout. Test at the intended counter, including a paper change and a temporary printer interruption.
| Test | What to verify | Who signs off |
|---|---|---|
| Cash checkout | Item, total, tender, change and drawer behaviour agree | Cashier and supervisor |
| Card checkout | POS outcome matches the terminal and provider record | Payments owner |
| Refund | Correct item, quantity, amount and approved refund method | Store manager |
| Receipt | Readable output, correct reference and successful reprint | Operations owner |
| Daily close | Counted cash and each non-cash method reconcile separately | Supervisor and finance |
3. Test payment failures as well as approvals
For integrated terminals, Odoo requires provider-specific configuration and validates a successful payment in the POS. Follow the applicable payment-terminal instructions; provider, device and regional availability must be checked for your setup.
Run an approval, a decline, a cancellation and an interrupted connection in the supported test arrangement. Record what the cashier sees and how the supervisor determines the actual outcome. If the terminal appears paid but the POS appears incomplete, reconcile the provider record before retrying. A second attempt could otherwise create a second charge.
For a separate, non-integrated card machine, test the manual handoff explicitly. Selecting a card payment method in a register is not evidence that a provider approved or settled a transaction.
4. Validate refunds and receipts
Test a partial return against an original order and check the amount and selected refund method. Odoo’s POS workflow guide documents order-based refunds. Your acceptance test should also establish who can authorise the action and how staff handle a receipt they cannot locate.
Inspect printed and reprinted receipts for the company details, order reference, items, discounts and payment information your operation needs. Odoo provides receipt configuration and reprinting controls in its receipt guide. Confirm any required invoice or receipt content with the person responsible for local accounting requirements.
5. Rehearse an internet outage carefully
Odoo 19 POS can retain offline orders in the browser and synchronise them after connectivity returns, but backend-dependent functions are limited and integrated payment terminals require internet access. Its offline POS guidance warns against closing or reloading the browser, or clearing its cache, before pending orders synchronise.
Use an isolated trial to distinguish an internet outage from a failure of the local network. Reconnect and confirm each test order appears once in the backend. Write a short cashier procedure describing permitted actions, unavailable payments and who decides whether trading must pause. Do not rely on an improvised browser reset during an outage.
6. Prove the closing arithmetic
Fictional example: a shop opens with 100 currency units, takes 240 in cash sales, pays 20 in cash refunds and records a 30 cash removal. Expected drawer cash is 290. A separate 180 in card sales is checked against payment-provider records; it is not added to the cash drawer.
If the count is 285, investigate the five-unit difference rather than copying the expected figure. Odoo’s closing workflow shows expected totals by payment method and provides controls for discrepancies. Review those settings with the supervisor before launch.
Release only after the team can explain every test payment and close without unexplained differences. Keep the device list, test results and first-day contact together. Use the support incident checklist to prepare the first-day escalation details. Explore our retail workflows and Odoo services, or send your POS requirements with the intended devices and payment provider.