Why Odoo for restaurants and retail stores starts with the point of sale
Odoo Point of Sale covers front-of-house sales for restaurants, food trucks and retail shops: taking orders, tendering payments, handling returns and attaching customers to a sale. The build depends on how Odoo connects POS, inventory and accounting, because each sale touches stock levels, tax and the ledger at the same moment. Before any terminal is configured, decide which events move stock, which post journal entries, and whether those postings happen per sale, per session or per day. Those choices shape your reports, your reconciliations and what staff must do at close of day. Write them down before the first floor plan is drawn.
For staff, the change is mostly in the sequence of work. A server or cashier keys an order on a terminal that already knows the table layout, menu items, modifiers and the printer each item should go to. In a restaurant, the kitchen printer or display receives the order when it is fired, so the kitchen no longer depends on a handwritten ticket. In a shop, the same sale can reduce stock for the item sold and record a loyalty point if that program is enabled. Training should focus on exceptions: voids after an order is sent, split bills, refunds and payments taken while offline. Those are the cases where an unclear workflow shows up first.
For owners and managers, the change is in visibility. Sales, stock and cost data can come from the same transactions, so month-end rekeying should shrink. That only holds if menu items, product variants and units of measure are set up consistently across locations, and if each location's accounting is mapped correctly from the start. Ask the implementer which reports you need on day one, such as sales by shift, waste or stock by location, and confirm they can be produced from the configuration you plan without a spreadsheet step. Multi-store operators should also confirm how stock transfers between locations will be recorded and approved.
Treat the Bakery and Food Truck packages as starting points that must be configured for your business, and budget that configuration as project work. A package may bring sample products, categories, a POS layout or accounting defaults, but your menu, tax rules, prep flows, payment methods and location structure still need to be set and tested. Confirm with the implementer exactly what each package contains in the Odoo version you will run, since package contents can change between releases. Also confirm the plan: multi-company, Odoo Studio and external API access are listed only on Odoo's Custom plan, and Odoo.sh or on-premise hosting also requires Custom.
What restaurant and retail operations require from the build
This table maps each operational requirement for restaurant and retail Point of Sale to its source and to the configuration and testing work it creates. Read it as a checklist for scoping: each row names who sets the rule, so you can confirm it with the right party before the build starts. The main takeaway is that most of the risk sits in rules you do not control, such as fiscal authority and payment provider requirements.
| Requirement | Source | What it means for the build |
|---|---|---|
| Table service with floor plans | The operator's own operating rules for seating, sections and servers | Floor plans, table layouts and server assignments must match the real room. Test table transfers, merged bills and split checks at peak service. |
| Kitchen order printing | The operator's own operating rules for kitchen stations and routing | Map each product to the right kitchen printer or display. Test course firing, order changes and voids so tickets reach the correct station. |
| Payment terminals | The payment provider | Confirm which terminal models and connection methods your provider supports with Odoo's Point of Sale. Test approvals, declines, refunds and offline behavior on the actual hardware. |
| Loyalty programs | The operator's own operating rules for rewards and member data | Define points, rewards and eligibility rules before configuring them. Test how loyalty interacts with discounts, returns and promotions, and confirm where member data is stored. |
| Multi-store stock visibility | The operator's own operating rules for warehouses and transfers | Set up warehouses and stock locations per store and confirm which stock levels each till can see. Test inter-store transfers and stock counts across all locations. |
| Country POS certification | The local tax or fiscal authority | Confirm which fiscal localization, receipt format and certification steps apply in your country, and whether the authority requires certified hardware or software. Ask for written confirmation before configuring receipts or tax rules. |
| Daily close and reconciliation | The payment provider and the local tax or fiscal authority | Define the end-of-day steps, cash counts and payment settlement matching. Test that totals from tills, terminals and the accounting records agree after a full trading day. |
Choosing Odoo Community, Enterprise or the Custom plan for a store group
For a multi-location restaurant or retail group, the first decision is not which Point of Sale screens to use but which Odoo edition and hosting plan can carry the whole business. Odoo offers a Community edition and a paid Enterprise edition, and the two differ in features and support. The Community edition on GitHub is licensed under LGPL-3.0, so its source is public and can be inspected and modified under that license. The Enterprise source code is not publicly available and requires a subscription or partner access, which matters if your team expects to read or change the code directly.
Plan choice is a separate question from edition, and for a store group it often decides the outcome. Odoo's pricing page lists three plans: One App Free, Standard and Custom. The One App Free and Standard plans are Odoo Online only. According to the same pricing page, only the Custom plan can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. If you plan to run stores under separate legal entities, host the system in your own cloud account, connect a payment, loyalty or delivery service through the API, or add store-specific fields and logic, those requirements point to the Custom plan before any app is selected.
Write the requirements list before you talk to Odoo about pricing. Include the number of legal entities and whether stores share one stock ledger, where the database must be hosted for your data handling rules, which integrations need external API access, and which custom changes you expect to maintain for years. Then map each item to the edition and plan that include it. Per-user monthly prices and the yearly discount on the pricing page are only part of the total, so compare plans against this list rather than the headline price.
Confirm the point-of-sale and industry features in writing. Floor plans, kitchen printing, payment terminal integrations, loyalty programs, multi-store stock and the country POS certifications and Bakery or Food Truck packages do not all sit in the same place across editions and plans. Ask Odoo, in writing, which of these your chosen edition and plan include, which are Enterprise only, and which depend on a particular country localization. Ask for the exact app names and version you will run, and keep the answers with the scope document so the decision can be checked later.
Plan for support windows before you sign. Odoo's standard support covers the first three years after a major release, including security updates and bug fixes, and security patches are only provided during standard support. Extended support after that is limited to Odoo.sh for select versions and on-premise, and SaaS versions cannot use it. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years. Ask which version you would start on, its standard support end date, and what an upgrade costs and requires in your chosen plan, because a store group that cannot upgrade on schedule ends up with an unsupported point-of-sale system.
Which POS, stock and integration settings matter in restaurants and shops
Restaurants and shops configure Odoo Point of Sale in a few areas that decide whether service, stock and month-end close work from the first day. Each card names the decision the team must make and the data that decision depends on. Settle that data early, because floor plans, menus, stock locations and tax codes all feed the same sales records.
Floor plans and kitchen routing
Floor plans define the tables, rooms and zones that servers work from, and kitchen printing routes decide which order tickets reach each station, such as grill, bar or pass. The decision is how many floors, zones and printers you need and which products belong to which station. The data you need is a table inventory for each room, a product-to-station mapping, and the printer or network address for each station. Test every route with a live order before opening, and confirm the printing options available in your target version.
Payment terminals and staff sign-in
Payment terminal setup connects each till to the card hardware and payment provider your business uses, and it decides who may take payment at which terminal. Confirm which terminal and payment integrations your target Odoo version supports before you choose hardware. For staff sign-in, Odoo documents LDAP with optional user creation on first login from a template, Google Sign-In, Microsoft Azure OAuth and two-factor authentication. Confirm which of these methods apply to POS terminal setup in your target version, and map each role to the terminals it may use.
Loyalty and promotions
Loyalty programs and promotions change the price a customer pays at the till, so they must be designed before the menu or catalog is loaded. Decide which purchases earn points, whether promotions can stack, and whether a rule applies to one store or across the chain. The data you need includes existing customer records, agreed discount rules and the product categories each rule covers. Test each rule against sample baskets, including refunds and returns, and confirm which loyalty and promotion features your chosen plan includes.
Multi-store inventory and transfers
Each shop or kitchen needs its own stock locations, and transfers move goods between them. The decision is which stores hold stock independently, which sell from a central warehouse, and how returns and waste are recorded. The data you need is the location structure, opening counts for each store, unit of measure rules, and reorder points for each site. Set up transfers and counts in a test database first, and confirm which multi-company functions your plan includes, since Odoo's pricing page limits multi-company to the Custom plan.
Product variants and modifiers for menus
Menus need variants, such as sizes, and modifiers, such as extra cheese or no onion, and each option can change the price or the recipe. Decide which options are variants that create separate stock items and which are modifiers that only change the ticket. The data you need is the menu structure, option prices, and any recipe or bill of materials for each item. Check how modifiers reach the kitchen printers in your target version, because one option can affect both pricing and kitchen tickets.
Accounting and tax mapping
Every sale posts to accounting through the tax, journal and income account mapped to each product and payment method. Decide the tax rates for each product group and region, the sales journal for each store, and how tips, discounts and rounding post. The data you need is the chart of accounts, the tax rate tables and the fiscal position for each store location. Confirm the country localization for your tax regime in the target version, and have your accountant review sample closing entries, because a wrong mapping appears in every report.
How floor plans, kitchen printing and payment terminals fit into one daily flow
The core point of this section is that a service day is one chain of linked records, and most build decisions sit at the handoffs between them. In a restaurant, a server opens a table on the floor plan and sends the order. The kitchen ticket prints at the station printers that the order's products are routed to, the guest pays at a terminal paired with the point of sale, and the session is closed at the end of the shift. In a shop, a cashier scans items at a till, stock leaves the store's stock location, the customer pays by card or cash, and the day ends with a closing count. Both paths should produce the same kind of trail: an order, a payment, a stock movement and, at close, accounting entries.
The restaurant build choices are concentrated in four places. Printer routing decides which product categories print at which kitchen or bar station, and it should be mapped from the menu, not from the floor layout. Terminal pairing decides which device each till or waiter tablet uses, and what happens when a terminal is offline. Split bill rules decide whether a table is divided by seat, by item or by amount, and whether each part can use a different payment method. Tips and service charges decide where the extra money is recorded so that the cash count and the card settlement still agree. Each of these should be written down with the front-of-house manager before the configuration starts.
For a shop, the choices shift toward refunds, returns and reconciliation. Refunds should be tied to the original receipt, so that the stock return and the payment reversal are linked. Roles should decide who can void a sale, issue a refund without a manager and open or close a session. The accountant should confirm how each payment method maps to a journal, how cash differences are booked, and how tips and rounding post when the session closes. Ask the implementation partner to show a sample closing report and its journal entries, and have the accountant sign off on them before go-live.
Test every path with the actual hardware in the actual location before go-live. Run a dinner-rush scenario with every printer model, a split bill across two terminals, a declined card, a partial refund, a lost network connection and a restart of the terminal during a payment. Reconcile the end-of-day totals against the terminal settlement report. Confirm hardware compatibility and terminal providers with Odoo and the provider for the chosen version before buying devices, because support differs by version and region. PCI DSS scope for the card flow is covered in the compliance section of this page.
How a restaurant or retail rollout runs in phases
A phased Odoo rollout turns menus, pricing, stock and shift rules into configured point of sale in a pilot location before the group goes live. Each phase closes with a written output that the client signs off before the next one starts.
Map menus, pricing and shift rules
We walk through how each outlet builds menus, applies price lists, runs promotions, handles discounts and voids, and assigns shifts and cash drawers. The menu owner supplies current menu cards, modifier rules and price change history, and store managers describe how service actually runs on a busy day. The output is a written process map per outlet type, with open decisions listed for the client to resolve before configuration begins.
Choose the edition and hosting model
The partner compares the Odoo plans and Community and Enterprise editions against the features the process map requires, such as floor plans, kitchen printing, multi-store stock and POS certifications for the countries involved. The finance contact confirms the licensing budget owner and the hosting constraints, including whether data must stay in a specific country or data center. The output is a written decision record covering edition, hosting, environments and the support model.
Prepare product, customer and stock data
We clean and structure product catalogs, variants, units of measure, customer records and opening stock counts for every location. The finance contact confirms tax codes and accounting accounts, and store managers confirm physical counts and item naming. Import files are validated in a test database, with exceptions logged and returned to the client for correction. The output is a set of reconciled data loads with a signed count of records and stock values per location.
Build configuration and integrations
We configure POS sessions, payment methods, taxes, loyalty rules, kitchen printer routing and multi-store stock flows, and build any custom modules or connectors the process map requires, such as links to a payment provider or accounting system. The client reviews each configured feature against the process map in a test environment. The output is a configuration record and a list of tested scenarios with pass or fail results.
Test hardware and terminals in a pilot store
The hardware list is checked against the supported device and printer setup, and terminals, card readers, kitchen printers and scales are installed and tested in one pilot location. Test cases cover normal sales, refunds, split bills, offline behavior, end-of-day close and failed payments. Issues found during the pilot are fixed and retested before wider rollout. The output is a signed pilot acceptance report with a defect log and the agreed go or no-go decision for group-wide rollout.
Train staff by role
We deliver training for cashiers, kitchen staff, shift leads, store managers and the central finance team, using the configured system and the pilot store's own processes. Store managers confirm who attends and which roles need manager-only functions such as voids, price changes and cash counts. Training material is adapted from what worked in the pilot. The output is a training record by role and a short set of written procedures for each outlet.
Cut over stores and run hypercare
Remaining stores move to the new system in an agreed sequence, with stock counts, final data loads and cash reconciliations completed the day before each switch. After cutover, the partner stays on call to resolve incidents, tune configuration and answer questions during an agreed hypercare window. The output is a cutover log per store, an issues register with owners and a handover document for the client's support team.
Country POS certifications and payment scope to confirm before go-live
Restaurants and shops often need local approvals, card payment controls and record rules in place before the first sale. The cards below set out what to confirm in each area, who owns the answer and what evidence an assessment will need. DeployOpen prepares the systems and evidence, while independent auditors and certification bodies issue any audit reports or certifications.
Local POS certification and fiscal approval
Some countries require a point of sale system or fiscal device to be certified, registered or approved by a tax authority before it issues receipts in production. Odoo's fiscal localization packages cover accounting and tax logic for many countries, but they do not by themselves show that your setup meets the local rule. Confirm the requirement with the local authority, then confirm with Odoo which localization and POS features apply to your country and version before go-live.
Payment card data scope
Scope is the set of systems that store, process or transmit cardholder data, and PCI DSS applies to everything inside it. Connecting card terminals, online payment links or a payment provider integration can pull Odoo POS, its database and its network paths into that scope. Map each payment flow during design, confirm whether the provider handles card data directly, and keep card numbers out of Odoo records, logs and exported reports. Your acquirer or assessor sets the evidence they expect.
Tax and receipt rules
Tax rates, tax-inclusive or tax-exclusive pricing, rounding and receipt wording often follow local law and can differ by product type, such as prepared food and packaged goods. Check how Odoo applies taxes to POS orders, combos, discounts, tips and refunds, and test that the printed or digital receipt carries every field your authority requires. Route later tax configuration changes through a documented change process so historic receipts stay accurate.
Sales record retention and archiving
Local rules set how long sales records, POS session reports and invoices must be kept and in what form. Confirm the period and format with your tax authority or accountant, then decide where closed sessions are archived, who can access them and how backups are restored for an audit request. Test a restore into a non-production copy, and neutralize that copy so it cannot send live messages or trigger live payments. Odoo documents neutralization for test database copies.
Staff account and cashier access control
Shared cashier logins shared manager PINs make it hard to show who voided a sale, applied a discount or closed a session. Define roles for cashiers, shift leads, managers and back-office staff, restrict discounts, refunds and session closing to the roles that need them, and require individual accounts. Odoo documents LDAP sign-in, Google Sign-In, Microsoft Azure OAuth and two-factor authentication, so confirm which options your edition and hosting model support before you choose the sign-in method.
Evidence for compliance assessments
Assessors and auditors typically ask for configuration records, access reviews, backup and restore test results, change logs and network diagrams. DeployOpen can plan, configure and document these controls in your environment and prepare the supporting evidence for your assessment. DeployOpen does not issue audit reports, attestations or certifications. Agree early with your independent auditor or certification body which evidence they will accept.
Which Odoo version to build on, given the support windows
Choose the Odoo version by working backward from the support end date, not forward from the release date. A store that cannot close for a forced upgrade needs a version whose standard support runs well past the planned go-live and the quiet trading periods that follow. Standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, including security updates and bug fixes. The supplied dates are Odoo 20.0, released in September 2026 with standard support planned until September 2029; Odoo 19.0, released in September 2025 and supported until September 2028; Odoo 18.0, released in October 2024 and supported until September 2027; and Odoo 17.0, whose standard support ended in September 2026. Confirm these dates against Odoo's current support page before you sign a quote, because the window is what sets your deadline.
Security patches are provided only during standard support. Paid extended support exists, but it is limited to Odoo.sh for select versions and to on-premise deployments. Odoo SaaS versions are released every two to three months and cannot use extended support, so a store on Odoo Online must accept a steady release cadence instead of holding one version. For a point of sale estate, the practical check is whether card terminal connectors, kitchen printing and loyalty modules have been tested on each version you are considering. Ask your implementation partner to record that test result against the version number, and confirm with Odoo which extended support options apply to your hosting type before you commit to a version.
On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years. That means the store will be moved to a newer major version on a schedule set by Odoo, whether or not the business is ready. Plan the upgrade window with the operations team: identify the lowest trading weeks, agree who signs off on the cutover, and reserve time for fixing the point of sale configuration that changed. Odoo's upgrade service moves a database to a newer supported version through an upgraded test database, and Odoo's guidance is that this copy should be tested before production. Treat that test as a rehearsal of a live shift, using real menus, price lists, tax settings and terminal payments on the test copy.
What restaurant and retail owners ask before hiring an Odoo partner
What drives the cost of an Odoo POS rollout for one restaurant versus a store group?
The cost rises with the number of sites, terminals, users and integrations the POS must feed. A single restaurant mainly pays for menu and floor plan setup, kitchen printer routing, hardware testing and staff training. A store group adds multi-store stock rules, consolidated reporting, a company structure for each legal entity and a repeated rollout at each site. Licensing is a recurring cost that depends on the plan, the number of users and the edition. Odoo's pricing page places on-premise and Odoo.sh hosting under the Custom plan, so hosting choice affects the subscription. Ask the partner to separate one-time services from recurring licenses, hosting and support, and to name who buys each subscription.
How long does an Odoo POS rollout take and what sets the duration?
The duration is set by the number of sites, the state of your menu and product data, the number of integrations in scope and how many devices must be tested without disrupting trading. A single site with a standard menu and one payment terminal usually moves faster than a group that needs a pilot store followed by waves of rollout. Payment terminal setup, country fiscal rules and the availability of your staff for testing can also add time. Ask for a phased plan with a pilot, a cutover window outside peak trading, a hypercare period and a named sign-off point, and confirm your own dependencies in writing.
What must our team provide before an Odoo POS rollout starts?
Your team should supply a current menu with modifiers and recipes if you track them, price lists for each channel or store, stock counts by location, and a hardware inventory with models and network details. You will also need payment provider accounts, loyalty rules and a finance contact who can approve the chart of accounts and tax mapping. Inconsistent product data often causes delay, so clean it before the build starts. Name one person to approve menu changes during the project, because each late change can reopen floor plans and printer routing. Ask the partner to list these inputs in the scope document with an owner and a due date for each.
Can a restaurant run its own Odoo POS rollout without an outside partner?
A restaurant with experienced administrators can attempt its own rollout, but the risks sit in decisions that are hard to reverse, including the chart of accounts, tax mapping, company structure and stock valuation. Edition matters: Enterprise requires a subscription, on-premise Enterprise databases are activated with the subscription code, and Community has no access to the upgrade service. Doing it yourself also means your team owns testing, backups and cutover night. Odoo documents database duplication with neutralization for test copies, so test on a neutralized copy before touching live sales. Compare the internal effort with a fixed-scope partner quote that covers the same checklist.
Can we use Odoo Community for a restaurant chain and what does leaving cost?
Community is open source under LGPL-3.0 and can run POS and accounting, but it does not include the upgrade service, and some features are available only in Enterprise. Check each POS feature you need against both editions before you decide. Leaving Community later means moving the database to another edition or hosting arrangement, which can depend on the Enterprise upgrade path and subscription terms. The cost of leaving grows with the custom code and data you have built and with how long you have stayed on an older version. Ask for a written list of features that need Enterprise and a written description of the exit path, including what it requires from your side.
How are Odoo upgrades handled for a POS and accounting database?
Upgrades follow Odoo's support windows. Standard support covers three years after a major release and includes security fixes, while extended support is limited and security patches come only during standard support. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years according to Odoo's upgrade documentation. The upgrade service builds an upgraded test database that you must test before production, and on-premise use requires an Enterprise subscription. Custom modules and POS hardware drivers often need porting and retesting. Ask the partner for a dated upgrade plan, test cycles that include terminals and printers, and a rollback plan.
What happens to existing POS and accounting data during an Odoo rollout?
Existing POS and accounting data can usually be migrated, but the approach depends on what you keep: open invoices, customer records, product catalogs, historical sales and general ledger balances. Keep the old system available read-only for reference, map products and tax codes carefully, and choose a clean cutover point for stock levels and open tickets. Test migrations on a duplicated database and neutralize it so that outbound emails and payment callbacks do not fire. Ask for a data map, reconciliation reports for sales and ledger totals that finance signs off, and written retention rules for historical records.
What should a written quote for an Odoo POS project include?
A written quote should follow from a written scope and show costs in separate lines. Ask for the sites and terminals in scope, the edition and hosting choice with licensing terms, and the list of integrations for payments, loyalty, accounting and stock. Also request the data migration deliverables, training sessions, hypercare length, testing responsibilities, the rate for change requests, the exclusions and the client inputs with owners. Confirm who pays for hardware and payment provider fees, who holds each subscription and what happens if the scope changes. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so ask for acceptance criteria in the same document.
How DeployOpen scopes and delivers an Odoo rollout for stores and restaurants
DeployOpen plans, implements, customizes, integrates and supports Odoo inside your own cloud accounts, data centers or air-gapped networks. For stores and restaurants, the work covers the point of sale, floor plans, kitchen printing, payment terminals and stock across locations, moving through testing to go-live. Engagements are fixed-scope, with the scope agreed in writing before work starts.
How we scope
- Written scope listing the stores, registers, kitchen printers and terminals in the rollout
- Confirmation of which country POS certification applies to each location before build starts
- Confirmation of the Odoo edition and plan, since only the Custom plan supports on-premise hosting
How we build
- Floor plans, table layouts and kitchen printing routes configured against the menus you run
- Payment terminal and loyalty configuration tested with the providers you select
- Multi-store stock rules and custom modules tested on a copy of the database before production
How we hand over
- Documented configuration, store setup and terminal settings for your own team to maintain
- Test results and a go-live checklist agreed in the scope and signed off by your team
- Training materials for cashiers and managers, where the written scope includes them
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after go-live
- Major version upgrades tested on an upgraded copy before production, as Odoo's upgrade process expects
- Upgrade planning around the two-year major version cycle that Odoo.sh and Odoo Online require
